From nobody Thu Oct 1 00:59:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078ED1B2B9B for ; Thu, 1 Oct 2015 00:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.612 X-Spam-Level: X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAkKU-WAQpRZ for ; Thu, 1 Oct 2015 00:59:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EA11B2B94 for ; Thu, 1 Oct 2015 00:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=970; q=dns/txt; s=iport; t=1443686380; x=1444895980; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/uqb1CJre/MLfJ7zE4lZmlay+4Mecytkp7WqVAFzn+0=; b=mgCKCRm3BMpyLcao0n3rAEdqgHjfYSPQirCaagWjcatZwcnb5Hi+Aiju UUTnOwcGpJYADPnh/VYXnHYbDg9oidu5DqIOnkMODdsqOchcl1nkMgFTR QPMHUOznsRqdPtk5j4nBy35NIyzojHn+aLCDuXoJNXwa4JuyuQ5K2VsYv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvAQDv5gxW/5tdJa1egyeBQga5RYQhAQ2HdAKBLzgUAQEBAQEBAYEKhCQBAQEDATo/BQsCAQgYHhAhESUCBA4FiBkDCgjGRw2FDQEBAQEBAQEBAQEBAQEBAQEBAQEBAReJA4JuglCCCjMHgxiBFAEElXkBiyKBcZQLh0cBHwEBQoIRHYFUcYhygQYBAQE X-IronPort-AV: E=Sophos;i="5.17,616,1437436800"; d="scan'208";a="36666338" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 01 Oct 2015 07:59:39 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t917xdgN015446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2015 07:59:39 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 1 Oct 2015 03:59:38 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Thu, 1 Oct 2015 03:59:38 -0400 From: "Fred Baker (fred)" To: Alexandre Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ7k4GdXDL2sFAh0exNhAwtjJ+OA== Date: Thu, 1 Oct 2015 07:59:38 +0000 Message-ID: <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> In-Reply-To: <55FC5D78.4070008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.20.245] Content-Type: text/plain; charset="us-ascii" Content-ID: <768A10A5A3048840AD16AD68ED574AC3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 07:59:44 -0000 > On Sep 18, 2015, at 11:52 AM, Alexandre Petrescu wrote: >=20 >> However, it may be imposed as a crude load management system. So >> maybe the draft should point out that the number of IP addresses is >> not a proxy for the traffic load. Agree that someone might be trying to manage load. But I suspect it's more = about revenue generation. Example: I recently took a cruise on Royal Caribb= ean (which is a five star hotel on a barge), and paid five star hotel price= s for Internet access (well, not really; we didn't buy it). The first devic= e was $15/day, the second was half that, and there wasn't a third device pr= ice. Not sure what would have happened if my device had wanted to change it= s IP address daily (is that a MAC address or an IP address?). I think they = saw it as a revenue source, and weren't especially thinking about the amoun= t of space segment or ship-to-shore microwave they were using. From nobody Thu Oct 1 08:09:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF61A87D2; Thu, 1 Oct 2015 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chSMlkgOgZVQ; Thu, 1 Oct 2015 08:09:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CE81B2AC8; Thu, 1 Oct 2015 08:09:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 08:09:47 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 15:09:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Reducing energy consumption of Router Advertisements Authors : Andrew Yourtchenko Lorenzo Colitti Filename : draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt Pages : 6 Date : 2015-10-01 Abstract: Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-reducing-ra-energy-consumption-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 1 08:13:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043521B2CD6 for ; Thu, 1 Oct 2015 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIKuiRBGRVnn for ; Thu, 1 Oct 2015 08:13:51 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECFE1B2CD1 for ; Thu, 1 Oct 2015 08:13:51 -0700 (PDT) Received: by ykdz138 with SMTP id z138so82162409ykd.2 for ; Thu, 01 Oct 2015 08:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Qz0MjdnwzUJoeT0mxyPzsMDr8paa5/KaXMXf8PxB2E4=; b=SQ8rNWm+Bdhv+fNe9oCZNhk7T7vdwEgAltm5LuZ5eNwR77CIk2xJPqHJqPJwnVp9d0 S7xE+L40hcw68PNQRlmG1GfaaADwIkQLL9QbUIuC6oDkTZDshEYCaIZtg281CHrFJie7 9oigqmT5aOV5dR2LHhkXN6JKwZfaiFimMjjhWqrljK3hQWeAaKWiJNDgVucpisu6FuS3 1IpcwjrY7U0QodSwczxofuLnXVX95Y8V4F3n5PwF5gi2T/SreYiPSjcmNds5mV1sY8lY OX+8HFjn9532F2UG/oZMYB56YNbUJYuht7N2oMqR830B87PYAM4I/mdOZoRLXK/GqtT/ fu5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Qz0MjdnwzUJoeT0mxyPzsMDr8paa5/KaXMXf8PxB2E4=; b=Ax3D7GL/BQXeskA93ETeGQx2NC6lcEwpDItG1E1nsKej/gNxOmq/mIB2l0VBy4KevQ 1ipsWw92r2zTwGkWpnZxseKoBAHRQVz5MsK5lJ+Re9NhnqS+1irL+SIuZKUAgukY6WuM UCHx82upHSWzuNcRaWrpHr/4ldiAw3mZ9q/7ym7bLVUCvCdEAxRMqdjh0pROqI60qhL5 wZXkurEBRSnEkfdSsjYCgGeZtF3nGwdnnb2AIBfUE3AVAYk4xHtRAocn9mk2Ze+EOgW+ UpeGuF5uiCb29a7PsCEdWNaWzi4fviHPhmQzkwd0MFM7K9aXBCMjyUrfdtFVlsS/4UM4 pDNQ== X-Gm-Message-State: ALoCoQkI+6p2gfc0FYdlUPsATn6KTWgm5cyqIZmFQG13HuNlIZn2gA0FWKxMXZeHRwmBu0ak8hBk X-Received: by 10.129.133.195 with SMTP id v186mr9034002ywf.40.1443712430082; Thu, 01 Oct 2015 08:13:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Thu, 1 Oct 2015 08:13:30 -0700 (PDT) In-Reply-To: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Fri, 2 Oct 2015 00:13:30 +0900 Message-ID: To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a114f0f728e0edb05210c7e2e Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 15:13:52 -0000 --001a114f0f728e0edb05210c7e2e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 2, 2015 at 12:09 AM, wrote: > Title : Reducing energy consumption of Router > Advertisements > Authors : Andrew Yourtchenko > Lorenzo Colitti > Filename : > draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt > Pages : 6 > Date : 2015-10-01 > The changes from -02 are as follows: 1. Added a section on RA intervals and lifetimes. 2. Added text on RA guard in the security considerations section. Both are in response to previous WG comments. --001a114f0f728e0edb05210c7e2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 2, 2015 at 12:09 AM, <internet-drafts@ietf.org> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ti= tle=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Reducing energy consumption o= f Router Advertisements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andr= ew Yourtchenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Lorenzo Colitti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-reducing-ra-energy-consumption-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-01

The changes from -02 are as= follows:
  1. Added a section on RA intervals and lifetimes.<= br>
  2. Added text on RA guard in the security considerations section.<= /li>
Both are in response to previous WG comments.
--001a114f0f728e0edb05210c7e2e-- From nobody Thu Oct 1 11:39:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE501A8845 for ; Thu, 1 Oct 2015 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCUXxrM_8wvD for ; Thu, 1 Oct 2015 11:39:14 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230591B2E99 for ; Thu, 1 Oct 2015 11:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6464; q=dns/txt; s=iport; t=1443724753; x=1444934353; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C95+rYj9ZkBe6PYw7osam9inLurFx67o6kziWW2IoTQ=; b=gADY2IYWcGfplrOrv6Pk6lGdAX6vFKrhSLL5cY15Aj4p+WJOCyFH9jmg gSe0saAhNLIqnIDzjDSXVJDoT/YJLnPM734g2qcyUtUA1Azqh+CzbJO31 yNhkGijhDz093DuPcQg1Pn4awMBFu4ZAIlzEaQzW7mMkBxFL13fZaDYX0 Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqAgAgfQ1W/5RdJa1egydUbga9aw6BcQELhXcCgTY4FAEBAQEBAQGBCoQkAQEBAwEBAQFrEAsCAQgEFCcHJwsUEQIEEw6IGAgNy3QBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIkDgm6FCQuDGIEUBZV5AYJKgWFqh34DgU2ENo0IiEQBHwFDhAJxAYhxgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,619,1437436800"; d="asc'?scan'208,217";a="31908018" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 01 Oct 2015 18:39:12 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t91IdBGY028227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Oct 2015 18:39:12 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 1 Oct 2015 14:39:10 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Thu, 1 Oct 2015 14:39:10 -0400 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt Thread-Index: AQHQ/Hh2hfda7NGFXUyar66yPH7vPA== Date: Thu, 1 Oct 2015 18:39:10 +0000 Message-ID: References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.253.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A34A20DE-E538-4D40-81FE-9EEA62900D58"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 18:39:16 -0000 --Apple-Mail=_A34A20DE-E538-4D40-81FE-9EEA62900D58 Content-Type: multipart/alternative; boundary="Apple-Mail=_FCCE6AB7-B226-40AF-A46B-75FCA07533D9" --Apple-Mail=_FCCE6AB7-B226-40AF-A46B-75FCA07533D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks - I'd appreciate it if you would look at the update and comment = quickly. The big new text is in section 4 and the security = considerations. = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-reducing-ra-energy-= consumption-02.txt = My issue is that I moved too quickly. I looked at the list traffic and = noted that it had come to a hiatus, and assumed that Lorenzo/Andrew had = dealt with the open issues. This draft is intended to be the update that = does that. However - I filed it with the IESG. If I need to snatch it = back, say so now, please. > On Oct 1, 2015, at 8:13 AM, Lorenzo Colitti = wrote: >=20 > On Fri, Oct 2, 2015 at 12:09 AM, > wrote: > Title : Reducing energy consumption of Router = Advertisements > Authors : Andrew Yourtchenko > Lorenzo Colitti > Filename : = draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt > Pages : 6 > Date : 2015-10-01 >=20 > The changes from -02 are as follows: > Added a section on RA intervals and lifetimes. > Added text on RA guard in the security considerations section. > Both are in response to previous WG comments. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_FCCE6AB7-B226-40AF-A46B-75FCA07533D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks - I'd appreciate it if you would look at the update and = comment quickly. The big new text is in section 4 and the security = considerations. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-reducing= -ra-energy-consumption-02.txt

My issue is that I moved too quickly. I looked at the list = traffic and noted that it had come to a hiatus, and assumed that = Lorenzo/Andrew had dealt with the open issues. This draft is intended to = be the update that does that. However - I filed it with the IESG. If I = need to snatch it back, say so now, please.

On = Oct 1, 2015, at 8:13 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Fri, Oct 2, 2015 at 12:09 AM, <internet-drafts@ietf.org> = wrote:
    =     Title           : Reducing = energy consumption of Router Advertisements
        Authors         : = Andrew Yourtchenko
                    =       Lorenzo Colitti
        Filename        : = draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt
        Pages          =  : 6
        Date          =   : 2015-10-01

The changes from -02 are as = follows:
  1. Added a = section on RA intervals and lifetimes.
  2. Added text on RA guard in the security considerations = section.
Both are in response to previous WG = comments.
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_FCCE6AB7-B226-40AF-A46B-75FCA07533D9-- --Apple-Mail=_A34A20DE-E538-4D40-81FE-9EEA62900D58 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVg19z0ayAOS/EQ8MAQLPfg/+OUgs630E7ZXYVlxdHVFPZ8SlSbN61D58 l+8qs3obAcgzMxEWukReeQ0sOYVtWaypX/fCIxyKbPAvZ+D1lc+9Bl5Y5vspTz3v c4wxS9YJexdqxQpDXq6rjJvcvwFrjJgZhhpPC80MpvTyg1uMVppSbVx4eflSFc/Z vcfee6693XytMaamiPUaLNUMCazoVeFeZMx6/AqpBl8VxN4/jcshQqIi2jOq3j+5 EmU7196UCqQ2M0u6vqjG47fV/bMJgsrZOWOoOGsDtzRfTCvY4TH3BVZvd4x4zxIg P9DZ0kRailFbHA+dH1nHU9PmGjfooaYl3fVw0v4/XbTcl4dd46ECiQmkdrITlws0 CEFLE9gzAmiS97JbyzegH9hvP7gPN3cKHE7iS0FycKlWrCMY3lISG0m7Bmp9Qqj9 1/TMWiydMZ1b0kgA6p/l28j3e17kjYzEwUcJuxWQL+bS7JEI5RFp7s8nEw/Hx20P wyIMCsTUiHQuVH6FPYlqrb33NWEbmwt0C2Fjsujj6AsoNjXZUMnVYOnjMzoCeGnF TJRSjSQSJShRNgO4+baEN0Q38/ECVo+NRFYZSlkVMc9wEAw7UVLuom12LO9wEnKk zETHqtyDKF5ceO0icOD4aYweIJoH+TzKcXOWk1b1v/co/1n2jJTzD7IThGIGImFk bgg5CUmtS04= =uClj -----END PGP SIGNATURE----- --Apple-Mail=_A34A20DE-E538-4D40-81FE-9EEA62900D58-- From nobody Thu Oct 1 12:10:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A071A8862 for ; Thu, 1 Oct 2015 12:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlrs64i3yNyA for ; Thu, 1 Oct 2015 12:10:26 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAE41A88A7 for ; Thu, 1 Oct 2015 12:10:26 -0700 (PDT) Received: by pablk4 with SMTP id lk4so82026730pab.3 for ; Thu, 01 Oct 2015 12:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/0YUfwBzAkLyfZFBMQ/LzYH48ytbYRcI7bNMWEEaxTY=; b=oEvjpgUa27q3Uw7VQZkP5x7QY17de19DI9FeEeYUSGtTf6KvXjLC/RfTt+LRxVuODH xQRNeSnlwPY7Ey4pX0TzDbB41ApiMv6/CncJaUmVqS7rS8WCDK68/nMbOXucvSGeqtAT c0XnrBVk90iMZlZrVNyAdXtjyI8dZUzrpLx9CzA/N7R01HDkEZYtayE9BK09aNJOZpe5 n7evDaFX3ohZCBiOHRieiM2IGzTDpeKrAz61MF8M55qzbL0+HDJAxNUK/hNlaCpeeHSH znSGoEW5TKkXX/a7OX7Gvd7uWR8SD3vPeRWj81EvoehIndsoQtP/4OwLc2eX+xEuV4YC lYEg== X-Received: by 10.69.12.135 with SMTP id eq7mr14091309pbd.125.1443726625848; Thu, 01 Oct 2015 12:10:25 -0700 (PDT) Received: from ?IPv6:2406:e007:7515:1:28cc:dc4c:9703:6781? ([2406:e007:7515:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ce3sm8151860pbb.35.2015.10.01.12.10.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 12:10:24 -0700 (PDT) To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <560D8520.8000008@gmail.com> Date: Fri, 2 Oct 2015 08:10:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 19:10:27 -0000 On 01/10/2015 20:59, Fred Baker (fred) wrote: > >> On Sep 18, 2015, at 11:52 AM, Alexandre Petrescu wrote: >> >>> However, it may be imposed as a crude load management system. So >>> maybe the draft should point out that the number of IP addresses is >>> not a proxy for the traffic load. [That was me, not Alexandre] > Agree that someone might be trying to manage load. But I suspect it's more about revenue generation. Example: I recently took a cruise on Royal Caribbean (which is a five star hotel on a barge), and paid five star hotel prices for Internet access (well, not really; we didn't buy it). The first device was $15/day, the second was half that, and there wasn't a third device price. Not sure what would have happened if my device had wanted to change its IP address daily (is that a MAC address or an IP address?). I think they saw it as a revenue source, and weren't especially thinking about the amount of space segment or ship-to-shore microwave they were using. Sure, but in either case it's fundamentally due to a belief that an IP address is a costly resource, and I think we're trying to say "no it isn't,in IPv6." Which leaves open the question of what *is* a costly resource that it's reasonable to charge for, of course. Brian From nobody Thu Oct 1 12:16:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A81A887A for ; Thu, 1 Oct 2015 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM6LX6VZHNaL for ; Thu, 1 Oct 2015 12:16:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFE71A886C for ; Thu, 1 Oct 2015 12:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4341; q=dns/txt; s=iport; t=1443726998; x=1444936598; h=from:to:subject:date:message-id:mime-version; bh=mUScWY7HWHWb9jfItLID5Svhn6mng3rCyheO0IMJ//Q=; b=Lg+jWq8HgDl7RI/PT00bCpMTcTP2kaJXPwmDSdUXqtsVKkCsdgX4GY7l 2rxyCwqRio7WyaIUGTwBwNnv7TxSmZdvU4+hGqbobw/RPPCgyZ0QzJDsY DxNA1G17E+Mx/OF12otz2BVI3bCemRyfS9GMAZE+7GiVfPtTszFoYLzhq I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuAgBThQ1W/4ENJK1egydUdK8djk4OgXEKhzI4FAEBAQEBAQF/C4QrgQsBgQAnBCGIIA2nSKQvAQEBAQEBAQMBAQEBAQEBARYEiQOKME0dgRQFhX6MSIMzAXeBU4FhBWWHfoFQhDaNCIhEAR8BQ4QCiWOBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,619,1437436800"; d="asc'?scan'208";a="33812456" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2015 19:16:37 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t91JGbqR011769 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Oct 2015 19:16:37 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 1 Oct 2015 15:16:36 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Thu, 1 Oct 2015 15:16:36 -0400 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: State of play as of today Thread-Index: AQHQ/H2wzjVknD/1UEWCD7Z5ENLVaw== Date: Thu, 1 Oct 2015 19:16:36 +0000 Message-ID: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.253.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A6A6C30E-2B67-4E86-99E9-7FD01C42033C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 19:16:40 -0000 --Apple-Mail=_A6A6C30E-2B67-4E86-99E9-7FD01C42033C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft repository closes 10/19, the chairs are supposed to file an = initial agenda proposal the same day, and IETF 94 is the week of 11/1. = To get on the agenda, I need an updated draft from before or a new -00 = draft, and supportive discussion on the list of that draft. That means = that filing a draft on 10/19, along with 355 others, is probably not a = winning proposition. The time to file a new -00 or to stimulate = discussion of an updated draft is now. Please do so. BTW, 355 is not an exaggeration: Drafts posted 2015-07-01 - 34 Drafts posted 2015-07-02 - 58 Drafts posted 2015-07-03 - 55 Drafts posted 2015-07-04 - 26 Drafts posted 2015-07-05 - 81 Drafts posted 2015-07-06 - 355 Drafts posted 2015-07-07 - 4 Drafts posted 2015-07-08 - 4 Drafts posted 2015-07-09 - 4 Our status at this instant is as follows. - We are discussing draft-ietf-v6ops-host-addr-availability, - waiting for an update of draft-bao-v6ops-rfc6145bis in response to a = comment yesterday - waiting for an update to draft-ietf-v6ops-design-choices, - otherwise have pretty much cleared our queue of documents. I do have a proposal from Tom Herbert (formerly Google, now Facebook) to = discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is = interesting in the context of allocation of a /64 to a host in a data = center. He tells me that there are a few changes (notably a routable = interior address) in a version he is about to post, and that Facebook = plans some "canary" deployments to test the concepts. I tend to think it = would be an interesting discussion, but have not heard from the working = group. Status: Independent Series RFC Editor's queue: 2015-09-15 draft-ietf-v6ops-mobile-device-profile Publication Requested 2015-10-01 draft-ietf-v6ops-reducing-ra-energy-consumption Waiting for AD Go-Ahead (IETF LC closed, on IESG agenda 10/15) 2015-09-30 draft-ietf-v6ops-pmtud-ecmp-problem Waiting for Writeup 2015-09-22 draft-ietf-v6ops-siit-dc 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat 2015-09-22 draft-ietf-v6ops-siit-eam Waiting for update from authors: 2015-07-06 draft-ietf-v6ops-design-choices Unupdated WG Document 2015-07-06 draft-ietf-v6ops-dhcpv6-slaac-problem 2015-05-03 draft-ietf-v6ops-ula-usage-recommendations 2015-05-01 draft-ietf-v6ops-ipv6-ehs-in-real-world Updated WG Document 2015-09-03 draft-ietf-v6ops-host-addr-availability Unupdated Individual Submission 2015-07-06 draft-akira-v6ops-mape-experience 2015-07-06 draft-xcf-v6ops-chinatelecom-deployment 2015-07-05 draft-hui-v6ops-ipv6trans-select-nfv 2015-07-05 draft-xli-v6ops-cernet-deployment 2015-07-05 draft-yang-v6ops-ipv6tran-select 2015-07-01 draft-gont-v6ops-ipv6-ehs-packet-drops 2015-06-26 draft-vyncke-v6ops-ipv6-only-thin-clients 2015-06-25 draft-sun-v6ops-xlat-multi Updated Individual Submission 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack 2015-08-08 draft-bao-v6ops-rfc6145bis --Apple-Mail=_A6A6C30E-2B67-4E86-99E9-7FD01C42033C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVg2GlUayAOS/EQ8MAQJsVw/+OmvURjmNl/LdDAgwstpQHw119f68yJFM 6Sd1RMGxlRUv7o98B3DAAedTIkaKCa4D25YxpS4N2wsQWEnfqgaFKEdSpFfSWAgK m6VXfiUJK8SEV80V8nwfnp1MED3sd/BTsufY6c7FfnbS+Jg0B7MHJ0Evj+MZ+ZRX brMOo5/YgcSOVVwfUURJeT9L03xWXbvH3qE7+aQr1Cwsx3QE3fsrhFdqwWQBBi8W TzjWpA22aI5GQUabNa8aTmnQZx5zv1+DP+ZFnD7nei7vOlcIKlFX9hiWGsl6/TE1 T8yy8lP5hCWdUMPLDAtET5oDKRpeDF4FV7S0lctEZWaRm0JLVyh/Nr2uKtH2T/9R 3oLpmzQU5ZzCfny5xLW8tqo2S8TdxJ3tL40r6jnVoAmEg3Xrf2AbH37peBLMaycn jgfAMbnukSEQ3kfK4pUis2GGyas/eNj1bgel5BhbMeSzofd3l9RRz5crELorYXfr sL9wsEAuTXy4jc+4ZlT7Icmkfs3G8N7VnshE6fsZkE/mxP2sGxhr5Yo72vG6lXf9 d0xApPhX1pamLDF2KV5jM4+BYSjP9P3C55M4mhugzvK/eq3UyM4SbddD30YovXa4 pk9r+T+16Fnsk7cs4HMNWgMBcP0PY5FlhSbmaJre3+ufDyQJEe+ZOXeF6/X4FTlz JCdSekKSolw= =AWjw -----END PGP SIGNATURE----- --Apple-Mail=_A6A6C30E-2B67-4E86-99E9-7FD01C42033C-- From nobody Thu Oct 1 13:48:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB321A0178 for ; Thu, 1 Oct 2015 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3fGCE6TLx1J for ; Thu, 1 Oct 2015 13:48:30 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id AC0901A88EA for ; Thu, 1 Oct 2015 13:48:30 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 1 Oct 2015 15:48:26 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f181.google.com [209.85.214.181] #+LO+TS+TR X-Umn-Classification: local Received: by obbzf10 with SMTP id zf10so67685236obb.2 for ; Thu, 01 Oct 2015 13:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=RGVDIP6VvbZ0ja4GzXOqS9B3sIjPFYFedFgxLm7/sO0=; b=NzHWIB/MuwkCB0oKdneNRb93M4gyHo7oSRNcGD1o9k/7Pvmb/2d5s7RaPRW4a9t4cZ 4J/GVVIwDLjdjoGKCVlIakEzGGBqOQ5Ai9DVKnxv69cQOv+2zlxZtAUbOQiYHsaR2GK1 1Gt+kDPzqHVKKx5ttv8JM0oVhBTzDFSecD6pk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=RGVDIP6VvbZ0ja4GzXOqS9B3sIjPFYFedFgxLm7/sO0=; b=W3NW90yW1sDouRlaYQ/1cASawYOXEQPXm/1zvEBUXh9WrkKaWFH0l0UAsHe+xF1KFk QDFkuuz3mkQWqXsmKcrZqsV7jgQjowRfP+6Q2qpwnWdCVKWG9nzbvxA2ERV4YQ0y4+aF s2KKOJyV21U4nr+b6nGgOuNUQmnQ4ckUx4PeUKUaST2K3+QMnrj6afADF2L1MGEWFaDa XclvpX/x80lvanhOH5cDhOWPAvaM9JsG8SAW6/kuzvKsr969nEQn8xFeHUOOAjPLFwkI p5MSEnyswtX1E33nPk0GcEfpA9Snrgw2M/ahOMSXIXJq4/5A8adtLfTFBvMBj3qIOvy+ wWQw== X-Gm-Message-State: ALoCoQm6kP4g0hVqebOZwKrC4Mk99NUVLDkMsmVS1r2/P+auPC3iNdo77wbvu85A+lvRQZNNQ1BUA0jLwJHLbuUEkAOLOS7WKJVXkFLn+pSS0mK4l6oHJlIkyFbcPwr+UQ0nESCOU9+B X-Received: by 10.60.155.145 with SMTP id vw17mr7637865oeb.85.1443732506175; Thu, 01 Oct 2015 13:48:26 -0700 (PDT) X-Received: by 10.60.155.145 with SMTP id vw17mr7637848oeb.85.1443732505882; Thu, 01 Oct 2015 13:48:25 -0700 (PDT) Received: from [10.228.59.102] (mobile-107-107-189-146.mycingular.net. [107.107.189.146]) by smtp.gmail.com with ESMTPSA id lh4sm3470395obc.3.2015.10.01.13.48.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Oct 2015 13:48:23 -0700 (PDT) References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-9A9C8CCC-A501-46D5-A183-3E278DC6FC47 Message-Id: <9F756584-CDC9-4C55-AA6B-266E4D0AA1B6@umn.edu> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (13A404) From: David Farmer Date: Thu, 1 Oct 2015 15:48:21 -0500 To: "Fred Baker (fred)" Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 20:48:35 -0000 --Apple-Mail-9A9C8CCC-A501-46D5-A183-3E278DC6FC47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This covers my technical issues. =20 However, as I noted with the last version for what is now 5.2 the the term "= mobile devices" is used, whereas the rest of the document uses "battery-powe= red devices". This is mostly editorial, but I think it would read better if= consistent terminology were used throughout document. I prefer the term "b= attery-powered devices", because it is more inclusive of the full range of d= evices that are impacted by this issue. Today it mostly mobile devices, but= this is likely to be important for the Internet of Things (IoT) as it becom= es much more prevalent. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On Oct 1, 2015, at 13:39, Fred Baker (fred) wrote: >=20 > Folks - I'd appreciate it if you would look at the update and comment quic= kly. The big new text is in section 4 and the security considerations. https= ://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-reducing-ra-energy-consump= tion-02.txt >=20 > My issue is that I moved too quickly. I looked at the list traffic and not= ed that it had come to a hiatus, and assumed that Lorenzo/Andrew had dealt w= ith the open issues. This draft is intended to be the update that does that.= However - I filed it with the IESG. If I need to snatch it back, say so now= , please. >=20 >>> On Oct 1, 2015, at 8:13 AM, Lorenzo Colitti wrote: >>>=20 >>> On Fri, Oct 2, 2015 at 12:09 AM, wrote: >>> Title : Reducing energy consumption of Router Advertis= ements >>> Authors : Andrew Yourtchenko >>> Lorenzo Colitti >>> Filename : draft-ietf-v6ops-reducing-ra-energy-consumptio= n-02.txt >>> Pages : 6 >>> Date : 2015-10-01 >>=20 >> The changes from -02 are as follows: >> Added a section on RA intervals and lifetimes. >> Added text on RA guard in the security considerations section. >> Both are in response to previous WG comments. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-9A9C8CCC-A501-46D5-A183-3E278DC6FC47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This cove= rs my technical issues.
 
However, as I noted with t= he last version for what is now 5.2 the the term "mobile devices" is used, w= hereas the rest of the document uses "battery-powered devices".  This i= s mostly editorial, but I think it would read better if consistent terminolo= gy were used throughout document.  I prefer the term "battery-powered d= evices", because it is more inclusive of the full range of devices that are i= mpacted by this issue.  Today it mostly mobile devices, but this is lik= ely to be important for the Internet of Things (IoT) as it becomes much more= prevalent.

Thanks.

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>
David Farmer               &nbs= p;          Email: farmer@umn.edu
Office of Information Technology
Un= iversity of Minnesota    
2218 University Ave SE   &= nbsp;     Phone: +1-612-626-0815
Minneapolis, MN 55414-3= 029   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Oct 1, 2015, at 1= 3:39, Fred Baker (fred) <fred@cisco.com= > wrote:

Folks - I'd appre= ciate it if you would look at the update and comment quickly. The big new te= xt is in section 4 and the security considerations. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-= reducing-ra-energy-consumption-02.txt

My issue is that I moved too quickly. I looked at the list= traffic and noted that it had come to a hiatus, and assumed that Lorenzo/An= drew had dealt with the open issues. This draft is intended to be the update= that does that. However - I filed it with the IESG. If I need to snatch it b= ack, say so now, please.

On Oct 1, 2015, at 8:13 AM, Loren= zo Colitti <lorenzo@goog= le.com> wrote:

On Fri, Oct 2, 2015 at 12:09 AM, <internet-drafts@ietf.org> wrote:
        Title     =      : Reducing energy consumption of Router Advertisements<= br class=3D"">         Authors         : Andre= w Yourtchenko
                     =     Lorenzo Colitti
        Filename        : draft-ietf= -v6ops-reducing-ra-energy-consumption-02.txt
        Pages           : 6=
        Date            : 2= 015-10-01

The changes from -02 are as follows:
  1. Added a section on RA intervals and lifetimes.
  2. Added text on RA guard in the security conside= rations section.
Both are in response to previous W= G comments.
_______________________________________________
v6ops mailing l= ist
v6ops@ietf.or= g
= https://www.ietf.org/mailman/listinfo/v6ops

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


-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Davi= d Farmer                   &nbs= p;      Email: farmer@umn.e= du
Office of Information Technology
University of Minnesota    <= /span>
2= 218 University Ave SE         Phone: +1-612-626-0815
Minn= eapolis, MN 55414-3029   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= = --Apple-Mail-9A9C8CCC-A501-46D5-A183-3E278DC6FC47-- From nobody Thu Oct 1 15:41:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557E31A8F3B for ; Thu, 1 Oct 2015 15:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSCHw-fKWoWQ for ; Thu, 1 Oct 2015 15:41:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F181A8F40 for ; Thu, 1 Oct 2015 15:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1443739313; x=1444948913; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1KBvPyKfaZwCMgqkWiYvwWmQK3DEoJRyRfEmFBIED+E=; b=k6Y6H05WU/SB8GycItopZcjespbLOwO7WmULW+MkoCp4kMOWM3MLmiTE W9qvME6FhuiNajoCJ9QuhkJwThRTRXmysm1cg6aMXIaC70hKwj5R9R2rU QrkPJYUg9D0B8PZS034ndGJXGb5hFLQHMkvUrQaVpmcwSKJEB1FOLt4A6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQBQtg1W/4ENJK1egydUbga9bAENgXuFeQKBODgUAQEBAQEBAYEKhCQBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIJg3MAQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi3GEKhEBIDgGgxKBFAWFfo97AYQwZYlOhDaNCIhFHwEBQoQCcYg4OoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,620,1437436800"; d="scan'208";a="193806757" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2015 22:41:53 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t91MfqEc032049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Oct 2015 22:41:52 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 1 Oct 2015 17:41:52 -0500 Received: from xhc-aln-x15.cisco.com (173.36.12.89) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 1 Oct 2015 17:41:52 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.153]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0248.002; Thu, 1 Oct 2015 17:41:52 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: State of play as of today Thread-Index: AQHQ/H2wzjVknD/1UEWCD7Z5ENLVa55XOKcw Date: Thu, 1 Oct 2015 22:41:50 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> In-Reply-To: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:41:55 -0000 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Thursday, October 01, 2015 3:17 PM To: v6ops@ietf.org Subject: [v6ops] State of play as of today >I do have a proposal from Tom Herbert (formerly Google, now Facebook) to d= iscuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is interest= ing in the context of allocation of a /64 to a host in a >data center. He t= ells me that there are a few changes (notably a routable interior address) = in a version he is about to post, and that Facebook plans some "canary" dep= loyments to test the concepts. I >tend to think it would be an interesting = discussion, but have not heard from the working group. If Tom could please update the document with an email that does not bounce = back when people contact him for his submission, I'd appreciate it. Certa= inly, this work could be discussed including the fact whether the consensus= is to remain within the 64-bit boundary between the interface-id vs. not f= or any IPv6 addressing.=20 Other comments: In section5.1.2 , the document says "Since migrations should be relatively = rare events,". If migration is a rare event, is it worth solving the task= move problem? Why not stay with "not to migrate" until the task runs to c= ompletion and not work on any ILA? The WG and the author could decide if the document serves the purpose for = ILA and task move but keeps away from tenant separation because the securit= y in section 5.2 and its 3rd paragraph which ends in "not considered a sig= nificant risk" is questionable. I suspect security will take lot more eff= ort. Thanks, Hemant From nobody Thu Oct 1 15:48:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F961A8F42 for ; Thu, 1 Oct 2015 15:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urz0WPy-gMzl for ; Thu, 1 Oct 2015 15:48:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77B01A8F3D for ; Thu, 1 Oct 2015 15:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3239; q=dns/txt; s=iport; t=1443739728; x=1444949328; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GI3MZuh3tm5/xupB4tQ4ryutKo1Uclzi/VP0NGPSqq8=; b=YiP7dQ/lDJcyXZj91ziHOkXU+aDPeDW8QyTfT4/kliBc0wZh4C70aQI1 UPclJrIvuSYfVvinyrPJtJ4ezJzVAD8f2ZwCv9lCO6GKKrkmhYtvBIhGX wb8auy20iudIJMZgQOxcPJNld/f3Gf/r7v6IQgrvIxrqMhg89O8NlhKTk 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqAgD9tw1W/5FdJa1egydUbgavHo5ODoF7hXkCgTg4FAEBAQEBAQGBCoQkAQEBAwF5BQcEAgEIEQQBAQEnBzIUCQgCBAENBQ6IGAgNzAIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIkDgm6EKhEBUQcGgxKBFAWFfo97AYJKgWEFZYd+gVCENo0IiEQBHwFDhAJxiDg6gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,620,1437436800"; d="asc'?scan'208";a="31918831" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 01 Oct 2015 22:48:45 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t91Mmj3E015492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2015 22:48:45 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 1 Oct 2015 18:48:45 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Thu, 1 Oct 2015 18:48:44 -0400 From: "Fred Baker (fred)" To: "Hemant Singh (shemant)" , Tom Herbert Thread-Topic: State of play as of today Thread-Index: AQHQ/JtTzjVknD/1UEWCD7Z5ENLVaw== Date: Thu, 1 Oct 2015 22:48:44 +0000 Message-ID: <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.253.79] Content-Type: multipart/signed; boundary="Apple-Mail=_CA537D10-F00F-4A59-B4EE-1F108DA2E642"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:48:50 -0000 --Apple-Mail=_CA537D10-F00F-4A59-B4EE-1F108DA2E642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 1, 2015, at 3:41 PM, Hemant Singh (shemant) = wrote: >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker = (fred) > Sent: Thursday, October 01, 2015 3:17 PM > To: v6ops@ietf.org > Subject: [v6ops] State of play as of today >=20 >=20 >> I do have a proposal from Tom Herbert (formerly Google, now Facebook) = to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is = interesting in the context of allocation of a /64 to a host in a >data = center. He tells me that there are a few changes (notably a routable = interior address) in a version he is about to post, and that Facebook = plans some "canary" deployments to test the concepts. I >tend to think = it would be an interesting discussion, but have not heard from the = working group. >=20 > If Tom could please update the document with an email that does not = bounce back when people contact him for his submission, I'd appreciate = it. He seems to be using tom@herbertland.com > Certainly, this work could be discussed including the fact whether = the consensus is to remain within the 64-bit boundary between the = interface-id vs. not for any IPv6 addressing. >=20 > Other comments: >=20 > In section5.1.2 , the document says "Since migrations should be = relatively rare events,". If migration is a rare event, is it worth = solving the task move problem? Why not stay with "not to migrate" until = the task runs to completion and not work on any ILA? >=20 > The WG and the author could decide if the document serves the purpose = for ILA and task move but keeps away from tenant separation because the = security in section 5.2 and its 3rd paragraph which ends in "not = considered a significant risk" is questionable. I suspect security = will take lot more effort. >=20 > Thanks, >=20 > Hemant --Apple-Mail=_CA537D10-F00F-4A59-B4EE-1F108DA2E642 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVg24TUayAOS/EQ8MAQJKOA/+OZLjSWrkto4RcWwB/LyrKirfq3dNbwPI ncjTXrrzS1NGqb1G0dtdYtE0vR3C0dYeZTnVDJTLxyhUQMQPrm56aNu8opLesO28 T3uy3nonuOxfnWex6+tW0iyhI+3T7HC1CX2YmEoR1IFlTpkuDVbCp94v6Ryl7a1t xlstWkUnxeX1dbzc4TG85NVsaxnajptFw5GLIoajmvNSR1Tm5idmUSbwtFdQQ0gU VitHewR7kGhgD3E1op4G1v8pm9pdG31JRpHeQ5/AuKKabCDISEcK9zJ2I0F9LTM+ x0T4t0iMCDhlPqND5DcrtUjWTy22HgKYHIQPcY2NI2eq0D2x8ZOHs09Ixd/ohemz bZ0K3Eo6S7yxDRX/fU5dXBLzDbHtWqF1wDvFCQAQXvL4ukXrNdLmglwiA8dr6aO3 JQfuevqsYkDbbhQ/YgEC/ZEmM1Hn5p8/USTZ5Hp/lcFVzMh3l43wbfNJ5ar5a9QL trQnmS3pA6gtL06+NikzbAcSHM6OOtdsZghWh7aKBzYuTn201NPzMNCT1rz9qUhH u+6P1G3WBLEF4WUl5yTHvuQGwZ7MWq0MakyAxKq/eqzUw+9BXvyZ2itwuU92H3bE INu5rw5oXxqz1iRtYYr2e8S/zwDMVODGpWQiF53tmKD4hUNPBpwx4RWGczXQjqAj X5pWaoDczZo= =Ld9V -----END PGP SIGNATURE----- --Apple-Mail=_CA537D10-F00F-4A59-B4EE-1F108DA2E642-- From nobody Thu Oct 1 15:56:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1691A8FD2 for ; Thu, 1 Oct 2015 15:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV1aPqhyyRWc for ; Thu, 1 Oct 2015 15:56:34 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA231A8F50 for ; Thu, 1 Oct 2015 15:56:34 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so89303528pac.2 for ; Thu, 01 Oct 2015 15:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HQ8xV1/w4YfyogHQF8IOAKYccVyZna8AOQtyZopEdY8=; b=I5uEAA/ON/GDAtNeqZziwhuoMU1GrVtz9VWXy0Jh2YlkuF3W9SdgBp6WMatVoKifgz tUvgeP5RJhnsiwcJ2XDiup3L3qq3hiqgapSp5+txwzmXuVio9DdmBWxti2Ak/TMOExFt a8l6T1AFf0XZnfS5orkZDBiin+ma1MCj1ePiCF2GjoORBL07j3dJ5GBQ4kntAHzo2RAH QIAwv1Uy+tIz1eX+uEmwWbbE+/42SZzpmQy6Ayihj3I4WddYOsJXYVaP3+76yxsvqB4I weYj1gwxWejRzX9HXxjlrVcUedqH7njziT2Ho1xeNugRu6RIIGb2eD/xbPLGW76vFbbu y4kw== X-Received: by 10.68.180.131 with SMTP id do3mr15406875pbc.133.1443740193435; Thu, 01 Oct 2015 15:56:33 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id be6sm8782051pad.5.2015.10.01.15.56.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 15:56:32 -0700 (PDT) To: "Fred Baker (fred)" , "Hemant Singh (shemant)" , Tom Herbert References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <560DBA24.6050206@gmail.com> Date: Fri, 2 Oct 2015 11:56:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:56:36 -0000 On 02/10/2015 11:48, Fred Baker (fred) wrote: > >> On Oct 1, 2015, at 3:41 PM, Hemant Singh (shemant) wrote: >> >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) >> Sent: Thursday, October 01, 2015 3:17 PM >> To: v6ops@ietf.org >> Subject: [v6ops] State of play as of today >> >> >>> I do have a proposal from Tom Herbert (formerly Google, now Facebook) to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is interesting in the context of allocation of a /64 to a host in a >data center. He tells me that there are a few changes (notably a routable interior address) in a version he is about to post, and that Facebook plans some "canary" deployments to test the concepts. I >tend to think it would be an interesting discussion, but have not heard from the working group. >> >> If Tom could please update the document with an email that does not bounce back when people contact him for his submission, I'd appreciate it. > > He seems to be using tom@herbertland.com > >> Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing. I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at the same time. Brian >> >> Other comments: >> >> In section5.1.2 , the document says "Since migrations should be relatively rare events,". If migration is a rare event, is it worth solving the task move problem? Why not stay with "not to migrate" until the task runs to completion and not work on any ILA? >> >> The WG and the author could decide if the document serves the purpose for ILA and task move but keeps away from tenant separation because the security in section 5.2 and its 3rd paragraph which ends in "not considered a significant risk" is questionable. I suspect security will take lot more effort. >> >> Thanks, >> >> Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 1 16:25:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34071A9058 for ; Thu, 1 Oct 2015 16:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM1pSxGSfiR7 for ; Thu, 1 Oct 2015 16:24:55 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6765A1A9056 for ; Thu, 1 Oct 2015 16:24:55 -0700 (PDT) Received: by vkgd64 with SMTP id d64so50491455vkg.0 for ; Thu, 01 Oct 2015 16:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9+Sz3nLhVj6zFAo1i16SoyscrkDRotB4uVMDZ2PDulo=; b=I2ceRdO3VUv9UNQsKqUFAKEZn88DzN7aLHCtQwHQziARD0H6ZTuXhHLUXbX1LCIU0M Nb2mfssR1DIWq0e+cJ7FtUEI7O6MVVANa5u8XskpZ/kD1kY11URb5c/kwVK/ulq140JZ Aiy6GgYW52Nm6a/8kabQM01IyGaRIEc98nZx9qYdwssn5EmiW7wsEP2vn1jK5qGZKjgA gZY6DvoL0JS6C6GcxFT7E6duUxSAg3v4C1QNJDIHPZ5CUC54lS9mNSNoJdQbXnODJO57 22aJt7o4NXq7zwGjwuNXqt2BT0Lu403bWEdIIh43S278Qtkp5iArEFVJK6RdhJIt2ZPu 7AbA== X-Received: by 10.31.171.142 with SMTP id u136mr8549409vke.132.1443741894479; Thu, 01 Oct 2015 16:24:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.77.16 with HTTP; Thu, 1 Oct 2015 16:24:25 -0700 (PDT) In-Reply-To: References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> From: Mark Smith Date: Fri, 2 Oct 2015 09:24:25 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 23:24:56 -0000 Hi, On 2 October 2015 at 04:39, Fred Baker (fred) wrote: > Folks - I'd appreciate it if you would look at the update and comment > quickly. The big new text is in section 4 and the security considerations. > https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt > I'm generally ok with the next text. I did find that the new Router Advertisement frequency section intro read a bit as though it was a general and broad discussion of the reasons to adjust RA timers, rather than one specific to RA interval impacts on device power consumption. For example, I've adjusted RA timers to reduce control plane resource consumption on a broadband BNG/BRAS (e.g., 30K PPPoE sessions with the default RA timers results in 50 unique RAs per second IIRC). I'd think this reason would be out of scope for this draft. So perhaps something like the following would make it clearer that this section is only discussing battery power considerations when changing RA intervals "4. Router Advertisement frequency There are a variety of reasons to adjust the frequency of periodic RAs. This section discusses the power impacts for battery powered devices when choosing an appropriate frequency for periodic RAs." Regards, Mark. > My issue is that I moved too quickly. I looked at the list traffic and noted > that it had come to a hiatus, and assumed that Lorenzo/Andrew had dealt with > the open issues. This draft is intended to be the update that does that. > However - I filed it with the IESG. If I need to snatch it back, say so now, > please. > > On Oct 1, 2015, at 8:13 AM, Lorenzo Colitti wrote: > > On Fri, Oct 2, 2015 at 12:09 AM, wrote: >> >> Title : Reducing energy consumption of Router >> Advertisements >> Authors : Andrew Yourtchenko >> Lorenzo Colitti >> Filename : >> draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt >> Pages : 6 >> Date : 2015-10-01 > > > The changes from -02 are as follows: > > Added a section on RA intervals and lifetimes. > Added text on RA guard in the security considerations section. > > Both are in response to previous WG comments. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 1 16:59:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208DA1A90A3 for ; Thu, 1 Oct 2015 16:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSvIC3SzfTBN for ; Thu, 1 Oct 2015 16:59:45 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7611A90A5 for ; Thu, 1 Oct 2015 16:59:45 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so7661298igb.0 for ; Thu, 01 Oct 2015 16:59:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ANhthjssVpR2Gv0PsoDhhxY8GPsCo/gpNaV/WVlAo78=; b=R8afbjtqGV1fjW3pBRQ4dJ8rmBSgfR5E1V9GKXCVgjxF0SGRKkB/GtGILHnPWENpOC 5o8qeEGAUs//vCCX6R50yzr6vTMWbp0rMWGyXlWcnhcPVjFYbKCUM6LoPka+76JcVVF9 5gJthUURJ/l3etTSXTzs9HZ/AQiLJ5hmcGuDDFkbov95bZJC1DEc2WUpS5JccS4cWZcc yUoF4gmcIR0NHtZaDONMwREoOe/xdLsCUMx4Ill+PYTTLK6uobqM7K/Ep1jsv92x7Dg4 odfdyNLCsXT/7JgsbnDr9l388fIlr/17j8er8mcQX0QfxkoaI/QS8OPBbJg2APwpGu0J swQg== X-Gm-Message-State: ALoCoQkM+tZkxxxzrR2kMRPkgEpJyj7oa6/vRNiotuysmfiiZTkupFCgTb9lnGKa6rtN1CGiiV5j MIME-Version: 1.0 X-Received: by 10.50.134.231 with SMTP id pn7mr1545210igb.89.1443743984990; Thu, 01 Oct 2015 16:59:44 -0700 (PDT) Received: by 10.107.128.94 with HTTP; Thu, 1 Oct 2015 16:59:44 -0700 (PDT) In-Reply-To: <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> Date: Thu, 1 Oct 2015 16:59:44 -0700 Message-ID: From: Tom Herbert To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 23:59:47 -0000 >>> I do have a proposal from Tom Herbert (formerly Google, now Facebook) t= o discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is inter= esting in the context of allocation of a /64 to a host in a >data center. H= e tells me that there are a few changes (notably a routable interior addres= s) in a version he is about to post, and that Facebook plans some "canary" = deployments to test the concepts. I >tend to think it would be an interesti= ng discussion, but have not heard from the working group. >> >> If Tom could please update the document with an email that does not boun= ce back when people contact him for his submission, I'd appreciate it. > Sorry about that, I'll update the draft soon. > He seems to be using tom@herbertland.com > Yes. >> Certainly, this work could be discussed including the fact whether the = consensus is to remain within the 64-bit boundary between the interface-id = vs. not for any IPv6 addressing. >> >> Other comments: >> >> In section5.1.2 , the document says "Since migrations should be relative= ly rare events,". If migration is a rare event, is it worth solving the t= ask move problem? Why not stay with "not to migrate" until the task runs t= o completion and not work on any ILA? >> Rare is relative here, in a large data center we could be migrating hundreds of jobs per second. There are also instances where we need to a mass migration like when we need to bring down a cluster for repair. The salient property is that the cost of adding the ability to migrate is near zero when tasks that are not migrating. >> The WG and the author could decide if the document serves the purpose f= or ILA and task move but keeps away from tenant separation because the secu= rity in section 5.2 and its 3rd paragraph which ends in "not considered a = significant risk" is questionable. I suspect security will take lot more = effort. It's not a significant security risk in the sense that all tenants are already part of the same entity. In a cloud application with third party untrusting tenants then ILA would probably not offer adequate security (although I would point out that this is no worse security than with VXLAN). Tom >> >> Thanks, >> >> Hemant > From nobody Thu Oct 1 17:03:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734711A90AD for ; Thu, 1 Oct 2015 17:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCTO9M8i7Qgc for ; Thu, 1 Oct 2015 17:03:38 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D49C1A90AC for ; Thu, 1 Oct 2015 17:03:38 -0700 (PDT) Received: by igcpb10 with SMTP id pb10so7697445igc.1 for ; Thu, 01 Oct 2015 17:03:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ekNvYDBE7lac8wMu5zTOmBwhPuGteVHwngGFq/S7Uus=; b=QFzQ2+jfrHGQh47UKiv8aXqLjv48OUbfWUahc8QTC5ZgTmgFpo/91ObHImTcectWfx Zvk9uNPDP3MZTGO+x+BnkL9PbsXSq6/9ah7MEQkQ6gboXS/dFHMtS9uxwd7lreDJNuPh /jB+AeXmQtSYFlIap3gIQw3dLSRBkTzOcB/qnOIoPbOf6I7Dpr00y0RNa8NSozYW33+L tzb+fQR1ySCp4xo7uIp7PRMN5BK9ivAfkTWqLQ4aTTWX6Cn0UT9WCWoJMFK3UfN3zh0v rXKltIqAINCjigfABBCRCealMCJBaZ58pDYfPMziT7ulrSpMleyewZcW/OLghehdSP8r N6/w== X-Gm-Message-State: ALoCoQn/oU/7K+t8VGQKHZXYT2EMmaVm7RRIcrFoZ7gZeWu8Fhv8RlAYnFsJ24bOdKTj5c5loHYo MIME-Version: 1.0 X-Received: by 10.50.118.67 with SMTP id kk3mr1609797igb.65.1443744217703; Thu, 01 Oct 2015 17:03:37 -0700 (PDT) Received: by 10.107.128.94 with HTTP; Thu, 1 Oct 2015 17:03:37 -0700 (PDT) In-Reply-To: <560DBA24.6050206@gmail.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> Date: Thu, 1 Oct 2015 17:03:37 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 00:03:40 -0000 On Thu, Oct 1, 2015 at 3:56 PM, Brian E Carpenter wrote: > On 02/10/2015 11:48, Fred Baker (fred) wrote: >> >>> On Oct 1, 2015, at 3:41 PM, Hemant Singh (shemant) = wrote: >>> >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fr= ed) >>> Sent: Thursday, October 01, 2015 3:17 PM >>> To: v6ops@ietf.org >>> Subject: [v6ops] State of play as of today >>> >>> >>>> I do have a proposal from Tom Herbert (formerly Google, now Facebook) = to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is inte= resting in the context of allocation of a /64 to a host in a >data center. = He tells me that there are a few changes (notably a routable interior addre= ss) in a version he is about to post, and that Facebook plans some "canary"= deployments to test the concepts. I >tend to think it would be an interest= ing discussion, but have not heard from the working group. >>> >>> If Tom could please update the document with an email that does not bou= nce back when people contact him for his submission, I'd appreciate it. >> >> He seems to be using tom@herbertland.com >> >>> Certainly, this work could be discussed including the fact whether the= consensus is to remain within the 64-bit boundary between the interface-id= vs. not for any IPv6 addressing. > > I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at > the same time. > Brian, I think ILA is mostly a manifestion of the sections 4 and 5.1 of that draft (flow labels are not relevant in ILA). Tom > Brian > >>> >>> Other comments: >>> >>> In section5.1.2 , the document says "Since migrations should be relativ= ely rare events,". If migration is a rare event, is it worth solving the = task move problem? Why not stay with "not to migrate" until the task runs = to completion and not work on any ILA? >>> >>> The WG and the author could decide if the document serves the purpose = for ILA and task move but keeps away from tenant separation because the sec= urity in section 5.2 and its 3rd paragraph which ends in "not considered a= significant risk" is questionable. I suspect security will take lot more= effort. >>> >>> Thanks, >>> >>> Hemant >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From nobody Thu Oct 1 17:21:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D061A90DC for ; Thu, 1 Oct 2015 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2FrrM6Wa77M for ; Thu, 1 Oct 2015 17:21:07 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B421A90DB for ; Thu, 1 Oct 2015 17:21:07 -0700 (PDT) Received: by vkgd64 with SMTP id d64so51088999vkg.0 for ; Thu, 01 Oct 2015 17:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aadgtDZf7NX+VDKG1modffmjCaXw+H5eUcaKiyXDvSE=; b=QcODUSWIrFeB0OjpB9Y8WcdWHebhdhINXrXl87f9lzQfl8sGt9KcR3ikVsPLTZH90N lAYhwgQ/jyLVDDIOkHAfyELgcLCFNOCIiIAOwZCJUqr9N216PwzrewZ+GxGH1fP0Q0G2 ZBHkv4bVJIUfWzhRcjUHKwwpLXzxje54d6P1qDzFSmAWDaIM4exaOmFWiYHHKrF6CWhu BMrf22HIvuB3IBC9BnYpcavL4mnhyPR2invEVF8KvqjGBEjkdpR2tcjqhTblfC9G+Io5 yGchhgKQLm/79ZSCd/TTfDN31NiIq8d8i82rghBK2sXpHSFMmB9o5QATm4Xm7jd6lDzV aeYA== X-Received: by 10.31.9.81 with SMTP id 78mr7833090vkj.10.1443745266680; Thu, 01 Oct 2015 17:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.77.16 with HTTP; Thu, 1 Oct 2015 17:20:37 -0700 (PDT) In-Reply-To: <560DBA24.6050206@gmail.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> From: Mark Smith Date: Fri, 2 Oct 2015 10:20:37 +1000 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 00:21:09 -0000 Hi, On 2 October 2015 at 08:56, Brian E Carpenter wrote: >>> Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing. > > I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at > the same time. > To save people a bit of time, I did the following presentation on that draft at the AusNOG 2014 conference: "Network Virtualisation: The Killer App for IPv6?" http://www.slideshare.net/MarkSmith214/nvtkaipv6-50785685 Tom asked me to review his ILA draft a while back. In the context of both his and my drafts, and having had some further time to think about them, I think there might be two different but related problems being considered: - network virtualization, which I think might actually be more accurately described as "network emulation" - virtual machine / process portability across physical machines and grouping of them together so they share a prefix for policy and other reasons My draft was purely focussed on the first problem, although it inherently addresses the second. From memory, I think Tom's was specifically addressing both of the problems. The reason I've come to realise there are probably two different problems to consider is that one of the fundamental differences between what I proposed (and what other network virtualization/emulation methods propose) and what Tom proposed is that in his model, the hosts within the virtual networks have to have IPv6 addresses that are structured to suit the operation of the underlay network. This is easy or easier to achieve when the operator of both the underlay and overlay networks is the same entity/organisation. I think that difference is fairly significant from the point of view of trying to perform network emulation successfully. It seems to me that if you're emulating a network, then your fundamental goal is that the emulation of the network should be as transparent as possible to the hosts using the emulated network, which includes allowing them to use what ever addressing / addressing structure they'd like. I think Tom's proposal is a good solution to the second problem, however I wouldn't see it as a complete network emulation solution because of its client host addressing requirements. I do think there is a need for solutions to both types of "network virtualization". Regards, Mark. From nobody Thu Oct 1 19:18:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAD61AC39E for ; Thu, 1 Oct 2015 19:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ1-LYiKvoQ3 for ; Thu, 1 Oct 2015 19:18:20 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3961B1AC399 for ; Thu, 1 Oct 2015 19:18:20 -0700 (PDT) Received: by ykft14 with SMTP id t14so98756861ykf.0 for ; Thu, 01 Oct 2015 19:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VdPqNevAUF5TD5qSoY9x/Dkh3dxJ/GyoTEeDdBKcTvk=; b=nCaZATNFJbBcuDUDE+hX9TF5tZDp4n21du3A7v0v4hDO6wsvlGmZL93UifDEUTtLMW tT3O5BvdB+v6JQzyt0TnpR1jZjzRBMJUil59xeOp1/IG2eUutuY0JR4UDt7xzl7xjB1h tIDvvWBOyp2+PRE1ItMQ2AkHocz7iu0/fLwTcqHmI9FSj5sSn1CE57NrmBaFvHOZwWNW EP+6VY5/js8GrbeqDg3/I+VI+J5wcaVkCslX0OgeaQQXCFDGunFah8TvX2PLbyfO2+0w I7W8bPc/3nHecfLVs8Q/aorS5GR1NhlL1ggjtieZIYWvSgY/uPLpPn28gV8hxfjATCQG 75bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VdPqNevAUF5TD5qSoY9x/Dkh3dxJ/GyoTEeDdBKcTvk=; b=VI1rJk1iJqR4FufLa4EGxzk2/j81FaZTwD2I4bECIcFKf8/0UrSqCOD9KPPnegwNoc bFPbyMT2Mf958lZHOrv7qRzFv4lQEImv6XvbjQWJBEOL0NdZiwn/Ab6GpW4iPx4/1t5M PPsYccYvDRzh/P6cXJApAtMdCSdAmbw8qh9Cv+F7RlcEi75xB0VrAkXlVXFAWVYKDC99 ItGZZIO8by9H2m9lSfy2fP5zZ/d3DHzsFH7VgsctdrtbflfQS/8grXlozDiYyiz6txeg OtBAserkiQhSYiSwJibHNP7RpDnNM3ARPC+emb4PBUnnWq4pTJv29QGiVhBUmW7Q+2Ng /0gQ== X-Gm-Message-State: ALoCoQn3qQ8GeGTEMcS3J8ScPkujdHhdMePCrfR/rGpA/JW48gQiS6bcXL1hKiSemjBQELgwJ/gV X-Received: by 10.170.190.133 with SMTP id h127mr11178747yke.115.1443752299303; Thu, 01 Oct 2015 19:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Thu, 1 Oct 2015 19:17:59 -0700 (PDT) In-Reply-To: <560DBA24.6050206@gmail.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> From: Lorenzo Colitti Date: Fri, 2 Oct 2015 11:17:59 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113a1302f21e78052115c69e Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 02:18:21 -0000 --001a113a1302f21e78052115c69e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 2, 2015 at 7:56 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > >> Certainly, this work could be discussed including the fact whether the > consensus is to remain within the 64-bit boundary between the interface-id > vs. not for any IPv6 addressing. > > I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at > the same time. > I would really like to hear about this sort of thing. It's a good example of the kinds of things we'll be able to do with IPv6 when it's deployed widely enough for us to think in terms of what we can do with IPv6, instead of just mimicking whatever we do in IPv4. --001a113a1302f21e78052115c69e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 2, 2015 at 7:56 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
>&= gt;=C2=A0 Certainly, this work could be discussed including the fact whethe= r the consensus is to remain within the 64-bit boundary between the interfa= ce-id vs. not for any IPv6 addressing.

I would strongly suggest discussing draft-smith-enhance-vne-with-ipv= 6 at
the same time.

I would really like to h= ear about this sort of thing. It's a good example of the kinds of thing= s we'll be able to do with IPv6 when it's deployed widely enough fo= r us to think in terms of what we can do with IPv6, instead of just mimicki= ng whatever we do in IPv4.=C2=A0
--001a113a1302f21e78052115c69e-- From nobody Thu Oct 1 21:07:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14E1ACD17 for ; Thu, 1 Oct 2015 21:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmWXlMrJN7xJ for ; Thu, 1 Oct 2015 21:07:29 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151791ACD15 for ; Thu, 1 Oct 2015 21:07:29 -0700 (PDT) Received: by vkfp126 with SMTP id p126so53199703vkf.3 for ; Thu, 01 Oct 2015 21:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uzcQrPUdgP1OFsht/7QOgrtUvIJKhTq2nDtBgDBqQ6o=; b=SNjxyi2Q+2fJSi+W83+Daft3yhC9VtK4cmdisQ2R4QRG6+OmVOfWZBTifJiZNBQbIu GPrr3dQE2k81AUDKcSv2JdUVEFt5IfWRndDhpxVfSrn6REGB0nRNbBa5hzLM9lHfQUUh btlMh+O/+qJ1Gyjb8E4Sa/EplO2i456o8gkxShenuPahJYWwW4MOGu9JwoVA85XVtHo7 85f7t+v90ct2tJdIjzIoWMEyDLNiP+jyDJxM4D/eux+NAXtEejSmpoRFWQdjsLhEhW2j aM0HOhrbvaSiQ6zd/3vyOvju8tFr1Y92wjzV+vgX+5m5dJNWcHxB9zhLBkE2IR+tqCZT 5zrg== X-Received: by 10.31.171.142 with SMTP id u136mr9185094vke.132.1443758848234; Thu, 01 Oct 2015 21:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.77.16 with HTTP; Thu, 1 Oct 2015 21:06:58 -0700 (PDT) In-Reply-To: References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> From: Mark Smith Date: Fri, 2 Oct 2015 14:06:58 +1000 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 04:07:30 -0000 On 2 October 2015 at 12:17, Lorenzo Colitti wrote: > On Fri, Oct 2, 2015 at 7:56 AM, Brian E Carpenter > wrote: >> >> >> Certainly, this work could be discussed including the fact whether the >> >> consensus is to remain within the 64-bit boundary between the interface-id >> >> vs. not for any IPv6 addressing. >> >> I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at >> the same time. > > > I would really like to hear about this sort of thing. It's a good example of > the kinds of things we'll be able to do with IPv6 when it's deployed widely > enough for us to think in terms of what we can do with IPv6, instead of just > mimicking whatever we do in IPv4. > Just did a bump of the draft, I forgot to delete a section a few rev's ago. Here's the latest: "Enhancing Virtual Network Encapsulation with IPv6" https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 1 22:57:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DD01ACD82 for ; Thu, 1 Oct 2015 22:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S6r6-k-M4ez for ; Thu, 1 Oct 2015 22:57:26 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id C8D761ACD85 for ; Thu, 1 Oct 2015 22:57:26 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Fri, 2 Oct 2015 00:57:23 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-oi0-f54.google.com [209.85.218.54] #+LO+TS+TR X-Umn-Classification: local Received: by oiev17 with SMTP id v17so52923652oie.1 for ; Thu, 01 Oct 2015 22:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=5ihZ5uIfDXV9RaGVl99ewmecHj5w7qB6gycKNjtGuOk=; b=Hk7KJCN+eDFeHPkxyB7tBISzEtIA7cmcLZ0Sy55CtUc7NTZ6ZSLXj9+eTjg7r2G2PR 3UB0qOBQX1M0W+ZwbgleXMo8I4G9H6FTcJvnpN3QaiQh12q6UVZFmgl9151ZGvYwTNCr OGOi9CTYVfEtsHI/v3QLt4jzD2mEV/P7HxuVY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=5ihZ5uIfDXV9RaGVl99ewmecHj5w7qB6gycKNjtGuOk=; b=UvPMlPyfDmLpABhNuuSFZHFwfhIcZl2zGdxHKx7T2QN7WbT/wO0bIkLZ6rn9pgq2gs tsZi0ep8zhSztAk24hAswEtkRhrKzgx4XXnT/p5rx5vdXwlZnnFW4hG8jbTxfnAYhhdd inLQ+g2PMv9l9G3x0NLl0C+/KTgaaaC1WSx9ixA7kulSkGSSdDxOD8O8Y2ZKg1b77rHv 7/FchyZC1EsS1hs1OilQ5dcuk2WK/zFRkrMqtiZ282r+PptoVj0ElJL8AG0gTyPfJRuW uz8sDdL0dwFtX/2f8bsxvj2++YDUq/5cxl2i3C2O18SHYUezfpzXIsllEvAydz0rukbj DSbQ== X-Gm-Message-State: ALoCoQl5UNYw0JofVm90wtfP3TeLK5Ouj3dGvvKk+DkocbJQPtYxD8MwnzNjmNyD9vfuBN2a1dLrRLYuaAQ9u+WvSHaraooGrvmoc7yphJJsMRHUbMakB2otlxgS0a3M9JNebZCoYlF0 X-Received: by 10.202.169.65 with SMTP id s62mr8158195oie.28.1443765443059; Thu, 01 Oct 2015 22:57:23 -0700 (PDT) X-Received: by 10.202.169.65 with SMTP id s62mr8158186oie.28.1443765442834; Thu, 01 Oct 2015 22:57:22 -0700 (PDT) Received: from [10.228.59.102] (mobile-107-107-189-146.mycingular.net. [107.107.189.146]) by smtp.gmail.com with ESMTPSA id su2sm4380956oeb.14.2015.10.01.22.57.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Oct 2015 22:57:20 -0700 (PDT) References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <9F756584-CDC9-4C55-AA6B-266E4D0AA1B6@umn.edu> In-Reply-To: <9F756584-CDC9-4C55-AA6B-266E4D0AA1B6@umn.edu> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <7C94C787-0A6C-45D1-81FB-8A211C81DD64@umn.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (13A404) From: David Farmer Date: Fri, 2 Oct 2015 00:57:18 -0500 To: "Fred Baker (fred)" Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 05:57:28 -0000 > On Oct 1, 2015, at 15:48, David Farmer wrote: >=20 > This covers my technical issues. > =20 > However, as I noted with the last version for what is now 5.2 the the term= "mobile devices" is used, whereas the rest of the document uses "battery-po= wered devices". This is mostly editorial, but I think it would read better i= f consistent terminology were used throughout document. I prefer the term "= battery-powered devices", because it is more inclusive of the full range of d= evices that are impacted by this issue. Today it mostly mobile devices, but= this is likely to be important for the Internet of Things (IoT) as it becom= es much more prevalent. >=20 > Thanks. Reading through this again, I have a couple more editorial nits; 1. As note above "mobile devices" is used, but "battery-powered devices" and= "battery-powered hosts" are also used. "Battery-powered hosts" seems to be t= he most commonly used, so I suggest s/mobile devices/battery-powered hosts/ a= nd s/battery-powered devices/battery-powered hosts/ 2. There is a reference to RFC6104 in the security considerations section, b= ut no Informational Reference is detailed in section 9. Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Oct 2 05:58:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E901AC39F for ; Fri, 2 Oct 2015 05:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r84uay7o3FqY for ; Fri, 2 Oct 2015 05:58:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710AF1B2B42 for ; Fri, 2 Oct 2015 05:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=868; q=dns/txt; s=iport; t=1443790704; x=1445000304; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uc57PomfUIDi0p5z5s3X6qrpFO5SZCT9boHQNwONauA=; b=PdYoblDGRDrueIswLpbPXnCqbYMrOI1DKUxu9CRxAxHHnrW8lXbqXN4O sedXnjef9TrzaXZRR5tl27JB5UrAKUf9PZp2NlUbqqkrlbs0E8ohMVx4l bb+QUOOdCJ66Ibz+37LhEhq2i1h6KX9JkURJ46fXpQjq/g6dombxjVD5J w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AAAgAyfg5W/5ldJa1egyeBQga9eQENh3QCHIEeOBQBAQEBAQEBgQqEJAEBAQQjEUUQAgEIEQQBAQMCBh0DAgICMBQBCAgCBAENBQiIJrcIlEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKT4RcFhsHgmkvgRQBBJV8Aah5HwEBQoQCcYhygQYBAQE X-IronPort-AV: E=Sophos;i="5.17,623,1437436800"; d="scan'208";a="32129575" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 02 Oct 2015 12:58:23 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t92CwN6g011248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2015 12:58:23 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Oct 2015 07:58:22 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 2 Oct 2015 07:58:22 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.153]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 07:58:22 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti , Brian E Carpenter Thread-Topic: [v6ops] State of play as of today Thread-Index: AQHQ/H2wzjVknD/1UEWCD7Z5ENLVa55XOKcwgABY1QCAAAIzAIAAOESAgABejKA= Date: Fri, 2 Oct 2015 12:58:05 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891690C5D2@xmb-rcd-x06.cisco.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 12:58:29 -0000 DQo+RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXSANCj5T ZW50OiBUaHVyc2RheSwgT2N0b2JlciAwMSwgMjAxNSAxMDoxOCBQTQ0KPlRvOiBCcmlhbiBFIENh cnBlbnRlcg0KPkNjOiBGcmVkIEJha2VyIChmcmVkKTsgSGVtYW50IFNpbmdoIChzaGVtYW50KTsg VG9tIEhlcmJlcnQ7IHY2b3BzQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFt2Nm9wc10gU3RhdGUg b2YgcGxheSBhcyBvZiB0b2RheQ0KDQo+SSB3b3VsZCByZWFsbHkgbGlrZSB0byBoZWFyIGFib3V0 IHRoaXMgc29ydCBvZiB0aGluZy4gSXQncyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUga2luZHMgb2Yg dGhpbmdzIHdlJ2xsIGJlIGFibGUgdG8gZG8gd2l0aCBJUHY2IHdoZW4gaXQncyBkZXBsb3llZCB3 aWRlbHkgZW5vdWdoIGZvciB1cyB0byB0aGluayBpbiB0ZXJtcyBvZiB3aGF0IA0KPndlIGNhbiBk byB3aXRoIElQdjYsIGluc3RlYWQgb2YganVzdCBtaW1pY2tpbmcgd2hhdGV2ZXIgd2UgZG8gaW4g SVB2NC7CoA0KDQpEb2VzIElQdjQgaW4gdGhlIGRhdGEgY2VudGVyIHN1cHBvcnQgY29udGFpbmVy L3Rhc2sgbWlncmF0aW9uIGFuZCBpZiBzbywgaG93IGlzIGl0IGRvbmUgdG9kYXk/IA0KDQpIZW1h bnQNCg== From nobody Fri Oct 2 12:49:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE711A87D4 for ; Fri, 2 Oct 2015 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.625 X-Spam-Level: * X-Spam-Status: No, score=1.625 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dV85swgIHzU for ; Fri, 2 Oct 2015 12:49:20 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4A1A87D0 for ; Fri, 2 Oct 2015 12:49:20 -0700 (PDT) X-SENDER-IP: 10.64.163.151 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.17,624,1437451200"; d="scan'208";a="355370573" Received: from unknown (HELO exchpapp10.corp.twcable.com) ([10.64.163.151]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 02 Oct 2015 15:22:34 -0400 Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp10.corp.twcable.com (10.64.163.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Oct 2015 15:49:18 -0400 Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by exchpapp06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1104.000; Fri, 2 Oct 2015 15:49:18 -0400 From: "George, Wes" To: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ/UtsV/Ob8xcEUkGKhu6iiRrU4Q== Date: Fri, 2 Oct 2015 19:49:17 +0000 Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] Content-Type: text/plain; charset="utf-8" Content-ID: <1F368FD5740D404ABA55F171FA796E97@twcable.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 19:49:23 -0000 SSdtIGxhdGUgb24gdGhlIGFjdHVhbCBXR0xDLCBhbmQgZm9yIHRoYXQgSSBhcG9sb2dpemUsIGJ1 dCBzaW5jZSB0aGUNCmRpc2N1c3Npb24gaXMgc3RpbGwgZ29pbmcsIGFuZCBJIG1hZGUgc2lnbmlm aWNhbnQgY29tbWVudHMgb24gYSBwcmV2aW91cw0KdmVyc2lvbiBvZiB0aGUgZHJhZnQsIEkgd2Fu dGVkIHRvIHJlc3BvbmQuDQoNCkdlbmVyYWxseToNClRoaXMgaXMgYSBkcmFtYXRpYyBpbXByb3Zl bWVudCBvdmVyIHRoZSBwcmV2aW91cyB2ZXJzaW9ucyBhbmQgYWRkcmVzc2VzDQptYW55IG9mIG15 IGNvbmNlcm5zLiBJIHRoaW5rIHRoZXJlIGhhcyBiZWVuIHNvbWUgdmFsdWFibGUgZmVlZGJhY2sg aW4gdGhlDQpwcmV2aW91cyBjb21tZW50cyB0aGF0IEkgd29uJ3QgcmVwZWF0IGhlcmUsIGFuZCBv bmNlIGl0IGFuZCB0aGUgY29tbWVudHMNCmJlbG93IGFyZSBhZGRyZXNzZWQsIHRoZSBkcmFmdCBp cyByZWFkeSB0byBtb3ZlIG9uLg0KDQoNCkhvd2V2ZXIsIGdpdmVuIHNvbWUgb2YgdGhlIGRpc2N1 c3Npb24gdGhhdCBoYXMgdGFrZW4gcGxhY2Ugb24gdGhlICJBDQpsaXR0bGUgcHVzaGJhY2siIHRo cmVhZCwgSSB0aGluayB5b3UgbmVlZCB0byByZW1lbWJlciB0aGF0IHRob3NlIHJlc3BvbnNlcw0K YXJlIHZhbHVhYmxlIGRldmlsJ3MgYWR2b2NhdGUgZmVlZGJhY2suIFRha2UgdGhlIHBvaW50cyBy YWlzZWQgYW5kDQppbmNvcnBvcmF0ZSB5b3VyIGFkZGl0aW9uYWwgZXhwbGFuYXRpb24gYW5kIGp1 c3RpZmljYXRpb24gYXMgcmVzcG9uc2UgaW50bw0KdGhlIGRyYWZ0LCBiZWNhdXNlIHRoZSB0YXJn ZXQgYXVkaWVuY2Ugb2YgdGhpcyBkcmFmdCBhcmUgZ29pbmcgdG8gcmFpc2UNCmV4YWN0bHkgdGhl IHNhbWUgY29uY2VybnMuIFRoaXMgZHJhZnQgaXMgZXNzZW50aWFsbHkgdHJ5aW5nIHRvIHB1dA0K dG9nZXRoZXIgYSBsb2dpY2FsIGFyZ3VtZW50IHRvIGNvbnZpbmNlIG9wZXJhdG9ycyBvZiBjZXJ0 YWluIHR5cGVzIG9mDQpuZXR3b3JrcyB0byBkbyBzb21ldGhpbmcgYSBjZXJ0YWluIHdheSwgYSB3 YXkgdGhhdCBpcyBzaWduaWZpY2FudGx5DQpkaWZmZXJlbnQgZnJvbSB0aGUgd2F5IHRoYXQgdGhl eSBkbyBpdCB0b2RheSwgYW5kIHlvdXIgcHJldmlvdXMgZWZmb3J0cyB0bw0KY29udmluY2Ugb3Bl cmF0b3JzIG9mIHRoaXMgKE5BTk9HLCBhIGNlcnRhaW4gQW5kcm9pZCBidWcgSUQsIGV0YykgaGF2 ZSBub3QNCmdvbmUgd2VsbC4gQmV0d2VlbiB0aGF0IGFuZCB0aGUgZmFjdCB0aGF0IElFVEYgdW5m b3J0dW5hdGVseSBoYXMgYQ0KcmVwdXRhdGlvbiBmb3IgYmVpbmcgYSBsaXR0bGUgdG9uZSBkZWFm IG9yIGl2b3J5IHRvd2VyIHdoZW4gaXQgY29tZXMgdG8NCm1ha2luZyByZWNvbW1lbmRhdGlvbnMg dG8gb3BlcmF0b3JzLCB5b3UncmUgbm90IGFyZ3VpbmcgZnJvbSBhIHBvc2l0aW9uIG9mDQpzdHJl bmd0aCwgZXZlbiBnaXZlbiB0aGUgZXRob3Mgb2YgdGhlIGF1dGhvciBsaXN0IGFuZCB0aGUgY29t cGFueSBuYW1lcw0KYXNzb2NpYXRlZCwgYW5kIHNvIHRoZXJlIGFyZSBtdWx0aXBsZSByZWFzb25z IHRvIHJlYWxseSBjb25jZW50cmF0ZSBvbg0Kc3RyZW5ndGhlbmluZyB0aGUgc3VwcG9ydHMgb2Yg eW91ciBhc3NlcnRpb25zIGFuZCByZWNvbW1lbmRhdGlvbnMuIEVyciBvbg0KdGhlIHNpZGUgb2Yg bW9yZSBqdXN0aWZpY2F0aW9uLCBtb3JlIGRldGFpbCwgbW9yZSBkaXJlY3RseSByZWxldmFudA0K ZXhhbXBsZXMsIG1vcmUgY2l0YXRpb25zIHdoZW4gbWFraW5nIGFzc2VydGlvbnMgYWJvdXQgd2h5 IHRoaXMgaXMgdGhlDQpyaWdodCB3YXkuDQoNCldoYXQgSSBzdGlsbCBzZWUgc3BlY2lmaWNhbGx5 IG91dHN0YW5kaW5nIHRoYXQgaGFzbid0IGFscmVhZHkgYmVlbiBjb3ZlcmVkDQpieSBvdGhlcnM6 DQoNClNlY3Rpb24gOCAtIEkgZG9uJ3QgZmluZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgbGlt aXRzIG9mIGFzc2lnbmluZw0KbXVsdGlwbGUgYWRkcmVzc2VzIHZpYSBJQV9OQS9UQSBwYXJ0aWN1 bGFybHkgY29udmluY2luZyByaWdodCBub3cuIEkgdGhpbmsNCnlvdSBtYWtlIGEgZ29vZCBwb2lu dCBlYXJsaWVyIGFib3V0IHRoZXJlIGJlaW5nIHNvbWUgYWRkZWQgY29tcGxleGl0eSBhbmQNCnBv dGVudGlhbCBkZWxheXMgYXNzb2NpYXRlZCB3aXRoIGhhdmluZyB0byBhc2sgZm9yIGFkZGl0aW9u YWwgYWRkcmVzc2VzDQp3aGVuIHRoZSBzaXR1YXRpb24gY2hhbmdlcywgYW5kIEkgc2VlIHdoeSB0 aGUgcHJpbWFyeSByZWNvbW1lbmRhdGlvbiBpcw0KU0xBQUMgb3IgUEQuIEJ1dCBJIHRoaW5rIGl0 J3MgbmHDr3ZlIHRvIGFzc3VtZSB0aGF0IGFwcGxpY2F0aW9uIGFuZCBkZXZpY2UNCmRldmVsb3Bl cnMgYXJlIG5ldmVyIGdvaW5nIHRvIGhhdmUgdG8gb3BlcmF0ZSBpbiBhbiBJQV9OQSBlbnZpcm9u bWVudCBzdWNoDQp0aGF0IHRoZXkgd2lsbCBuZXZlciBoYXZlIHRvIHJlcXVlc3QgYWRkaXRpb25h bCBhZGRyZXNzZXMgaWYgdGhlIHNpdHVhdGlvbg0KY2hhbmdlcywgc28gdGhlIGNvbXBsZXhpdHkg dG8gbWFrZSBpdCByb2J1c3QgYW5kIGEgZ29vZCB1c2VyIGV4cGVyaWVuY2UgaXMNCmxpa2VseSB1 bmF2b2lkYWJsZS4gSSB0aGluayB5b3UnbGwgZmluZCBuZXR3b3JrIG9wZXJhdG9ycyB3aG8gd2ls bCBhc3NlcnQNCnRoYXQgdGhlaXIgbmV0d29yayBpcyBzZXQgdXAgc3VjaCB0aGF0IGdpdmluZyB5 b3UgbXVsdGlwbGUgYWRkcmVzc2VzIHZpYQ0KSUFfTkEgaXMgZWFzaWVyIGZvciB0aGVtLCBhbmQg dGhleSdsbCBnaXZlIHlvdSBhcyBtYW55IGFzIHlvdSBhY3R1YWxseQ0KaGF2ZSBhIHVzZSBmb3Is IHdoaWNoIGRvZXMgc29sdmUgdGhlIHByb2JsZW0gYXNzZXJ0ZWQgaGVyZSAodGhhdCBtb2Rlcm4N CmRldmljZXMgbmVlZCBtdWx0aXBsZSBhZGRyZXNzZXMpIGJ1dCB0aGV5IGRvbid0IHdhbnQgdG8g Z2l2ZSB5b3UgYW4gZW50aXJlDQovNjQsIG9yIGV2ZW4gNjQgYWRkcmVzc2VzIHVubGVzcyB5b3Ug YWN0dWFsbHkgbmVlZCB0aGF0IG1hbnkuIFNvIGlmIHlvdQ0KZG9uJ3QgYXNrIGZvciBlbm91Z2gg b24gdGhlIGluaXRpYWwgcmVxdWVzdCwgeW91IG1pZ2h0IGhhdmUgdG8gYXNrIGZvcg0KbW9yZSwg YW5kIHlvdSBuZWVkIHRvIGJlIHJlYWR5IHRvIGRlYWwgd2l0aCB0aGF0LCB3aGV0aGVyIGl0IG1l YW5zIGENCnRlbXBvcmFyeSBkZWxheSwgb3Igc2hpZnRpbmcgYmluZGluZ3Mgc28gdGhhdCB0aGUg bmV3IHRoaW5nIHVzZXMgYW4NCmV4aXN0aW5nIGFkZHJlc3MoZXMpIHdoaWxlIGFub3RoZXIgYXBw bGljYXRpb24ocykgdGhhdCBoYXBwZW5zIHRvIGJlDQpkb3JtYW50IHJlcXVlc3RzIGEgbmV3IGFk ZHJlc3MgZm9yIGl0c2VsZiBpbiB0aGUgYmFja2dyb3VuZCwgZXRjLiBJIGFncmVlDQp0aGF0IGl0 J3MgbGVzcyBwcmVmZXJhYmxlLCBidXQgYSBsb3QgbW9yZSBkaXNjdXNzaW9uIHdpbGwgYmUgbmVj ZXNzYXJ5IHRvDQpzdXBwb3J0IHRoZSBhc3NlcnRpb24gdGhhdCBhc2tpbmcgZm9yIG1vcmUgYWRk cmVzc2VzIGlzbid0IGEgd29ya2FibGUNCmVub3VnaCBhbHRlcm5hdGl2ZS4NCg0KU2VjdGlvbiA5 LjEgLQ0KDQpBIG5pdDogIi4uLnRoZSBlbnRlcnByaXNlIG5ldHdvcmtzIG9mIHRoZSBhdXRob3Jz Li4uICpFbXBsb3llcnMqIiB3b3VsZCBiZQ0KbW9yZSBhY2N1cmF0ZSwgYnV0IHNpbmNlIGF1dGhv cnMgYXJlIHN1cHBvc2VkIHRvIGJlIHdvcmtpbmcgYXMNCmluZGl2aWR1YWxzLCBtaWdodCBiZSBi ZXR0ZXIgdG8ganVzdCBzYXkgImVudGVycHJpc2UgbmV0d29ya3MgYXQgQXBwbGUgYW5kDQpHb29n bGUiIGFuZCBsZWF2ZSB0aGUgYXV0aG9ycyBvdXQgb2YgdGhlIGRpc2N1c3Npb24sIHNpbmNlIHRo ZWlyDQphZmZpbGlhdGlvbnMgcHJvdmlkZSBzb21lIGltcGxpZWQgY3JlZGliaWxpdHkgdG8gc3Bl YWsgYXV0aG9yaXRhdGl2ZWx5DQphYm91dCB0aGUgbmV0d29ya3MgYXQgQXBwbGUgYW5kIEdvb2ds ZSB3aXRob3V0IGZ1cnRoZXIgY2l0YXRpb24uIDotKQ0KDQpNb3JlIHN1YnN0YW50aXZlbHk6IFRo YXQgbGFzdCBwYXJhZ3JhcGggaXMgZ2VuZXJhbGx5IGJhc2VkIG9uIG9uZQ0KYXNzZXJ0aW9uIHRo YXQgSSdtIG5vdCBzdXJlIGlzIGZ1bGx5IGZvcm1lZCBhbmQgc3VwcG9ydGVkLiBUaGVyZSBpc24n dCBhbnkNCmRpc2N1c3Npb24gb2Ygd2hldGhlciB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrcyBhdCBB cHBsZSBhbmQgR29vZ2xlIG9yDQplbnRlcnByaXNlIG5ldHdvcmtzIGluIGdlbmVyYWwgYXJlIGJv dW5kIGJ5IHRoZSBzYW1lIHJlcXVpcmVtZW50cyB0byB0cmFjaw0KaG9zdCB0byBJUCBhbmQgd2hh dCBtZXRob2QgdGhleSdyZSB1c2luZyB0byBhZGRyZXNzIHRoYXQgaXNzdWUuIElmIHRoaXMNCmp1 c3QgaXNuJ3QgYW4gaXNzdWUsIGVpdGhlciBiZWNhdXNlIHRoZXkncmUgdXNpbmcgYXV0aGVudGlj YXRpb24gKC4xeCBvcg0Kc2ltaWxhcikgb3IgYmVjYXVzZSB0aGV5IGRvbid0IGFjdHVhbGx5IG5l ZWQvY2FyZSB0byB0cmFjayBob3N0cywgdGhhbg0KdGhpcyBpc24ndCBhZGRpbmcgbXVjaCBpbiB0 aGUgd2F5IG9mIHN1cHBvcnRpbmcgdGhlIHJlY29tbWVuZGF0aW9uIGFuZA0Kc2hvdWxkIHByb2Jh Ymx5IGJlIHJlbW92ZWQuIFJpZ2h0IG5vdywgdGhlIHdheSBJIGFtIGludGVycHJldGluZyBpdCBp cw0KdGhhdCBpdCdzIG1vcmUgaW50ZW5kZWQgdG8gc3VwcG9ydCB0aGUgYXNzZXJ0aW9uIHRoYXQg REhDUHY2IGlzIGdlbmVyYWxseQ0Kbm90IG5lY2Vzc2FyeSBpbiBlbnRlcnByaXNlIG5ldHdvcmtz IChpLmUuICJqdXN0IGJlY2F1c2UgeW91IHVzZSBESENQdjQNCmRvZXNuJ3QgbWVhbiB5b3UgYXV0 b21hdGljYWxseSBuZWVkIERIQ1B2NiIpIHJhdGhlciB0aGFuIHNwZWNpZmljYWxseQ0Kc3VwcG9y dGluZyB0aGUgYXNzZXJ0aW9uIHRoYXQgdGhlIGFsdGVybmF0aXZlIG1lYW5zIG9mIHRyYWNraW5n IGhvc3QgdG8gSVANCnByZXNlbnRlZCBoZXJlIGFyZSBzdWZmaWNpZW50LCBhbmQgSSBkb24ndCBi ZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50DQphY3R1YWxseSBwcm92aWRlcyBtdWNoIGluIHRoZSB3 YXkgb2Ygc3VwcG9ydCBmb3IgdGhlIGZpcnN0IGFzc2VydGlvbiwNCmJlY2F1c2UgZW50ZXJwcmlz ZSBuZXR3b3JraW5nIGlzIG5vdCBvbmUgc2l6ZSBmaXRzIGFsbC4NClRoZSBhc3NlcnRpb24gdGhh dCBtYW55IGxhcmdlIHVuaXZlcnNpdGllcyB1c2UgdGhlIHJlY29tbWVuZGVkIG1ldGhvZHMgZm9y DQpob3N0IHRyYWNraW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQgYnkgYW4gZXhhbXBsZSBhbmQgY2l0 YXRpb24gaWYgYXQgYWxsDQpwb3NzaWJsZSwgYmVjYXVzZSBvdGhlcndpc2UgaXQncyBhbHNvIG5v dCBhZGRpbmcgYSBsb3QgaW4gdGhlIHdheSBvZg0Kc3VwcG9ydCBzaW5jZSBub25lIG9mIHRoZSBh dXRob3JzIGlzIHJlcHJlc2VudGluZyBhIHVuaXZlcnNpdHkgYW5kIHRodXMgaXQNCnNvdW5kcyBs aWtlIGhlYXJzYXkuDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KDQpPbiA5LzEzLzE1LCAyOjAwIFBN LCAidjZvcHMgb24gYmVoYWxmIG9mIGZyZWRAY2lzY28uY29tIg0KPHY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGZyZWRAY2lzY28uY29tPiB3cm90ZToNCg0KPlRoaXMgaXMgdG8g aW5pdGlhdGUgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvZg0KPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0 eS4NCj5QbGVhc2UgcmVhZCBpdCBub3cuIElmIHlvdSBmaW5kIG5pdHMgKHNwZWxsaW5nIGVycm9y cywgbWlub3Igc3VnZ2VzdGVkDQo+d29yZGluZyBjaGFuZ2VzLCBldGMpLCBjb21tZW50IHRvIHRo ZSBhdXRob3JzOyBpZiB5b3UgZmluZCBncmVhdGVyDQo+aXNzdWVzLCBzdWNoIGFzIGRpc2FncmVl aW5nIHdpdGggYSBzdGF0ZW1lbnQgb3IgZmluZGluZyBhZGRpdGlvbmFsDQo+aXNzdWVzIHRoYXQg bmVlZCB0byBiZSBhZGRyZXNzZWQsIHBsZWFzZSBwb3N0IHlvdXIgY29tbWVudHMgdG8gdGhlDQo+ bGlzdC4NCj4NCj5XZSBhcmUgbG9va2luZyBzcGVjaWZpY2FsbHkgZm9yIGNvbW1lbnRzIG9uIHRo ZSBpbXBvcnRhbmNlIG9mIHRoZQ0KPmRvY3VtZW50IGFzIHdlbGwgYXMgaXRzIGNvbnRlbnQuIElm IHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZA0KPmJlbGlldmUgaXQgdG8gYmUgb2Ygb3Bl cmF0aW9uYWwgdXRpbGl0eSwgdGhhdCBpcyBhbHNvIGFuIGltcG9ydGFudA0KPmNvbW1lbnQgdG8g bWFrZS4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUg aGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8g Y29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Fri Oct 2 13:18:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B921B2D24 for ; Fri, 2 Oct 2015 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of1HnW7GMZZk for ; Fri, 2 Oct 2015 13:18:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93B91B2D20 for ; Fri, 2 Oct 2015 13:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1443817121; x=1445026721; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6suKwFcO3tAG7uTuSMHIzqSFsI2bSFimTXbWFFC4uew=; b=VDQ98WlZOz4rnVRX95Qb0f7E3oDPTFkVkozow4WOwMj5MTNsZsAzeXja 4BHfDwqwxU4lRDAlpbRgI8+Uskr2BqP6hEPzhGkGdS7UTTs+Q4ViFI6P4 CRngjNHJ/y/pDV1Q/2r6awMCc3n3oMRk9ZzwDQ3vcKLWvGMTmUFw2Kw1D U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqAgAg5Q5W/5ldJa1egydUXw8GvX4OgX2FLUoCgTY4FAEBAQEBAQGBCoQkAQEBAwF5BQsCAQgYLjIXDgIEDgUOiBgIDctWAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kDgm6EQksHgxiBFAWNBYh3AYJLgWFqiACBVodbkjEBHwFDhAJxAYhxgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,624,1437436800"; d="asc'?scan'208";a="194028592" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 02 Oct 2015 20:18:40 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t92KIeX1029527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2015 20:18:40 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Oct 2015 16:18:39 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Fri, 2 Oct 2015 16:18:39 -0400 From: "Fred Baker (fred)" To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] State of play as of today Thread-Index: AQHQ/U+GrOyYFXIR7kanu4yL9Vqohg== Date: Fri, 2 Oct 2015 20:18:39 +0000 Message-ID: <7C389E24-F5D8-4C1E-85CC-0DBBB2146935@cisco.com> References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com> <560DBA24.6050206@gmail.com> <75B6FA9F576969419E42BECB86CB1B891690C5D2@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B891690C5D2@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.233] Content-Type: multipart/signed; boundary="Apple-Mail=_F4A6C482-3D74-4DCD-BD91-06622923F1F5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:18:43 -0000 --Apple-Mail=_F4A6C482-3D74-4DCD-BD91-06622923F1F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 2, 2015, at 5:58 AM, Hemant Singh (shemant) = wrote: >=20 > Does IPv4 in the data center support container/task migration and if = so, how is it done today? This isn't really an IPv4/IPv6 question as much as it is a process = question. To my knowledge, there are two fundamental approaches. One is suitable for transaction systems, like Jynga's games, web = clusters, and client/server applications built on top of the web. In = that model, consider that the server is a cluster of VM/Containers that = one reaches by DNS name or something equivalent. In that model, one = spins up a new server instance, adds its address to the DNS name in a = DNS Resource Record (so it is now servicing transactions), deletes the = old address's DNS Resource Record (so the only folks opening new = transactions with it already had its address from a previous read of = DNS), waits a while (the RR has to expire, and you then need to continue = waiting until all active sessions acquiesce), and then kills the old = system. The other is more for applications that have to maintain memory across = such a change. VMWare describes it at = http://kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&cmd= =3DdisplayKC&externalId=3D1000936. In that case, you're literally moving = the VM/Container and its IP address; if you're not willing to stop its = processing while you do so, it is changing its swap image while you're = copying the image somewhere else. Net result - you copy the image, copy = the parts that changed while you were doing that, and do so again, until = you get something consistent at the new and the old locations. Then you = kill the old and continue with the new. The advantage of Tom's approach is that moving the "inside" address = requires nothing in routing, only informing the systems that care where = the instance is that the instance has changed. Depending on the nature = of the application moved, you'll use something akin to one of those = approaches. --Apple-Mail=_F4A6C482-3D74-4DCD-BD91-06622923F1F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVg7mpEayAOS/EQ8MAQLzSQ/+KUzH1Ztmctx3tjEQnw5QopAP/tWaJLBo OmExBa0b2FOIQwl+TUUkbaHUFSBBtTqWxSsQEOFWmf+9pE1SYgVDDRk1MgL93MHL L4Q5PCQgQa/JH72zLxnxI5mvtMn8/qhy5fUAtiTcSBqqIsL370+VHy9zR7CvrwKI Z5O5vYgLQE+xc0fmikfN1hlJ74T3wmODMjKFCtusMHoMypzsqKORV/o3AkgnWxJy PVb6Q3jvP5BPnjlux7rCwYJPNdrUcDJob1dYeFZSK/rFfafmFKkBHEHxCzYzQ+Jq sC9Wtg/3jjIg0jLnAgI0Tsk6eTG1ZtNNuACRKLW/Aa6i5v1spuqObn62k3dISf6M wGVZAr3mo4xJ/rI6WUzQUoKd63vi5Q1Tk5PcS0n3J6dSd7a22+C52PVfuzbHSQZM vwTciNTXqMc3koMp8uT0CmP4krWohjqr3FIDwNRg5SwEbKzlQKxEQZJ+qGhdbR6M Rab3L8yAreySx/i8Q6MqTm2vtsO804n3m+CsGniMlvxyuAfkM27WHUzOejEw1K5p I2cu6P2tq57x973uW+xdxlzywrXQHFwxPscbWKIfkFWV1C5cYk7xCoFSmjsbQzxn z5mV/aL00Dlh3cwi6ce328tuHQJfIuYvJJEWM7Lt5Voru2X0ald7HfT3Hg9a0jbV 3sJWt4ry4FY= =ZlBj -----END PGP SIGNATURE----- --Apple-Mail=_F4A6C482-3D74-4DCD-BD91-06622923F1F5-- From nobody Fri Oct 2 13:18:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36161B2D20 for ; Fri, 2 Oct 2015 13:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDblZWKF9ngC for ; Fri, 2 Oct 2015 13:18:43 -0700 (PDT) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4697A1B2D23 for ; Fri, 2 Oct 2015 13:18:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0NVL00000ZDMA400@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Fri, 02 Oct 2015 15:18:41 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.2.201216, SenderIP=0.0.0.0 Received: from DOIT-2NW1MRFY-X.doit.wisc.edu (brie.doit.wisc.edu [144.92.67.198]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NVM000H10F2KG00@smtpauth3.wiscmail.wisc.edu>; Fri, 02 Oct 2015 15:18:40 -0500 (CDT) Date: Fri, 02 Oct 2015 15:18:38 -0500 From: "Dale W. Carder" To: "George, Wes" Message-id: <20151002201838.GA30574@DOIT-2NW1MRFY-X.doit.wisc.edu> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> In-reply-to: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:18:45 -0000 Thus spake George, Wes (wesley.george@twcable.com) on Fri, Oct 02, 2015 at 07:49:17PM +0000: > The assertion that many large universities use the recommended methods for > host tracking should be supported by an example and citation if at all > possible, because otherwise it's also not adding a lot in the way of > support since none of the authors is representing a university and thus it > sounds like hearsay. Well, this one does. So there's one ;-) Here's the specific script we were running circa 2008: http://net.doit.wisc.edu/~dwcarder/scripts/physaddrwatch_ipv6.pl These days it has been rewritten to screen scrape more modern platforms. We do the same thing for IPv4 (and historically also did for IPX and appletalk), regardless of dhcp lease tracking and rfc6939. Dale From nobody Fri Oct 2 16:58:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF41A8AA9 for ; Fri, 2 Oct 2015 16:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sCz_SeG6MCq for ; Fri, 2 Oct 2015 16:58:41 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 164F91A8AA7 for ; Fri, 2 Oct 2015 16:58:40 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Fri, 2 Oct 2015 18:58:35 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-qg0-f51.google.com [209.85.192.51] #+LO+TS+TR X-Umn-Classification: local Received: by qgez77 with SMTP id z77so108451437qge.1 for ; Fri, 02 Oct 2015 16:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=EAObjoJG/Mp+9EM9trbwd7PB4yGK1DYcc58L2qGsz04=; b=SNJG2Tzj4+4//1PxIAe98DrCjIdqLuR6LYWl/ozpqwrPyZP71rqzj7XPmpwfHUuLbV +yjJ8uqtu4z5XTRAvYkaCfyomlPQ6DImc3BOYDJbe4bvvppLCGTwzHv4XMj1r8mV7iFz SHpgcGZWVgLBALLohoOSTLRzQQ7ZO3B5s/REA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=EAObjoJG/Mp+9EM9trbwd7PB4yGK1DYcc58L2qGsz04=; b=A5N7KEOmgHEIAXhKO5kigkgL1iiZFrCq1d6q1FiuJoGLGjDk1MfG5h0pvI1LetN4lR utJ5zVd5VpEtZ9+zNhRJTYRVwKUmCMrJDBIKloo0u631UV4PME7cJPjqm0oKUls5B4p9 EhN5T6rTutceUyvtPfHlvMS2Suxi0WYSuc64ri1LhszmLwRd7pwmOyQtz327TzNTtUm8 Smfj86c5hDhvPQxbZ4vobWp4wUTApuypvZJ4xL6m0zNBbjTZPE7inguuO7Yn+QXt0tIm Q+OftGgdfwRCRTzTBzpPg2VaxIDcmWX+rsk+3nteyBOVKozHyVQjw9p5Xb4oVo9XsIvo XI/w== X-Gm-Message-State: ALoCoQlhB/HWTmsEa/LkbE0wNe5PUgJZzZYm06Vx+g5XM/42zXAq4PeF+J4U9m8BeitGfT/m3Rl4BPlG6BF76iBQUs0PWaaG67G4IxL+x++jksReqPwun1WY0WPIcr7v08cFec62FkQa X-Received: by 10.140.84.116 with SMTP id k107mr23138794qgd.63.1443830315213; Fri, 02 Oct 2015 16:58:35 -0700 (PDT) X-Received: by 10.140.84.116 with SMTP id k107mr23138778qgd.63.1443830314967; Fri, 02 Oct 2015 16:58:34 -0700 (PDT) Received: from [192.168.11.186] ([107.19.189.227]) by smtp.gmail.com with ESMTPSA id m18sm5714503qgd.4.2015.10.02.16.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 16:58:32 -0700 (PDT) References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <20151002201838.GA30574@DOIT-2NW1MRFY-X.doit.wisc.edu> In-Reply-To: <20151002201838.GA30574@DOIT-2NW1MRFY-X.doit.wisc.edu> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (13A452) From: David Farmer Date: Fri, 2 Oct 2015 19:58:30 -0400 To: "Dale W. Carder" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 23:58:42 -0000 > On Oct 2, 2015, at 16:18, Dale W. Carder wrote: >=20 > Thus spake George, Wes (wesley.george@twcable.com) on Fri, Oct 02, 2015 at= 07:49:17PM +0000: >> The assertion that many large universities use the recommended methods fo= r >> host tracking should be supported by an example and citation if at all >> possible, because otherwise it's also not adding a lot in the way of >> support since none of the authors is representing a university and thus i= t >> sounds like hearsay. >=20 > Well, this one does. So there's one ;-) =20 >=20 > Here's the specific script we were running circa 2008: > http://net.doit.wisc.edu/~dwcarder/scripts/physaddrwatch_ipv6.pl > These days it has been rewritten to screen scrape more modern platforms. >=20 > We do the same thing for IPv4 (and historically also did for IPX and apple= talk), > regardless of dhcp lease tracking and rfc6939. >=20 > Dale We (UMN) do much the same for both IPv4 and IPv6. With IPv4 we never relied= on just DHCP logging because that doesn't catch manually configured hosts. = So we also collect APR tables from the routers for IPv4. I'll note that co= llecting both ARP tables and DHCP logs provides resiliency to errors or othe= r issues in either part of the system for the vast majority of hosts that do= DHCP. Enough about IPv4. Therefore similarly, we would find relying on only DHCPv6 logging unacceptab= le for the same reasons. So we currently use SLAAC, and monitor the routers= IPv6 neighbor tables as discussed. =20 However, early on, before implementing the IPv6 neighbor collection, we had w= ished DHCPv6 was universally available on hosts. Logging from the DHCPv6 se= rver would have been good enough to allow us to move forward with our IPv6 d= eployment. It wouldn't have been perfect, but it would have allowed wider d= eployment earlier on our network. For us, this was pre-2011 or so, after th= at we finally got around to implementing collection of IPv6 neighbor tables i= n our management tools. =20 So, I fully support the ideas of this document. However in the real world e= verything isn't always ideal. Therefore, it is critically important for all= hosts to support all IPv6 deployment models, SLAAC, classic DHCPv6, DHCPv6-= PD, and manual configuration. It is important to provide all options to tho= se implementing IPv6 in their networks. As I see it, the primary purpose of this document isn't to tell people how t= o implement IPv6 on their networks. It is simple telling them if they restr= ict a host to one or any other small number of addresses, then they are doin= g it wrong. Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Mon Oct 5 00:42:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2221B4BB2 for ; Mon, 5 Oct 2015 00:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz8RlI9xU454 for ; Mon, 5 Oct 2015 00:42:38 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205501B4BAE for ; Mon, 5 Oct 2015 00:42:38 -0700 (PDT) Received: by ykdt18 with SMTP id t18so163085392ykd.3 for ; Mon, 05 Oct 2015 00:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lMml29BzsVcxOTiR6K5JmkpUKe/EckyQy3Ec0AT+QYg=; b=jJZWshfeG5pBNP23AX/5dEoGn7B2Bxsp6TjQEVVMaFFICQhIcTqnguy3FhR+AFvUtF M3/tE1IO/AEIRXkgjUztyXRyw54+hYdvHEUaXwEuq0324vOVTkgPCoBqQhmha9LZb36a 6mj6Sn2i49mqTGWt5uoiBBCopyoM7vsPuisOkUUkXBXTPf9JrnzBzoQg9qU44ix6A3qf tx6Xu70PTiLO4D3Vc17c3kS5wNjKSS7+1jHv7N0wZMEmJykFl+PPjqsj4J/snswUYiy/ ZBr7PydB//3xKuUt/d/5NwUJx1xO82UdMZNFmpmnFILDzr4kyDuJLGPvgCmjTcvR4soM o4Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lMml29BzsVcxOTiR6K5JmkpUKe/EckyQy3Ec0AT+QYg=; b=geu/kYDY6PHuZWhK9gr9uiNIQGTPkFqQVRibeT6gQihf2w67OqYLOgOneS9XgtAMCN +02mrzCasxizLrJu8loH2BD+DSWrVhBkjrWTOnF2Q0qO3/iXImnmpfLaRwF3dneJbrrk CKVesQvjd41iB0vWdsdoYEQC69Bj4kcnXgKQjWlodP8+hCIo/0lkbUJy4noy216id8Sv n7BWT8bgADAL64s4hjVqVMkuJiGJpziL5fq6eGN9Hl1mr4RXoAUMYHPr0XGGyvveHMXy 1lGxAm6Ou00hEY/hSjRkkKxFjDGB/1G+TREm38cdYoVdr8dN4ht4DdJt4kVbgLMt2QxQ jViQ== X-Gm-Message-State: ALoCoQkZFQn9juU0PsZyb0LqYfiBmirhTXCArCjrg8Dln5YBhqSS2kSHCHmWuPvnCHBKimm7dqRp X-Received: by 10.129.133.195 with SMTP id v186mr24613222ywf.40.1444030957278; Mon, 05 Oct 2015 00:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.11 with HTTP; Mon, 5 Oct 2015 00:42:17 -0700 (PDT) In-Reply-To: <560D8520.8000008@gmail.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> <560D8520.8000008@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Oct 2015 16:42:17 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114f0f7241422e052156a86e Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 07:42:39 -0000 --001a114f0f7241422e052156a86e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 2, 2015 at 4:10 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think they saw it as a revenue source, and weren't especially thinking > about the amount of space segment or ship-to-shore microwave they were > using. > > Sure, but in either case it's fundamentally due to a belief that an IP > address is > a costly resource, and I think we're trying to say "no it isn't,in IPv6." > No, that's not the same. Just because something doesn't cost anything doesn't mean people won't try to charge for it. --001a114f0f7241422e052156a86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 2, 2015 at 4:10 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
I think they saw it as a revenue source, and weren't especiall= y thinking about the amount of space segment or ship-to-shore microwave the= y were using.

Sure, but in either case it's fundamentally due to a belief that= an IP address is
a costly resource, and I think we're trying to say "no it isn'= t,in IPv6."

No, that's not the= same. Just because something doesn't cost anything doesn't mean pe= ople won't try to charge for it.
--001a114f0f7241422e052156a86e-- From nobody Mon Oct 5 08:22:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2591AD071 for ; Mon, 5 Oct 2015 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3fTfpX4rq7v for ; Mon, 5 Oct 2015 08:22:40 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B753F1AD06E for ; Mon, 5 Oct 2015 08:22:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t95FMdLZ036305; Mon, 5 Oct 2015 08:22:39 -0700 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t95FMcFr036299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 5 Oct 2015 08:22:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.10]) with mapi id 14.03.0235.001; Mon, 5 Oct 2015 08:22:37 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ/0Fb4x2KflZJmEOM+GDOWGIDLZ5dALLA Date: Mon, 5 Oct 2015 15:22:37 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F187D6@XCH-BLV-504.nw.nos.boeing.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> <560D8520.8000008@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:22:41 -0000 SXQgbWlnaHQgYmUgd29ydGggZGlzY3Vzc2luZyBEQUQgaW1wbGljYXRpb25zIGluIHRoaXMgZHJh ZnQ7IHBlcmhhcHMgaW4gVGFibGUgMS4NCldpdGggU0xBQUMgYW5kIERIQ1B2NiBJQV9OQS9JQV9U QSwgREFEIGlzIHJlcXVpcmVkIHRvIHRlc3QgZm9yIHVuaXF1ZW5lc3MNCm9uIHRoZSBsaW5rLiBX aXRoIERIQ1B2NiBQRCwgREFEIGlzIG5vdCByZXF1aXJlZCBiZWNhdXNlIHRoZSBkZWxlZ2F0ZWQg cHJlZml4DQppcyBmdWxseSBvd25lZCBieSB0aGUgcmVxdWVzdGluZyBkZXZpY2UgYW5kIG5vdCBh c3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlIG92ZXINCndoaWNoIHRoZSBwcmVmaXggaXMgZGVsZWdh dGVkIChhbHRob3VnaCBpbmRpdmlkdWFsIGFkZHJlc3NlcyBmcm9tIHRoZSBkZWxlZ2F0ZWQNCnBy ZWZpeCBjYW4gYmUgYXNzaWduZWQgdG8gdGhlIGludGVyZmFjZSkuDQoNClRoYW5rcyAtIEZyZWQN CmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20gIA0K From nobody Mon Oct 5 08:58:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D22B1B3213; Mon, 5 Oct 2015 08:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP0cJ6s-TLKh; Mon, 5 Oct 2015 08:57:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4BA1B31FE; Mon, 5 Oct 2015 08:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8976; q=dns/txt; s=iport; t=1444060644; x=1445270244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2hmYvAMGDAEn8eMIQn77S14g6VFJIB/wznuz2DDm02Q=; b=ePU57/qa22knopQ4235KIrodQFqcXr1BtzIK7G+LBA6IsV+3MYFC5Ps0 Epf9o7AF7+rNnYjOVZOPEYAgBxTr0kb7QtG4UQyRztn1/WnzSIXOwE0eP 4WXh+vT/Xih1f1MMVd3AZaQzjFa0r0s9slKz7mtso51UJEKuwSz1Pnnd4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOAgDknBJW/40NJK1egydUbga+DQENgVoXDIV3AhyBFTgUAQEBAQEBAYEKhCQBAQEEAQEBIBE5AQkCEAIBCA4DAwECAwIfBwICAiULFQgIAgQBDQUUiBoNqHSUCAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIoVRAYR9hDUlGBsHBoJjgUMBBI0FiHcBhRaIAIFWR4NxgyOOQ4NuAR8BAUKCRIE+cYZ2AR8EH4EGAQEB X-IronPort-AV: E=Sophos;i="5.17,639,1437436800"; d="scan'208";a="34603285" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 05 Oct 2015 15:57:23 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t95FvKnN003267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 15:57:22 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 10:57:20 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Mon, 5 Oct 2015 10:57:20 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "opsawg@ietf.org" Thread-Topic: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) Thread-Index: AQHQ71LND9NEJgM1I0iEabKS/qboHJ5do7gA Date: Mon, 5 Oct 2015 15:57:20 +0000 Message-ID: References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> In-Reply-To: <55F76EA7.6090405@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.138.46] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: TSV Area , "'opsec@ietf.org'" , Internet Area , tsvwg , IPv6 Operations Subject: Re: [v6ops] [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:57:52 -0000 RmVybmFuZG8sIEZyZWQgYW5kIFBhdWwsDQoNClNvcnJ5IGZvciBiZWxhdGVkIHJlcGx5LCBoZXJl IGFyZSBhIGNvdXBsZSBvZiBjb21tZW50czoNCg0KVGhlIHRpdGxlIGlzIGEgbGl0dGxlIGFtYmln dW91cyBJTUhPIGl0IGlzICJPbiBGaXJld2FsbHMgaW4gU2VjdXJpdHkiDQooYmVjYXVzZSB0aGV5 IGFsc28gYXBwbHkgaW5zaWRlIGFuICdpbnRyYW5ldCcpIG9yICJPbiBGaXJld2FsbHMgaW4NCklu dGVybmV0IFByb3RvY29sIChJUCkgU2VjdXJpdHkiIG9yICJPbiBmaXJld2FsbHMgYW5kIFNlY3Vy aXR5IG9mIHRoZQ0KSW50ZXJuZXQiID8NCg0KVGhlIGludHJvZHVjdGlvbiBsb29rcyBtb3JlIGxp a2UgYW4gaGlzdG9yeSwgc28gc2hvdWxkIHBlcmhhcHMgYmUgcmVuYW1lZD8NCg0KVGVybWlub2xv Z3kgc2VjdGlvbiBzaG91bGQgcGVyaGFwcyBhcHBlYXIgbW9yZSBsaWtlIGFuIHVzdWFsIHRlcm1p bm9sb2d5DQpzZWN0aW9uIGFuZCBub3QgYXMgYSBmcmVlLWZvcm0gdGV4dD8NCg0KU2VjdGlvbiAz LjIgKGVuZCB0byBlbmQgcHJpbmNpcGxlKSBpcyBpbnRlcmVzdGluZyBidXQgaXMgYSBsaXR0bGUg Y29tcGxleA0KdG8gcmVhZC4NCg0KU2VjdGlvbiAzLjMsIHVuc3VyZSB3aGV0aGVyIEkgYW0gcmVh ZGluZyBpdCBjb3JyZWN0bHkgYnV0IEkgZG9uJ3QgYWdyZWUNCndpdGggdGhlIHN0YXRlbWVudCB0 aGF0IGZpcmV3YWxsIGNhbiBwcm90ZWN0IHRoZSAobmV0d29yaykgaW5mcmFzdHJ1Y3R1cmUNCmFn YWluc3QgRG9TIGF0dGFjayAoYXMgaGludGVkIGJ5ICJtZXNzYWdlIHZvbHVtZSBvdmVyd2hlbG1z IikuIFJhdGUNCmxpbWl0ZXJzIG9yIERvUyBzY3J1YmJpbmcgZGV2aWNlcyBkbyBub3QgcXVhbGlm eSBhcyAnZmlyZXdhbGwnIElNSE8uDQoNCkkgdGhpbmsgc2VjdGlvbiAzLjQgKGEgZ29vZCBvbmUp IHJhdGhlciBiZWxvbmdzIHRvIHNlY3Rpb24gNCBhbmQgc2hvdWxkDQphbGlnbiB0aGUgdGF4b25v bXkuDQoNClNlY3Rpb24gNC4xLCBzcGxpdCB0aGUgZmlyc3QgcGFyYWdyYXBoIGluIHR3byBwYXJ0 cy4gVGhlIHNlY29uZCBvbmUgYmVpbmcNCnRoZSBleGFtcGxlIGdpdmVuID0+IHRvIG1ha2UgaXQg Y2xlYXIgdGhhdCB0aGUgInNlc3Npb25zIG1heSBuZXZlciBiZQ0KaW5pdGlhdGVkIGZyb20gdGhl IG91dHNpZGUiIGJlbG9uZ3MgdG8gdGhlIGV4YW1wbGUgb25seQ0KDQpTZWN0aW9uIDQuMSwgMm5k IHBhcmFncmFwaCwgdGhlIHdvcmQgJ3Rlc3RpbmcnIGhhcyBhbiBhY3RpdmUgdG9uZSBpbiBteQ0K KG5vbiBuYXRpdmUpIEVuZ2xpc2gsIHdoeSBub3QgdXNpbmcgYSBtb3JlIHBhc3NpdmUgdmVyYiBz dWNoIGFzICJpbnNwZWN0Ig0Kb3IgImNoZWNrIiA/DQoNClNlY3Rpb24gNC4xLCBhdCB0aGUgcmlz ayBvZiBhcHBlYXJpbmcgYXMgJ3B1cmlzdCcsIEkgd291bGQgbW92ZSB0aGUgTkFUDQpzZWN0aW9u IGZyb20gdGhpcyBzZWN0aW9uIGFuZCBjcmVhdGUgb25lIG9uIHRoaXMgdG9waWMuDQoNClNlY3Rp b24gNC4yLCBvciByYXRoZXIgdGhlIHBlcmltZXRlciBleGlzdHMgYnV0IGl0IHZlcnkgdmVyeSBz bWFsbCA6IG9uZQ0KcGh5c2ljYWwgbGluayA6LSkgb3Igd2lkZXI6IG9uZSBsb2dpY2FsIHBlcmlt ZXRlciB3aXRob3V0IGFueSBzdHJpY3QNCmdlb2dyYXBoaWNhbCBib3VuZGFyaWVzLg0KDQpTZWN0 aW9uIDQuMiwgc2hvdWxkIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgJ3RhZ2dpbmcnIGlzIHJlcXVp cmVkIChiZWluZw0KSUVFRSA4MDIuMVEgVkxBTiB0YWcgb3IgLi4uKSwgYW5kLCB0aGUgZW5kIG9m IHRoZSBzZWN0aW9uIGlzIHJhdGhlcg0KbmVnYXRpdmUgb24gdGhpcyBzcGVjaWZpYyBGVy4NCg0K U2VjdGlvbiA0LjMsIEkgbGlrZSBpdCBvZiBjb3Vyc2UgOi0pLCBhbmQgSSBhZ3JlZSB0aGVyZSBh cmUgbm93IHNjYWxhYmxlDQphbGdvcml0aG0gdG8gZGV0ZWN0IGFub21hbGllcyBldmVuIHdpdGgg YSBzaW5nbGUgbm9kZSAodGhhbmtzIHRvDQpzZWxmLWxlYXJuaW5nIDotKSkNCg0KU2VjdGlvbiA0 LjMsICJSZXB1dGF0aW9uIGRhdGFiYXNlcyBoYXZlIGEgYmFkIHJlcHV0YXRpb24iIGlzIGEgZnVu DQpzZW50ZW5jZSA6LSkNCg0KU2VjdGlvbiA1LCBJIHdvdWxkIGFsc28gdXNlIHRoZSB3b3JkcyBv ZiB3aGl0ZSBhbmQgYmxhY2sgbGlzdHMgYXMgdGhleSBhcmUNCndlbGwta25vd24uIEkgd29uZGVy IGFsc28gd2h5IHRoZXJlIGlzIGEgc3BlY2lmaWMgc2VjdGlvbiA1LjEgd2l0aG91dCBhDQpzZWN0 aW9uIDUuMj8gSSB3b3VsZCByZW1vdmUgdGhpcyBoZWFkaW5nIGFuZCBrZWVwIHRoZSB0ZXh0LiBE b24ndCBmb3JnZXQNCnRvIG1lbnRpb24gSFRUUCAyLjAgJiB3b3JrcyBzdWNoIGFzIFFVSUMuDQoN ClNlY3Rpb24gNiwgc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IEZUUCAmIFNJUCBjYW4gYmUgdXNl ZCBmb3IgZHluYW1pYw0KcG9ydHMuIEl0IHNob3VsZCBhbHNvIG1lbnRpb24vcmVwZWF0IHRoYXQg cG9ydCA4MCBpcyBub3Qgb25seSBhYm91dCBIVFRQDQpidXQgZm9yIG1hbnkgcHJvdG9jb2xzICd0 dW5uZWxlZCcgb3ZlciBIVFRQLg0KDQpTZWN0aW9uIDYsIHRlbXBvcmFyeSBhZGRyZXNzZXMgYXJl IGluZGVlZCBhbm5veWluZyBpbiBzb21lIGNhc2VzIGJ1dCBJUA0KYWRkcmVzc2VzIGNhbiBhbHNv IGJlIHNwb29mZWQuIFNob3VsZCBtZW50aW9uIGFudGktc3Bvb2Zpbmc/IEFuZC9vciBJUFNFQw0K QUg/DQoNClNlY3Rpb24gNyBpcyBhYm91dCBsYXllci0zL2xheWVyLTQgJ3BhY2tldCBmaWx0ZXJp bmcnIHdoaWNoIGlzIGEgc3BlY2lmaWMNCmtpbmQgb2YgZmlyZXdhbGxzIHdoaWxlIHRoZSBJLUQg dGl0bGUgYXBwZWFycyB0byBiZSBtb3JlIGdlbmVyaWMuIEkNCnN1Z2dlc3QgdG8ga2VlcCB0aGUg c2VjdGlvbiBidXQgbWFrZSB0aXRsZSBtb3JlIHNwZWNpZmljIGFuZCBhZGQgc29tZQ0KaW50cm9k dWN0aW9uIHNlbnRlbmNlcyB0byB0aGlzIHNlY3Rpb24uDQoNClNlY3Rpb24gNywgSSBsaWtlIHRo ZSBwb2ludCBhYm91dCBGVyBiZWNvbWluZyB0aGUgRG9TIDotKSAod2hpY2ggaXMgcGxhaW4NCnRy dWUpLiANCg0KU2VjdGlvbiA4LCBraW5kIG9mIHJlcGVhdHMgYSBmb3JtZXIgcG9pbnQuLi4gVXNl ZnVsIHRleHQgYnV0IHNob3VsZCB1bmlmeQ0KYW5kIGF0IGEgc2luZ2xlIGxvY2F0aW9uDQoNClNl Y3Rpb24gMTAgaXMgb2YgY291cnNlIGxvb2tpbmcgZm9yIGhlYXRlZCBjb21tZW50cyBmcm9tIHRo ZSBjb21tdW5pdHkuLi4NCkhlcmUgYXJlIGEgY291cGxlOg0KLSB3b25kZXIgd2hldGhlciB0aGUg SUVURiBjb3VsZCBoYXZlIHJlY29tbWVuZGF0aW9ucyBmb3IgYWxsIGNhc2VzPw0KTW9yZW92ZXIs IHNpdHVhdGlvbiB3aWxsIHByb2JhYmx5IGNvbnRpbnVlIHRvIGV2b2x2ZQ0KLSB6b25lLWJhc2Vk IHNob3VsZCBhbHNvIGFsbG93IElDTVAgaW5ib3VuZCA7LSkNCi0gZG8gd2UgcmVhbGx5IHdhbnQg dG8gdHJ1c3QgUENQPw0KLSByb2xlLWJhc2VkLCB0aGUgcm91dGluZyB0ZWNobmlxdWUgaXMgaW50 cm9kdWNlIG5vdyBhbmQgbm90IHByZXZpb3VzbHk/DQotIHRoZSByb3V0aW5nIHRlY2huaXF1ZSB3 b3VsZCBwcm9iYWJseSBiZSBjb21wbGV4IHRvIGludHJvZHVjZSBhbmQgaGF2ZQ0Kc29tZSBzY2Fs aW5nIGxpbWl0Pw0KDQpUaGVyZSBhcmUgYWxzbyBpbXBvcnRhbnQgKElNSE8pIHRvcGljcyBNSVNT SU5HOg0KLSBtb3JlIGFuZCBtb3JlIHRyYWZmaWMgYXJlIGVuY3J5cHRlZCwgZ29vZCBmb3IgcHJp dmFjeSwgYmFkIGZvciBmaXJld2FsbHMNCmFzIHRoZXkgYXJlIGJsaW5kIG5vdyBhbmQgbW9zdGx5 IHVzZWxlc3MNCi0gcmVjb21tZW5kYXRpb24gZm9yIE5PVCBCTE9DS0lORyB0cmFmZmljIG92ZXIg dGhlIEludGVybmV0IChleGNlcHQgdG8NCmVhY2ggSVNQIG93biBpbmZyYXN0cnVjdHVyZSk/DQot IGxvZ2dpbmcgLyBhdWRpdGluZyBmdW5jdGlvbiBpcyBtaXNzaW5nICh0YWxraW5nIGFib3V0IHNl Y3VyaXR5IGhlcmUpDQotIGxvZ2dpbmcgb2YgZXZlbnQgaXMgbWlzc2luZyAodGFsa2luZyBhYm91 dCBvcGVyYXRpb24gaGVyZSkNCg0KSG9wZSB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhpcyAtMDAg dmVyc2lvbiB3aGljaCBpcyBhbHJlYWR5IHF1aXRlIGNvbXBsZXRlDQoNCi3DqXJpYw0KDQoNCg0K DQoNCg0KDQoNCg0KT24gMTUvMDkvMTUgMDM6MDQsICJPUFNFQyBvbiBiZWhhbGYgb2YgRmVybmFu ZG8gR29udCINCjxvcHNlYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmZ29udEBzaTZu ZXR3b3Jrcy5jb20+IHdyb3RlOg0KDQo+Rm9sa3MsDQo+DQo+V2UgaGF2ZSBwdWJsaXNoZWQgYW4g SS1EIGVudGl0bGVkICJPbiBGaXJld2FsbHMgaW4gSW50ZXJuZXQgU2VjdXJpdHkiLg0KPlRoZSBJ LUQgaXMgYXZhaWxhYmxlIGF0Og0KPjxodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZ29udC1vcHNhd2ctZmlyZXdhbGxzLWFuYWx5c2lzDQo+LTAwLnR4dD4uDQo+DQo+ T3VyIEktRCBjb3ZlcnMgYSBicm9hZCByYW5nZSBvZiB0b3BpY3MgKHJhbmdpbmcgZnJvbSBvcGVy YXRpb25zIHRvDQo+aW50ZXJuZXQgYW5kIHRyYW5zcG9ydCBhcmVhIHRvcGljcykgLS0gaGVuY2Ug dGhlIGNyb3NzcG9zdCBvZiB0aGlzDQo+YW5ub3VuY2VtZW50IHRvIG11bHRpcGxlIG1haWxpbmct bGlzdHMuDQo+DQo+V2hpbGUgd2UgKGNvLWF1dGhvcnMpIGFyZSBzdWJzY3JpYmVkIHRvIG1vc3Qg b2YgdGhlIGxpc3RzIHRvIHdoaWNoIHRoaXMNCj5hbm5vdW5jZW1lbnQgaXMgYmVpbmcgY3Jvc3Nw b3N0ZWQsIHdlIGV4cGVjdCAoZm9yIHRoZSBzYWtlIG9mIHVuaWZ5aW5nDQo+dGhlIGRpc2N1c3Np b24gaW4gYSBzaW5nbGUgcGxhY2UpIHRoZSBkaXNjdXNzaW9uIHRvIGhhcHBlbiBpbiB0aGUNCj5v cHNhd2dAaWV0Zi5vcmcgbWFpbGluZy1saXN0Lg0KPg0KPllvdXIgZmVlZGJhY2sgd2lsbCBiZSB2 ZXJ5IHdlbGNvbWUuDQo+DQo+VGhhbmtzIQ0KPg0KPkJlc3QgcmVnYXJkcywNCj5GZXJuYW5kbw0K Pg0KPg0KPg0KPg0KPi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPmRyYWZ0LWdvbnQtb3BzYXdnLWZpcmV3 YWxscy1hbmFseXNpcy0wMC50eHQNCj5EYXRlOiBNb24sIDE0IFNlcCAyMDE1IDE3OjQ5OjQxIC0w NzAwDQo+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+VG86IFBhdWwgRS4gSG9mZm1h biA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPiwgRmVybmFuZG8gR29udA0KPjxmZ29udEBzaTZuZXR3 b3Jrcy5jb20+LCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+LCBGcmVkDQo+ QmFrZXIgPGZyZWRAY2lzY28uY29tPiwgRnJlZCBCYWtlciA8ZnJlZEBjaXNjby5jb20+LCBQYXVs IEhvZmZtYW4NCj48cGF1bC5ob2ZmbWFuQHZwbmMub3JnPg0KPg0KPg0KPkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1nb250LW9wc2F3Zy1maXJld2FsbHMtYW5hbHlzaXMtMDAudHh0DQo+aGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGZXJuYW5kbyBHb250IGFuZCBwb3N0ZWQg dG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1nb250LW9wc2F3Zy1m aXJld2FsbHMtYW5hbHlzaXMNCj5SZXZpc2lvbjoJMDANCj5UaXRsZToJCU9uIEZpcmV3YWxscyBp biBJbnRlcm5ldCBTZWN1cml0eQ0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMDktMTUNCj5Hcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJMTcNCj5VUkw6DQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtb3BzYXdnLWZpcmV3YWxscy1hbmFs eXNpcy0NCj4wMC50eHQNCj5TdGF0dXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZ29udC1vcHNhd2ctZmlyZXdhbGxzLWFuYWx5c2lzLw0KPkh0bWxpemVkOg0KPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250LW9wc2F3Zy1maXJld2FsbHMtYW5h bHlzaXMtMDANCj4NCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRo ZSByb2xlIG9mIGZpcmV3YWxscyBpbiBJbnRlcm5ldCBzZWN1cml0eSwNCj4gICBhbmQgc3VnZ2Vz dHMgYSBsaW5lIG9mIHJlYXNvbmluZyBhYm91dCB0aGVpciB1c2FnZS4gIEl0IGFuYWx5emVzDQo+ ICAgY29tbW9uIGtpbmRzIG9mIGZpcmV3YWxscyBhbmQgdGhlIGNsYWltcyBtYWRlIGZvciB0aGVt Lg0KPg0KPg0KPg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk9QU0VDIG1haWxpbmcgbGlzdA0KPk9QU0VD QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0K DQo= From nobody Mon Oct 5 15:26:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6121A6F13 for ; Mon, 5 Oct 2015 15:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X-QGWIYxe4i for ; Mon, 5 Oct 2015 15:26:55 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFE81A6F3B for ; Mon, 5 Oct 2015 15:26:55 -0700 (PDT) Received: by padhy16 with SMTP id hy16so48553456pad.1 for ; Mon, 05 Oct 2015 15:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nyqPoDUaALAzLWVbH6+/ShjYhktsASJ6XoWPXtf6fm0=; b=Y/JJnE8yd4FIo0Xxu4gJi0eyxOjYufYpCMABExH/fIwhyq4im1cPl6RVo7+slAWPpT LoqSyl/4hp4/0zbPqJiK6S8znFfQOFYTWyFDc1zfpFW8HJB06Gby9vK8YL8knnCNsXv3 OgbreL7B54nMU+90Yd0FZDqcmxO56fXKCTM66prr2GvgsV6jZ0aQ0yLK7FHkjijWuCWp T9yO2tpu2cySopuiFHJ4/iPIC9U8lvdVR8CV43r+V+ByVyZuW9i8yx5Jo4g+Po4bv9jz nNvn8RjStIbgm2Bmb7eNfGvR8ELrADeVqrd6/gds7iMMN+BzheDBhT0crpQasFUk6ABG fNBg== X-Received: by 10.66.142.101 with SMTP id rv5mr41909112pab.25.1444084015364; Mon, 05 Oct 2015 15:26:55 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id l16sm29521080pbq.22.2015.10.05.15.26.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 15:26:53 -0700 (PDT) To: Lorenzo Colitti References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> <0C8D82CD-577C-4C22-B760-D856F8B9B9CF@cisco.com> <560D8520.8000008@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5612F92A.6020107@gmail.com> Date: Tue, 6 Oct 2015 11:26:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 22:26:57 -0000 On 05/10/2015 20:42, Lorenzo Colitti wrote: > On Fri, Oct 2, 2015 at 4:10 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> I think they saw it as a revenue source, and weren't especially thinking >> about the amount of space segment or ship-to-shore microwave they were >> using. >> >> Sure, but in either case it's fundamentally due to a belief that an IP >> address is >> a costly resource, and I think we're trying to say "no it isn't,in IPv6." >> > > No, that's not the same. Just because something doesn't cost anything > doesn't mean people won't try to charge for it. Well yes, that's how capitalism works, but we need the user community to understand that addresses are infinite, and not worth paying for in a free market. Brian From nobody Wed Oct 7 12:30:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E421AD1EC for ; Wed, 7 Oct 2015 12:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTJdiP0_6kd4 for ; Wed, 7 Oct 2015 12:30:44 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3A31AD190 for ; Wed, 7 Oct 2015 12:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1444246243; x=2308159843; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s9Nd5/Ak3VSwo0G+LlkjSjb2JzCj62CPREzwZzRmz7Q=; b=s1pe6NEs5Mk8fOHHG3qn4rzA6f7w42hA+CriCLNLAm2hqA+G6YLXtUMkimeqo33J bixxjeTsPHtoBYxxU3WrLCrgxAipfxnri9t9ky3Rcyn1mGs3B+vpUn7j4Sl42Z0/ y941b3FnsfUtaPaI8agvRypCci7DV4L4vgoupayS+mMw0BoT93sXTe6lOc8Z6PWd /Cxg13aJsPuJdyCLiQBE+Kbb6koNLNkTkDTv16lsan3JSiCJMkP+yJyWAHoe/tFu HDBtLZr4i0Bpix1gn7bCm3QTu0voQJCa6zGgl494XXeNyqDyI6zfUBGqT084x5uc nLGlZ60vODIWIjj1w3U7Pg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 68.57.27532.3E275165; Wed, 7 Oct 2015 12:30:43 -0700 (PDT) X-AuditID: 11973e15-f79fc6d000006b8c-04-561572e314a1 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 78.B7.29597.3E275165; Wed, 7 Oct 2015 12:30:43 -0700 (PDT) Received: from [17.153.69.252] (unknown [17.153.69.252]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NVV007EZ7J61LA0@spicerack.apple.com>; Wed, 07 Oct 2015 12:30:43 -0700 (PDT) Sender: plakhera@apple.com From: Prabhakar Lakhera Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Date: Wed, 07 Oct 2015 12:30:44 -0700 Message-id: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> To: v6ops@ietf.org MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCYpvu4SDTMYMUdFYuXZ98zWZw+tpfZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ+87PYCq4xVVx8MonxgbGCxxdjJwcEgImEjN6Gpgh bDGJC/fWs3UxcnEICexjlPhy8Rg7TNHE/0+YIRKTmSS6Nx2CcpqZJLp2XGcFqRIWkJJY1rUC yObgYBPQkZj5KAPEZBZQl5gyJRekgllAW+LJuwtgFcICHhIdT5JBwiwCqhI37u5lBgnzCthI 3HwSBVEtKHF15jRGEFtEQEhix7MmJogSPYlHnbIQh8lKbH3TygRhP2WV2P9RcwKj0CyEtbOQ rJ2F0LyAkXkVo1BuYmaObmaemV5iQUFOql5yfu4mRlCwTrcT3cF4ZpXVIUYBDkYlHt4AM5Ew IdbEsuLK3EOM0hwsSuK8rgWiYUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY06qetUTcvcMh 5lHx5rhpyKmD8fr5Pdynz7Dd3qd1wHl614lVX7M5X7+XXKL8Rdb9NuMLux3HXu6eNpN93hdx HU/nYyWz9aJttmSzXem/dydwX+dJz71u8vdierlUyroLS/p0jL+ev/yj7IOt3uOXE212dTUl ijTeut7iZKzsN1PYdMLc3FW1SizFGYmGWsxFxYkAAfskxTcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FCsofu4SDTM4OdmJYuXZ98zWZw+tpfZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ+87PYCq4xVVx8MonxgbGCxxdjJwcEgImEhP/P2GG sMUkLtxbz9bFyMUhJDCZSaJ70yFmCKeZSaJrx3VWkCphASmJZV0rgGwODjYBHYmZjzJATGYB dYkpU3JBKpgFtCWevLsAViEs4CHR8SQZJMwioCpx4+5eZpAwr4CNxM0nURDVghJXZ05jBLFF BIQkdjxrYoIo0ZN41CkLcZisxNY3rUwTGPlnIayahWTVLISGBYzMqxgFilJzEist9BILCnJS 9ZLzczcxgsOrMG0HY9Nyq0OMAhyMSjy8P4xFwoRYE8uKK3MPMUpwMCuJ8E7KFA0T4k1JrKxK LcqPLyrNSS0+xCjNwaIkzsucB5QSSE8sSc1OTS1ILYLJMnFwSjUw2qZsS3giu3a5HP+9Gzza UTNSDkS/Cnrl1sL7iou59ABr5IbUtHkT4nrn/l/yqlrH+Na9jPl2LU94Lp1P3r9+7+TFBcU1 nD6/9v8zqi+3ZXz3tjzJq8mFbUXBRqVvS/5sUNvZE7WPW3ab2bmu3sqbTWUvGjm/Rm3UiM7f G9Gd1vDJyHvCz+SdSizFGYmGWsxFxYkAKFfKUysCAAA= Archived-At: Cc: ipv6@ietf.org Subject: [v6ops] RFC 4191: Relevance of Route Information Option for ::/0 prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 19:30:45 -0000 Hi, RFC 4191 implies that Route Information Option can be sent for ::/0. The RFC itself has done well to address/explain, how this RIO of ::/0 = should be handled by a host and how it should override the preference = and lifetime values learned through RA header. However, It is not immediately clear to me as to why should default = route configuration be communicated through two different means in the = same message, i.e. by RA itself and through Route Information Option. It is prone to cause some confusions and bugs in certain implementations = (different devices on the same network working differently). Also from = implementation perspective, sequential processing of message and its = options somewhat gets disrupted, as one has to go back and update the = default route again. It can surely be done but again what=E2=80=99s the = use-case? My be there is some advantage of sending ::/0 in Route Information = Option that I am missing. I am sure folks here will be able to point me to the reasoning behind = it. However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 = to deprecate this option before binary compatibility issues creep in. = The host side processing can also be updated to simply ignore this = option without discarding the message altogether keeping in line with = Postel=E2=80=99s law :).= From nobody Wed Oct 7 14:57:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1071ACEED; Wed, 7 Oct 2015 14:57:16 -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=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZsurS2aG81b; Wed, 7 Oct 2015 14:57:15 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565631A1F20; Wed, 7 Oct 2015 14:57:15 -0700 (PDT) Received: by vkao3 with SMTP id o3so20634207vka.2; Wed, 07 Oct 2015 14:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uCjTstCqkf4DduVuxAknzejJIy7hmo1myTLJLDmKlUM=; b=ojzSdtPwVNjCVf6YG24H9dxah6YbTbz6MMMQQZ3qP5rBMprTPx7rAqIX2NAp213uTT AZ+sQoQw+IFXgTzHalP9LjgzI8Zp3KQUEZbk3Huwb9/TtikIQPtsKaQ9xxA4qJYKMkSx iLLJUnWj3ZHPE2C3LjLEbxvhJMhaJzR/9mZRn8CLy1qeAbrg2dn8Zui9tej/flgGEyB+ inGs3Babzbe3E9CecUjQfyW1d0IDAKnYAQiw8G8YwKL6uCfPpFrJCqEw3eJa+ZyYWTS1 cHQcoTVVtg5Q2raED2jFVUDBYSDQZ5QhJVCxj77mz65LFKGw7EFI9IcPiB+tTZDotznS XYxg== MIME-Version: 1.0 X-Received: by 10.31.56.72 with SMTP id f69mr2598885vka.27.1444255034473; Wed, 07 Oct 2015 14:57:14 -0700 (PDT) Received: by 10.103.77.16 with HTTP; Wed, 7 Oct 2015 14:57:14 -0700 (PDT) Received: by 10.103.77.16 with HTTP; Wed, 7 Oct 2015 14:57:14 -0700 (PDT) In-Reply-To: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> References: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> Date: Thu, 8 Oct 2015 08:57:14 +1100 Message-ID: From: Mark Smith To: Prabhakar Lakhera Content-Type: multipart/alternative; boundary=001a11434a3a4b838d05218ad4ae Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] RFC 4191: Relevance of Route Information Option for ::/0 prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:57:17 -0000 --001a11434a3a4b838d05218ad4ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 Oct 2015 6:30 am, "Prabhakar Lakhera" wrote: > Hi, > Hi, > > RFC 4191 implies that Route Information Option can be sent for ::/0. > > The RFC itself has done well to address/explain, how this RIO of ::/0 should be handled by a host and how it should override the preference and lifetime values learned through RA header. > > However, It is not immediately clear to me as to why should default route configuration be communicated through two different means in the same message, i.e. by RA itself and through Route Information Option. > Support of RIOs is a SHOULD rather than a MUST according to the IPv6 Node Requirements RFC (RFC6434). > It is prone to cause some confusions and bugs in certain implementations (different devices on the same network working differently). Also from implementation perspective, sequential processing of message and its options somewhat gets disrupted, as one has to go back and update the default route again. It can surely be done but again what=E2=80=99s the use= -case? > > My be there is some advantage of sending ::/0 in Route Information Option that I am missing. > I am sure folks here will be able to point me to the reasoning behind it. > > However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 to deprecate this option before binary compatibility issues creep in. The host side processing can also be updated to simply ignore this option without discarding the message altogether keeping in line with Postel=E2=80=99s law= :). > Are you saying deprecating RIOs completely, or just sending of ::/0 in them? It seems like the latter, but I'm not completely sure. Regards, Mark. _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11434a3a4b838d05218ad4ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 8 Oct 2015 6:30 am, "Prabhakar Lakhera" <plakhera@apple.com> wrote:
>

Hi,

> Hi,
>
> RFC 4191 implies that Route Information Option can be sent for ::/0. >
> The RFC itself has done well to address/explain, how this RIO of ::/0 = should be handled by a host and how it should override the preference and l= ifetime values learned through RA header.
>
> However, It is not immediately clear to me as to why should default ro= ute configuration be communicated through two different means in the same m= essage, i.e. by RA itself and through Route Information Option.
>

Support of RIOs is a SHOULD rather than a MUST according to = the IPv6 Node Requirements RFC (RFC6434).

> It is prone to cause some confusions and bugs in certai= n implementations (different devices on the same network working differentl= y). Also from implementation perspective, sequential processing of message = and its options somewhat gets disrupted, as one has to go back and update t= he default route again. It can surely be done but again what=E2=80=99s the = use-case?
>
> My be there is some advantage of sending ::/0 in Route Information Opt= ion that I am missing.
> I am sure folks here will be able to point me to the reasoning behind = it.
>
> However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191= to deprecate this option before binary compatibility issues creep in. The = host side processing can also be updated to simply ignore this option witho= ut discarding the message altogether keeping in line with Postel=E2=80=99s = law :).
>

Are you saying deprecating RIOs completely, or just sending = of ::/0 in them? It seems like the latter, but I'm not completely sure.=

Regards,
Mark.
_______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11434a3a4b838d05218ad4ae-- From nobody Wed Oct 7 17:46:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232221B3173 for ; Wed, 7 Oct 2015 17:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbdin9r8Oo5W for ; Wed, 7 Oct 2015 17:46:33 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BDA1B3171 for ; Wed, 7 Oct 2015 17:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1444265192; x=2308178792; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6L1yociKy3FC1cdBXV6TZtCXo81eH7eh8DS9mVUS1G0=; b=KIIyh0SSlNE2G6lkkqDPGAogtb0szE3ZaXBtZ4ZodfhKH8a+H62OXMoKJznDOlxj 9JOWC55HeMhGIcS+VDBrhknonkf0f9tRaoEiw4wYcnJvxMaXEXa+VsuBP4eXZIKg Oj9dY4dJEHYj0I9efdd0JqkvXE6OtcJJ8O3XYrzQ7/czfI1l7ZvsUTf6MRYHhGBm uWo0Wb+xHvZdXqYoQ70wsVfgWJftVYNzFge+foVEUyFfHeURmaMywCR3oH87x7DJ 4cvOdA1c0amZjTRXmIGGg9qfzqIwO4BhDodyD8wj7TDaGbzefztRZmTxjd0ORKi0 mGc/kEp4jeuyejITWNO3eQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id BC.62.13753.8ECB5165; Wed, 7 Oct 2015 17:46:32 -0700 (PDT) X-AuditID: 11973e13-f79e16d0000035b9-5d-5615bce8a7ab Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id CF.0F.29597.8ECB5165; Wed, 7 Oct 2015 17:46:32 -0700 (PDT) Received: from [192.168.0.19] (c-67-164-22-90.hsd1.ca.comcast.net [67.164.22.90]) by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NVV00DM6M5KFG60@kencur.apple.com>; Wed, 07 Oct 2015 17:46:32 -0700 (PDT) Sender: plakhera@apple.com Content-type: multipart/alternative; boundary=Apple-Mail-48D99020-8E06-4160-BFD6-4CBC9964A859 MIME-version: 1.0 (1.0) From: Prabhakar Lakhera X-Mailer: iPhone Mail (13A332) In-reply-to: Date: Wed, 07 Oct 2015 17:46:32 -0700 Content-transfer-encoding: 7bit Message-id: <53A2B837-835F-4C39-9995-4B1581F26AB1@apple.com> References: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> To: Mark Smith X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FCYpvtij2iYwepWC4uXZ98zWZw+tpfZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZW1edZinYolHxZvYllgbGC4pdjJwcEgImEguX7mCF sMUkLtxbz9bFyMUhJLCPUWLNtPdMMEVPF3xigUi0M0ks/zabGcKZxiSx7M4VZpAqYQEpiWVd K8BGMQvES2x9vJwRxOYVEJd4fXQKI0RNmMSrDT+AVnBwsAnoSMx8lAGxQE7i1PnVYCWcAsES P07+BFvMIqAqcWryM6iRFhId22cyQtjyEpvXvGWGGG8jsfn+cnaIe5oZJVqnHAKbLyKgLvGx jxEkLiFwhk3izpwz7BMYRWYhOW8WkvNmIZkLYWtK7O9ezgJha0ssW/gaKq4h0fltIiuy+AJG 9lWMQrmJmTm6mXmmeokFBTmpesn5uZsYQbE03U54B+PpVVaHGAU4GJV4eH8Yi4QJsSaWFVfm HmKU5mBREufV3SYaJiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx0cZo2RGeiD3rzye/f/3N JnTpCZ0p7MGaLFsce9Lr9Wc3lX/wcr3KUzHh5Yz4NfJl76TlrvsYfquddiQnZw+rxXUPrf+G 3tuX3VkkJrZUtHEiy2vDgOwCI7W68MWvl7K1GM1cILro84zko+9r9n6OcmLa5GStaKK9t2TL ue4jOayOr0ODLqspsRRnJBpqMRcVJwIAsEJIzYYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUiON1OTffFHtEwg8ZLxhYvz75nsjh9bC+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgytq46zVKwRaPizexLLA2MFxS7GDk5JARMJJ4u+MQC YYtJXLi3nq2LkYtDSKCdSWL5t9nMEM40Jolld64wg1QJC0hJLOtawQpiMwvES2x9vJwRxOYV EJd4fXQKI0RNmMSrDT+AJnFwsAnoSMx8lAGxQE7i1PnVYCWcAsESP07+ZAKxWQRUJU5NfgY1 0kKiY/tMRghbXmLzmrfMEONtJDbfX84OcU8zo0TrlENg80UE1CU+9jFOYBScheSiWUgumoVk FIStKbG/ezkLhK0tsWzha6i4hkTnt4msyOILGNlXMQoUpeYkVlroJRYU5KTqJefnbmIEhX5D YdoOxqblVocYBTgYlXh4fxiLhAmxJpYVV+YeYpTgYFYS4d05XzRMiDclsbIqtSg/vqg0J7X4 EONERqCPJzJLiSbnAyMzryTe0MTEwMTY2MzY2NzEnJbCSuK8EW1AFwmkJ5akZqemFqQWwRzF xMEp1cBo0m2zODq4gPOpGdNLpXbPayK2V+qL5Zsnp6t5XP5eGJI7K2Kyeu1xa9+JRacnPK3a I88iwfCc3Uunf/u9ItGJ673YtZVOpgVJH/4wV/r/u63pl698+xaXaLh1zuVbsXY5xZX7I89/ l3T9e/zr5kvXna4mvFtboxxupNhs6LDkkWXlo1LmSi0lluKMREMt5qLiRADjtfMy8AIAAA== Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] RFC 4191: Relevance of Route Information Option for ::/0 prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 00:46:35 -0000 --Apple-Mail-48D99020-8E06-4160-BFD6-4CBC9964A859 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just deprecating the sending of ::/0 in the route information option. > On Oct 7, 2015, at 2:57 PM, Mark Smith wrote: >=20 >=20 > On 8 Oct 2015 6:30 am, "Prabhakar Lakhera" wrote: > > >=20 > Hi, >=20 > > Hi, > > > > RFC 4191 implies that Route Information Option can be sent for ::/0. > > > > The RFC itself has done well to address/explain, how this RIO of ::/0 sh= ould be handled by a host and how it should override the preference and life= time values learned through RA header. > > > > However, It is not immediately clear to me as to why should default rout= e configuration be communicated through two different means in the same mess= age, i.e. by RA itself and through Route Information Option. > > >=20 > Support of RIOs is a SHOULD rather than a MUST according to the IPv6 Node R= equirements RFC (RFC6434). >=20 > > It is prone to cause some confusions and bugs in certain implementations= (different devices on the same network working differently). Also from impl= ementation perspective, sequential processing of message and its options som= ewhat gets disrupted, as one has to go back and update the default route aga= in. It can surely be done but again what=E2=80=99s the use-case? > > > > My be there is some advantage of sending ::/0 in Route Information Optio= n that I am missing. > > I am sure folks here will be able to point me to the reasoning behind it= . > > > > However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 t= o deprecate this option before binary compatibility issues creep in. The hos= t side processing can also be updated to simply ignore this option without d= iscarding the message altogether keeping in line with Postel=E2=80=99s law := ). > > >=20 > Are you saying deprecating RIOs completely, or just sending of ::/0 in the= m? It seems like the latter, but I'm not completely sure. >=20 > Regards, > Mark. > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-48D99020-8E06-4160-BFD6-4CBC9964A859 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just deprecating the sending of ::/0 i= n the route information option.

On Oct 7, 2015, at 2:57 PM, Ma= rk Smith <markzzzsmith@gmail.co= m> wrote:

=
On 8 Oct 2015 6:30 am, "Prabhakar Lakhera" <plakhera@apple.com> wrote:
>

Hi,

> Hi,
>
> RFC 4191 implies that Route Information Option can be sent for ::/0. >
> The RFC itself has done well to address/explain, how this RIO of ::/0 s= hould be handled by a host and how it should override the preference and lif= etime values learned through RA header.
>
> However, It is not immediately clear to me as to why should default rou= te configuration be communicated through two different means in the same mes= sage, i.e. by RA itself and through Route Information Option.
>

Support of RIOs is a SHOULD rather than a MUST according to t= he IPv6 Node Requirements RFC (RFC6434).

> It is prone to cause some confusions and bugs in certain= implementations (different devices on the same network working differently)= . Also from implementation perspective, sequential processing of message and= its options somewhat gets disrupted, as one has to go back and update the d= efault route again. It can surely be done but again what=E2=80=99s the use-c= ase?
>
> My be there is some advantage of sending ::/0 in Route Information Opti= on that I am missing.
> I am sure folks here will be able to point me to the reasoning behind i= t.
>
> However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 t= o deprecate this option before binary compatibility issues creep in. The hos= t side processing can also be updated to simply ignore this option without d= iscarding the message altogether keeping in line with Postel=E2=80=99s law := ).
>

Are you saying deprecating RIOs completely, or just sending o= f ::/0 in them? It seems like the latter, but I'm not completely sure.

Regards,
Mark.
_______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.iet= f.org/mailman/listinfo/v6ops

= --Apple-Mail-48D99020-8E06-4160-BFD6-4CBC9964A859-- From nobody Thu Oct 8 00:20:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0BC1B2AB4; Thu, 8 Oct 2015 00:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFBIrLYZKnTM; Thu, 8 Oct 2015 00:20:34 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4541E1B2AAF; Thu, 8 Oct 2015 00:20:34 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id C3E40D789E; Thu, 8 Oct 2015 00:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=P6KaZzxlnejsuglqWIHglG0bG/k=; b= sthYQkn1q5mYWCPxNNEYLkA5dxIGZtQsCkQoi7UoYO9AP42ueGAwN25DSS73gQ7W lyqS+svC6HnsT9czMQYhEUJcHQkN26mVeyDUz1t6Nep0hW6S88v160O5/AEYZUKR HBGbUXREtTNfabHoXExNilksIglfTQhoxdN7mpCHo8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=sOVjJHD2zlKeHTs0XtCjP3eHux J05bvRYZTDei+doj8p+B80juQCq6nJoupyqiqJEXkUjBgbs6Rpxdoimyh+4sRAq1 Nxw1tz9Tbt6R8+h23EXD7H3hv77ax2RDlTEA0o8ntEozv4raRGdoRA+TAZJq+P0+ pNibebIVRUBNOEZ6Q= Received: from h.hanazo.no (unknown [173.38.220.47]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 94B7DD7883; Thu, 8 Oct 2015 00:20:32 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9340C5A0DC2; Thu, 8 Oct 2015 09:20:30 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AA75BD2E-F62D-4B6E-881A-9DA6BB4B4DA5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> Date: Thu, 8 Oct 2015 09:20:29 +0200 Message-Id: <5B439290-490E-4076-96FB-2394063292B2@employees.org> References: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> To: Prabhakar Lakhera X-Mailer: Apple Mail (2.3094) Archived-At: Cc: v6ops@ietf.org, 6man WG Subject: Re: [v6ops] RFC 4191: Relevance of Route Information Option for ::/0 prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 07:20:35 -0000 --Apple-Mail=_AA75BD2E-F62D-4B6E-881A-9DA6BB4B4DA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Prabhakar, > RFC 4191 implies that Route Information Option can be sent for ::/0. >=20 > The RFC itself has done well to address/explain, how this RIO of ::/0 = should be handled by a host and how it should override the preference = and lifetime values learned through RA header. >=20 > However, It is not immediately clear to me as to why should default = route configuration be communicated through two different means in the = same message, i.e. by RA itself and through Route Information Option. >=20 > It is prone to cause some confusions and bugs in certain = implementations (different devices on the same network working = differently). Also from implementation perspective, sequential = processing of message and its options somewhat gets disrupted, as one = has to go back and update the default route again. It can surely be done = but again what=E2=80=99s the use-case? >=20 > My be there is some advantage of sending ::/0 in Route Information = Option that I am missing. > I am sure folks here will be able to point me to the reasoning behind = it. >=20 > However if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 = to deprecate this option before binary compatibility issues creep in. = The host side processing can also be updated to simply ignore this = option without discarding the message altogether keeping in line with = Postel=E2=80=99s law :). this exact point is explained in section 5.1 of 4191. cheers, Ole --Apple-Mail=_AA75BD2E-F62D-4B6E-881A-9DA6BB4B4DA5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWFhk+AAoJEL7aWKiYQt92AxwP/iyb+DSArqBtWZ/Zu0BuqQDN P0R7LX3DFCou/445xKDrCa3foBXK0RV1VjEv+ju7sfb/wHu8rzed8Kd2VQpd65TL mM7yd921TTzpyOL4Sikm/LjYXrev91ID6vpicoiGeJw6fBd/fnlPMuSeEY5DalEv 71D4OKOhg8KnWDjG4Cl9780u7B7YkwsM+zu507BQxEEPEdMMetpaWwhBVwl6brpP +NKYLTd4faCaM7DHyF295aEnRAqqYCC0CUNgICSRoDA5DeeV3aeIi6p6XjJtjRPI r4Uv5IMERafBpMtjcqqI1fvBtd0q+B1Uz2sPPI1WeFwPAMqUM+iheahs/MxHXO4y OKhrHwmtL3n+skokpfEjZTQrJ6h5UCs8IYQUPHgg0N+Tu/RZPSGMt0L8ey96dhUG 1U70PMVJLR/fF7UwJkBFnGfkR/MsccCaxs9QV+857PMCR/APCtLB4Dty1Fxyhy+Y UNrb9G89QZvibwL5SLK8v4x6phgk4SNTDiKSDC3Spl8R0B9d7joeNTb0SfhisVMb SUAdURRZfP70fAwg8hREmfMBHVGydERGji7tLCtig0L2joZN9eMjaGCd/4ASdUFp Uf0YshQWpT2grW64UIEIrQxX6cU84puTtVJ5tx9P1UCNW25/4jZtLSEi5pLacR7C JDlzKvLZkcETvZZfzGF0 =Am8W -----END PGP SIGNATURE----- --Apple-Mail=_AA75BD2E-F62D-4B6E-881A-9DA6BB4B4DA5-- From nobody Thu Oct 8 13:41:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45581ACDAB for ; Thu, 8 Oct 2015 13:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7OMHzzpF9IV for ; Thu, 8 Oct 2015 13:41:26 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE3A1ACDBD for ; Thu, 8 Oct 2015 13:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1444336886; x=2308250486; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gpvv48SkN5q7lakFdPfvT6Zm3pINtbIJDDWIFyZUNFk=; b=zqoru//AqAR8w9QNj24+jpagu4rJh9VmwapmIea/AsppXgjNt9IbUwJsZUqf41OU zn5QJQM8MiR8Y14oUFFlb71/Haf9TznlVTj4E4kdNvHk54fwryP/5rJ1P46g5MWc dfOL+MixXe1yR0wzJk+KL0Nti3FQ8HdhzZ+te5jrGyJuSVvQAgzdZas2HKRxmxmO 0xdAPEDF9opMMvegiUL6J6dY0/hrtQ+jPGK1bUSxmplKIEerlNc1rpmfGW8VpCVS AHUclSFByp2Zr05Nqm4bWqxackPl3gEdbutSC6u2m3Xmgqyo9W/hTTE9ENbidtz4 Gu3NuZiVtFvR/5QEHybRnA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id E2.8A.27532.5F4D6165; Thu, 8 Oct 2015 13:41:25 -0700 (PDT) X-AuditID: 11973e15-f79fc6d000006b8c-f7-5616d4f531cc Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 73.FE.29597.5F4D6165; Thu, 8 Oct 2015 13:41:25 -0700 (PDT) Received: from da0602a-dhcp239.apple.com (da0602a-dhcp239.apple.com [17.226.23.239]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NVX00KWP5H1MD50@spicerack.apple.com>; Thu, 08 Oct 2015 13:41:25 -0700 (PDT) Sender: plakhera@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_4CBF2E7C-5C04-4244-A34C-1E2F8490070D" MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Prabhakar Lakhera In-reply-to: <5B439290-490E-4076-96FB-2394063292B2@employees.org> Date: Thu, 08 Oct 2015 13:04:55 -0700 Message-id: <06E4ABF6-4EE5-4432-925B-00DB6CAD778C@apple.com> References: <5A93C618-A5C5-4649-979A-259732E8696E@apple.com> <5B439290-490E-4076-96FB-2394063292B2@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCYpvv1iliYwZFTVhYvz75nsjh9bC+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyZn3ZxFqwyrmi40Q/ewPjU8suRk4OCQETiS8ztrBD 2GISF+6tZ+ti5OIQEtjHKDFhynoWmKKOk7NYIRKTmST+HWqGchYySVx7fBGsXVhASmJZ1wpW EJtZIEli6a5ZQKM4OHgF9CQedcpClIRJvNrwAyzMJqAjMfNRBkiYU8BRYn/zGkYQm0VAVeLA vWNMICXMAtoSr//VQAyxkdjZ4ApSISRQLLG04TcziC0iICGxesYLqCtlJba+aWUCOUxCYAqb xIrPX1gmMArPQnLPLIR7IMLaEssWvmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypGodzEzBzdzDwz vcSCgpxUveT83E2MoJiYbie6g/HMKqtDjAIcjEo8vAvsxMKEWBPLiitzDzFKc7AoifNuWA0U EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDjHe4qkferJ+KsJNztX5jaXJciuL7llJp/kKGFt vUZGTeRnZeCMiMtq5975KOgxZEu43Vj+uWtG+QZuM4bY4N9zdi48MWnaz9X/0q679Itl94t2 +pV9XRq9O1DqRFbhi/zL+bGO8/+brfiRc9XNqEFZ4fgZl4o21qgtaS1THv1q3uLS8fEAtxJL cUaioRZzUXEiAFQjOaBqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUi2FCsofv1iliYwfKp5hYvz75nsjh9bC+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyZn3ZxFqwyrmi40Q/ewPjU8suRk4OCQETiY6Ts1gh bDGJC/fWs3UxcnEICUxmkvh3qJkVwlnIJHHt8UV2kCphASmJZV0rwDqYBZIklu6aBdTBwcEr oCfxqFMWoiRM4tWGH2BhNgEdiZmPMkDCnAKOEvub1zCC2CwCqhIH7h1jAilhFtCWeP2vBmKI jcTOBleQCiGBYomlDb+ZQWwRAQmJ1TNesEBcKSux9U0r0wRGgVlITpiFcAJEWFti2cLXzBC2 psT+7uUsmOIaEp3fJrIuYGRbxShQlJqTWGmhl1hQkJOql5yfu4kRHMKFaTsYm5ZbHWIU4GBU 4uFdYCcWJsSaWFZcmXuIUYKDWUmEN2AbUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvRJtomJBA emJJanZqakFqEUyWiYNTqoExtl1O53xkwQV7je89ur6L+2/8uLxgjemqgGc7/he/qW5W5yx5 2Tnvn/3SRxm8cq7LQxumft0ddzhA4U/MkyNnhY5c/VHcuMuYmVVI7leyhe38A54np325fOPT drZ1u0rmnTKxCVjsmpbgmiaUFBX0VvRxaOGklyc7H8dpNUmJ5jJf4WfkkspXYinOSDTUYi4q TgQAGqvLTF0CAAA= Archived-At: Cc: v6ops@ietf.org, 6man WG Subject: Re: [v6ops] RFC 4191: Relevance of Route Information Option for ::/0 prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 20:41:28 -0000 --Apple-Mail=_4CBF2E7C-5C04-4244-A34C-1E2F8490070D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ole, Many thanks for pointing me to that section! I re-read it (more carefully this time) and it cleared the mist for me. = I now understand the use case it is trying to address. Cheers! > On Oct 8, 2015, at 12:20 AM, otroan@employees.org = wrote: >=20 > Prabhakar, >=20 >> RFC 4191 implies that Route Information Option can be sent for ::/0. >>=20 >> The RFC itself has done well to address/explain, how this RIO of ::/0 = should be handled by a host and how it should override the preference = and lifetime values learned through RA header. >>=20 >> However, It is not immediately clear to me as to why should default = route configuration be communicated through two different means in the = same message, i.e. by RA itself and through Route Information Option. >>=20 >> It is prone to cause some confusions and bugs in certain = implementations (different devices on the same network working = differently). Also from implementation perspective, sequential = processing of message and its options somewhat gets disrupted, as one = has to go back and update the default route again. It can surely be done = but again what=E2=80=99s the use-case? >>=20 >> My be there is some advantage of sending ::/0 in Route Information = Option that I am missing. >> I am sure folks here will be able to point me to the reasoning behind = it. >>=20 >> However if there=E2=80=99s no strong case for ::/0, I propose RFC = 4191 to deprecate this option before binary compatibility issues creep = in. The host side processing can also be updated to simply ignore this = option without discarding the message altogether keeping in line with = Postel=E2=80=99s law :). >=20 > this exact point is explained in section 5.1 of 4191. >=20 > cheers, > Ole --Apple-Mail=_4CBF2E7C-5C04-4244-A34C-1E2F8490070D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ole,

Many thanks for pointing me to that section!
I re-read it (more carefully this time) and it cleared the = mist for me. I now understand the use case it is trying to = address.

Cheers!

On Oct 8, 2015, at 12:20 AM, otroan@employees.org = wrote:

Prabhakar,

RFC 4191 = implies that Route Information Option can be sent for ::/0.

The RFC itself has done well to = address/explain, how this RIO of ::/0 should be handled by a host and = how it should override the preference and lifetime values learned = through RA header.

However, It is not = immediately clear to me as to why should default route configuration be = communicated through two different means in the same message, i.e. by RA = itself and through Route Information Option.

It is prone to cause some confusions and bugs in certain = implementations (different devices on the same network working = differently). Also from implementation perspective, sequential = processing of message and its options somewhat gets disrupted, as one = has to go back and update the default route again. It can surely be done = but again what=E2=80=99s the use-case?

My = be there is some advantage of sending ::/0 in Route Information Option = that I am missing.
I am sure folks here will be able to = point me to the reasoning behind it.

However = if there=E2=80=99s no strong case for ::/0, I propose RFC 4191 to = deprecate this option before binary compatibility issues creep in. The = host side processing can also be updated to simply ignore this option = without discarding the message altogether keeping in line with = Postel=E2=80=99s law :).

this exact point is = explained in section 5.1 of 4191.

cheers,
Ole

= --Apple-Mail=_4CBF2E7C-5C04-4244-A34C-1E2F8490070D-- From nobody Fri Oct 9 03:25:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498151A8AAE; Fri, 9 Oct 2015 03:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78aoGP_iibxw; Fri, 9 Oct 2015 03:25:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 287FF1A8AAD; Fri, 9 Oct 2015 03:25:41 -0700 (PDT) Received: from 17-182-245-190.fibertel.com.ar ([190.245.182.17] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZkUrl-0005m9-HF; Fri, 09 Oct 2015 12:25:34 +0200 To: "Eric Vyncke (evyncke)" , "opsawg@ietf.org" References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56179631.8060803@si6networks.com> Date: Fri, 9 Oct 2015 07:25:53 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Internet Area , tsvwg , draft-gont-opsawg-firewalls-analysis@tools.ietf.org, "'opsec@ietf.org'" , TSV Area Subject: Re: [v6ops] [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 10:25:45 -0000 Hi, Eric, Thanks so much for your feedback! Please find my comments in-line.... On 10/05/2015 12:57 PM, Eric Vyncke (evyncke) wrote: > Fernando, Fred and Paul, > > Sorry for belated reply, here are a couple of comments: > > The title is a little ambiguous IMHO it is "On Firewalls in Security" > (because they also apply inside an 'intranet') or "On Firewalls in > Internet Protocol (IP) Security" or "On firewalls and Security of the > Internet" ? How about "On Firewalls in Network Security"? > The introduction looks more like an history, so should perhaps be renamed? How about splitting the historical part into a stand-alone section renamed as "Firewalls in the IETF" or the like? > Terminology section should perhaps appear more like an usual terminology > section and not as a free-form text? mm.. I guess that from the current contents we can define "firewall" and "perimeter"? > Section 3.2 (end to end principle) is interesting but is a little complex > to read. Any suggestions on how to improve the text? > Section 3.3, unsure whether I am reading it correctly but I don't agree > with the statement that firewall can protect the (network) infrastructure > against DoS attack (as hinted by "message volume overwhelms"). Rate > limiters or DoS scrubbing devices do not qualify as 'firewall' IMHO. Could you elaborate a bit? e.g., why wouldn't a rate-limited qualify as a firewall? > I think section 3.4 (a good one) rather belongs to section 4 and should > align the taxonomy. Yep. Looks like we could move this into the base Section 4. (Or were you meaning something else?) > Section 4.1, split the first paragraph in two parts. The second one being > the example given => to make it clear that the "sessions may never be > initiated from the outside" belongs to the example only OK, will do. > Section 4.1, 2nd paragraph, the word 'testing' has an active tone in my > (non native) English, why not using a more passive verb such as "inspect" > or "check" ? Agreed. Will do. > Section 4.1, at the risk of appearing as 'purist', I would move the NAT > section from this section and create one on this topic. Please let me think about this one. f you have any suggestions regarding whre in the I-D you'd put such a section, please let me know. > Section 4.2, or rather the perimeter exists but it very very small : one > physical link :-) or wider: one logical perimeter without any strict > geographical boundaries. Yes. :-) > Section 4.2, should make it clear that the 'tagging' is required (being > IEEE 802.1Q VLAN tag or ...), OK. > and, the end of the section is rather > negative on this specific FW. I see... any hints for improvement? > Section 4.3, I like it of course :-), and I agree there are now scalable > algorithm to detect anomalies even with a single node (thanks to > self-learning :-)) Could you elaborate a bit? :-) > Section 4.3, "Reputation databases have a bad reputation" is a fun > sentence :-) Indeed! :-) > Section 5, I would also use the words of white and black lists as they are > well-known. I wonder also why there is a specific section 5.1 without a > section 5.2? Section 5.2 was forthcomming... (will hopefuly be there in version -01 of the I-D) > I would remove this heading and keep the text. Don't forget > to mention HTTP 2.0 & works such as QUIC. Will do. > Section 6, should also mention that FTP & SIP can be used for dynamic > ports. Will do. > It should also mention/repeat that port 80 is not only about HTTP > but for many protocols 'tunneled' over HTTP. Will do. > Section 6, temporary addresses are indeed annoying in some cases but IP > addresses can also be spoofed. What we meant here is that things like IPv6 temporary addresses change such assumption. But yes, we should comment on spoofing. > Should mention anti-spoofing? And/or IPSEC > AH? Anti spoofing in terms of RPF, or something else? > Section 7 is about layer-3/layer-4 'packet filtering' which is a specific > kind of firewalls while the I-D title appears to be more generic. I > suggest to keep the section but make title more specific and add some > introduction sentences to this section. Good grief! Will do. > Section 8, kind of repeats a former point... Useful text but should unify > and at a single location You mean with Section 4.1? > Section 10 is of course looking for heated comments from the community... [FWIW, Section 10 will be split into a different document... such that the heat happens elsewhere :-) ] > Here are a couple: > - wonder whether the IETF could have recommendations for all cases? Certainly not for all -- but better to have something covered, than nothing :-) > Moreover, situation will probably continue to evolve > - zone-based should also allow ICMP inbound ;-) .... if they relate to an ongoing session? > There are also important (IMHO) topics MISSING: > - more and more traffic are encrypted, good for privacy, bad for firewalls > as they are blind now and mostly useless Yes and no. If you mean TLS, it prevents DPI, but still allows for filtering based on port numbers... > - recommendation for NOT BLOCKING traffic over the Internet (except to > each ISP own infrastructure)? not blocking which sort of traffic? > - logging / auditing function is missing (talking about security here) > - logging of event is missing (talking about operation here) Do you mean in the recommendations section, or elsewhere? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 9 17:12:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10E1B4FDD for ; Fri, 9 Oct 2015 17:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcbAaHXGXVXy for ; Fri, 9 Oct 2015 17:12:42 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9131B4FDB for ; Fri, 9 Oct 2015 17:12:42 -0700 (PDT) Received: by igcpe7 with SMTP id pe7so47301432igc.0 for ; Fri, 09 Oct 2015 17:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=C3+McVZpZ3ClOuhmjbjQRjWIo7u7S9E7/GXV9SexHoU=; b=DRDpsqywJQTWYQNiTxSc86rf+VH2AfWigI8FHzmtQWSez8CmZTCVRqMzK67Wbcgkxo bFSdaj3viykccHJ3FeDZTzX3/7AVm2CZW8pMjO+tDkQko8diy178VaX78Pr5zY5LjEfl L2qfb1wNVzDUZeJfTRgxW81y11FIc5KnF6hjGCV29EksJ3Pzukc1/7B1whc1MLbSj68+ DAg2EEdse12CrakchAuS0NHCHdQKiNTv/Zi9frrx2K4Uh+ewb4SXgeARg/Z9+qeHfiv3 TBl4/D3ugGHxd/0M9ttypZONlN9y70JA1okGAEEcKpqNUYmTPdFT6+8Wyaf8cK9AmYSm jZ/A== X-Gm-Message-State: ALoCoQm7HSBAdSAyE39TxqLHq6FuConiXx542ghE93UIiHMAnRY+0jGuFX+MhIb3pTbBMciEslka MIME-Version: 1.0 X-Received: by 10.50.73.8 with SMTP id h8mr2266221igv.94.1444435961348; Fri, 09 Oct 2015 17:12:41 -0700 (PDT) Received: by 10.107.128.94 with HTTP; Fri, 9 Oct 2015 17:12:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Oct 2015 17:12:41 -0700 Message-ID: From: Tom Herbert To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 00:12:43 -0000 > > Why did you not consider LISP (rfc6830) as a solution to your problem? > Is it because LISP is an overlay and you preferred native transport? > Your document does overlay IPv4 data in an IPv6 tunnel and thus the > ipv4 solution could just as well use LISP? > LISP, along with many other methods that could implement an overlay network (GUE, VXLAN, IPIP, SIT, GRE, etc.), is an encapsulation protocol. In ILA we avoid encapsulation, and so it should provide the best performance and compatibility with networking HW for implementing an overlay. As discussed in the draft there are limitations-- this is only for encapsulating L3 and it's not extensible for things like securing a virtual network identifier. The IPv4/IPv6 translation (not as tunneling) actually solves another problem in network virtualization. Consider a data center that is providing multi-tenant network virtualization, where tenants are IPv4 and use private addresses in 10/8. We would like to implement a common service in the data center at some public IP address. Because client addresses are not guaranteed to be unique, at the server either we need to run an instance for each tenant virtual network, or use NAT to make the client's source IPv4 address reachable back to the machine it is running on. With ILA, we would allow the client to connect to an IPv4 address, but at the server this would be IPv6. The client's address as seen by the server would indicate both the virtual networking identifier assigned to the client and virtual address. So the client is unambiguously identifiable at the server, and this also allows the client to be migrated without breaking the connection. Tom From nobody Sun Oct 11 10:56:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EE21B2C15 for ; Sun, 11 Oct 2015 10:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU9s-MecTilQ for ; Sun, 11 Oct 2015 10:56:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D908D1B2C14 for ; Sun, 11 Oct 2015 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2865; q=dns/txt; s=iport; t=1444586169; x=1445795769; h=from:to:subject:date:message-id:references:mime-version; bh=NUZ8kfgkVEYmTrnlQViJeJ5Kk0u9XGo0PE1+QSEC5v0=; b=itSlST/yr/OqikVoVXLhES++O1unMXR3YsvioP2NcTm8ehtlUS2+dcVC wmXzvxDoIKcPHBKfV0eu0Q7R4pnIywjVo5bhCmxm5sZRFidqRgOn7ViMV Hh4Xl3buOKd38WMBSezjpPQHrExEi0mnmTcRzft9RFK1iACVsBzRzOfqC U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgAwAMohpW/4YNJK1egyZUbga9bA6BWiGCcoIKfwKBGDgUAQEBAQEBAYEKhCYBAQEDAXcHCwIBGQMBAi8yGwIIAgQTDogYCA2/RQEBAQEBAQEBAQEBAQEBAQEBAQEBGIkDgm6EfB6DFIEUBY0NiQYBgk2BYWqIAYFYSINylXABHwFDhAJxAYZjgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,667,1437436800"; d="asc'?scan'208";a="36502868" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2015 17:56:08 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9BHu7nJ026989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 11 Oct 2015 17:56:07 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 11 Oct 2015 12:55:56 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Sun, 11 Oct 2015 12:55:55 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: New Version Notification for draft-bao-v6ops-rfc6145bis-02.txt Thread-Index: AQHRA8a/jYJOSR8F8UOrpcLacS8qaw== Date: Sun, 11 Oct 2015 17:55:55 +0000 Message-ID: References: <20151011014717.17513.49653.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.215.97] Content-Type: multipart/signed; boundary="Apple-Mail=_65502F4C-26FF-49B9-AF8D-80BA3B9BB6B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-bao-v6ops-rfc6145bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 17:56:10 -0000 --Apple-Mail=_65502F4C-26FF-49B9-AF8D-80BA3B9BB6B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. Any more commentary? > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-bao-v6ops-rfc6145bis-02.txt > Date: October 10, 2015 at 6:47:17 PM PDT > To: Fred Baker , Tore Anderson = , Fernando Gont , = Congxiao Bao , Xing Li >=20 >=20 > A new version of I-D, draft-bao-v6ops-rfc6145bis-02.txt > has been successfully submitted by Xing Li and posted to the > IETF repository. >=20 > Name: draft-bao-v6ops-rfc6145bis > Revision: 02 > Title: IP/ICMP Translation Algorithm (rfc6145bis) > Document date: 2015-10-10 > Group: Individual Submission > Pages: 38 > URL: = https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc6145bis-02.txt > Status: = https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/ > Htmlized: = https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-bao-v6ops-rfc6145bis-02 >=20 > Abstract: > This document describes the Stateless IP/ICMP Translation Algorithm > (SIIT), which translates between IPv4 and IPv6 packet headers > (including ICMP headers). This document updates RFC 6145. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_65502F4C-26FF-49B9-AF8D-80BA3B9BB6B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVhqi10ayAOS/EQ8MAQJscBAAkPpFg7A1iIxWrmUaMk82WxY5VQiW45cY 8mEbIk/k4L0NyUbr0ZigpTdHEs+yjC/83k+lB1hX2oNNi2/+6ZElCG4CDBbG+iMt yXopYfr24Kjz/qxd5LuPwrASK+UMvNWo4FROjfJ1H3YMnqLBzMdQHgFnB2MSC65i TUsD9T66uxNGti7D2UVf+F05O5Ku7pMaIgZqwqGGlsB2kTThGNWuycfSU3HhiLpJ axghtWJTD/UmVbGSTb2qFarS57CmPvGCEDsU40QPvwegFtoQiuLtcmQYCqhdllVA XQOq+NkuVBbuwp9YSguG38GBXs/N23xWxVhK6AjscD9uCEyTXNvsbqS1OlI86FjO F2azPjCsgNIpoD9MO9G7UM5/TkbGaQ9n8/bXXcXnk4lfjzlLkaLr/HbeWFRrxSB3 bGrNrX31YbWSelf0V6sz3ftIpQ+yEd/xOLQMX/LkIieOKgTEkHKjhE+n09+DS7Nd 328plC+5r1/84r8UoBuaxlGjctih+OQ9mlxBW4ktglh8r53QVencCRQK+KdEQ8rT jL/r++pkBdr0jzbbJCuD1QE6VZ4CLg5qakj4ycx19k8a9m2h7apP28BDUP0ZH152 6MUnOgs+5Uv6PQhZp8XWxm4omElJZeXZ2BVdT6RcB2saCS04YJ5zRJAdEkY+SjGQ 3KjTkHvML/0= =84Sm -----END PGP SIGNATURE----- --Apple-Mail=_65502F4C-26FF-49B9-AF8D-80BA3B9BB6B9-- From nobody Mon Oct 12 04:59:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B198D1ACEFF; Mon, 12 Oct 2015 04:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x36-6BjEl_ga; Mon, 12 Oct 2015 04:58:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F341ACF0A; Mon, 12 Oct 2015 04:58:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012115856.7960.17022.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 04:58:56 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-eam-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 11:59:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Explicit Address Mappings for Stateless IP/ICMP Translation Authors : Tore Anderson Alberto Leiva Popper Filename : draft-ietf-v6ops-siit-eam-02.txt Pages : 18 Date : 2015-10-12 Abstract: This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-eam-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-eam-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 12 05:42:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34F81B2A22; Mon, 12 Oct 2015 05:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_efB_xL1TB1; Mon, 12 Oct 2015 05:42:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CB61B2A2A; Mon, 12 Oct 2015 05:42:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012124238.3369.39641.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 05:42:38 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:42:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments Author : Tore Anderson Filename : draft-ietf-v6ops-siit-dc-03.txt Pages : 23 Date : 2015-10-12 Abstract: This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-dc-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 12 05:45:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1021B2A38; Mon, 12 Oct 2015 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aP-GXX-hnDG; Mon, 12 Oct 2015 05:45:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3161B2A3F; Mon, 12 Oct 2015 05:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012124509.2451.40082.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 05:45:09 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-2xlat-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:45:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : SIIT-DC: Dual Translation Mode Authors : Tore Anderson Sander Steffann Filename : draft-ietf-v6ops-siit-dc-2xlat-02.txt Pages : 17 Date : 2015-10-12 Abstract: This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency. The reader is expected to be familiar with the SIIT-DC architecture described in I-D.ietf-v6ops-siit-dc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-dc-2xlat-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 12 07:37:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1E1B33AD for ; Mon, 12 Oct 2015 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6hZ2gEcLHWz for ; Mon, 12 Oct 2015 07:37:51 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EE71B33AC for ; Mon, 12 Oct 2015 07:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8764; q=dns/txt; s=iport; t=1444660671; x=1445870271; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=14jgqT3FyUQxod3Vyv5ifUhI/HfYqMpkGDFwIQaZQ2g=; b=LWg0udLZocqALpatMWIg8qR4+4gM/FplOfL1nntuiUDTvvCj0ZkPbtfM T6MGsult5dcmBKbGpygHcdAfprrpH+IQLVrpTjOa5Ssl/28EXJF6OxYfk xOFi5KI6qzNV5O3agbh5rNF9/W5a7z2VWM2ZLtA0R8tZpFm7SPC3OY6WB U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXDQBnxBtW/5BdJa1dDgUBAYMRVGwCBppokgeRDg6BWhcKgnKCCn8CRWw4FAEBAQEBAQGBCoQmAQEBAwEBAQEgKAEiCwULAgEGAhECAQECAScDAgIhBAILFAkIAgQOBQ6ICwMKCA2NJp02hW0BiDUNhH0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiQOCboJQgiwRBwaCYzGBFAWNDYVHgz8Bgk2BYWqGDYF0gVhIg3KNKX+HSAEfAUOCDAIDHYEWPnEBhmOBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,673,1437436800"; d="asc'?scan'208";a="196572497" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2015 14:37:50 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9CEbo4x031267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2015 14:37:50 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Oct 2015 09:37:37 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Mon, 12 Oct 2015 09:37:38 -0500 From: "Fred Baker (fred)" To: Xing Li Thread-Topic: [v6ops] Regarding 6145bis Thread-Index: AQHQ/xpoRY1qu9BVOkiS8vOrU3UpU55mayAAgAHhn4A= Date: Mon, 12 Oct 2015 14:37:38 +0000 Message-ID: <5465F885-AE86-4231-B8A7-9F0347519621@cisco.com> References: <010C6DA6-51CB-49D3-A389-7867B5DD2860@cisco.com> <560FA348.4060502@cernet.edu.cn> <7992AF2D-5DF6-48AC-B89A-AE3E012E3CAB@cisco.com> <561A31BA.6000705@cernet.edu.cn> In-Reply-To: <561A31BA.6000705@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.59] Content-Type: multipart/signed; boundary="Apple-Mail=_2AD5B6DB-CF89-457D-B792-9DCDDB94544D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Regarding 6145bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:37:53 -0000 --Apple-Mail=_2AD5B6DB-CF89-457D-B792-9DCDDB94544D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. > On Oct 11, 2015, at 2:54 AM, Xing Li wrote: >=20 > Hi, Fred and All, >=20 > We have upddate the 6145bis according to Alberto's comments. >=20 > http://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/ >=20 > Regards, >=20 > xing >=20 >=20 > Fred Baker (fred) =E5=86=99=E9=81=93: >> Sounds good. >>=20 >>=20 >>> On Oct 3, 2015, at 2:43 AM, Xing Li wrote: >>>=20 >>> Hi, Fred and All, >>>=20 >>> Thanks. If there are no other comments, we will update the draft = 6145bis in the next couple of days. >>>=20 >>> Best regards, >>>=20 >>> xing >>>=20 >>>=20 >>>=20 >>>> Our status at this instant is as follows. >>>>=20 >>>> - waiting for an update of draft-bao-v6ops-rfc6145bis in response = to a comment yesterday >>>>=20 >>>>=20 >>>>=20 >>> Fred Baker =E5=86=99=E9=81=93: >>>=20 >>>> Looks like we got another comment. >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> *From: *Alberto Leiva > >>>>> *Subject: **[v6ops] Regarding 6145bis* >>>>> *Date: *September 30, 2015 at 2:32:09 PM PDT >>>>> *To: *v6ops@ietf.org >>>>>=20 >>>>>=20 >>>>>> Fragmented ICMP/ICMPv6 packets will not be translated by the = IP/ICMP >>>>>> translator. >>>>>>=20 >>>>> Is this due to some security concern? >>>>>=20 >>>>> I can see why fragmented pings can't be handled by a stateless = translator, due to the need to add or remove the ambiguous layer 4 = length to/from the ICMP checksum's pseudoheader, but a Stateful NAT64 = that collects fragments does have access to this information (and is not = difficult or slow to handle). >>>>>=20 >>>>> I suggest: >>>>>=20 >>>>> Fragmented ICMP/ICMPv6 packets will not be translated by = stateless >>>>> IP/ICMP translators. Such packets MAY be translated by stateful = IP/ICMP >>>>> translators. >>>>>=20 >>>>>=20 >>>>>> An IP/ICMP translator has two possible modes of operation: = stateless >>>>>> and stateful [RFC6144]. In both cases, we assume that a system = (a >>>>>> node or an application) that has an IPv4 address but not an IPv6 >>>>>> address is communicating with a system that has an IPv6 address = but >>>>>> no IPv4 address, or that the two systems do not have contiguous >>>>>> routing connectivity and hence are forced to have their >>>>>> communications translated. >>>>>>=20 >>>>> Take this with a grain of salt (I'm aware it makes it less = elegant). >>>>>=20 >>>>> "OR they might have contiguous routing connectivity but are = interacting via masking addresses (ie. hairpinning)." >>>>>=20 >>>>> Right? >>>>>=20 >>>>>=20 >>>>>> the translator MAY provide a configuration function for the = network >>>>>> administrator to adjust the threshold of the minimum IPv6 MTU to = a >>>>>> value that reflects the real value of the minimum IPv6 MTU in the >>>>>> network (greater than 1280 bytes). >>>>>> The translator MUST provide a configuration >>>>>> function for the network administrator to adjust the threshold of = the >>>>>> minimum IPv6 MTU to a value greater than 1280-byte if the real = value >>>>>> of the minimum IPv6 MTU in the network is known to the = administrator. >>>>>>=20 >>>>> This is a MAY, then a MUST. What's happening? >>>>>=20 >>>>>=20 >>>>>> If the DF flag is not set and the IPv4 packet will result in an = IPv6 >>>>>> packet larger than 1280 bytes, the packet SHOULD be fragmented so = the >>>>>> resulting IPv6 packet (with Fragment Header added to each = fragment) >>>>>> will be less than or equal to 1280 bytes. For example, if the = packet >>>>>> is fragmented prior to the translation, the IPv4 packets should = be >>>>>> fragmented so that their length, excluding the IPv4 header, is at >>>>>> most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the >>>>>> Fragment Header). The translator MUST provide a configuration >>>>>> function for the network administrator to adjust the threshold of = the >>>>>> minimum IPv6 MTU to a value greater than 1280-byte if the real = value >>>>>> of the minimum IPv6 MTU in the network is known to the = administrator. >>>>>> The resulting fragments are then translated independently using = the >>>>>> logic described below. >>>>>>=20 >>>>> Especially if you decide to MUST the requirement above, why not = declare it as a variable from the start? >>>>>=20 >>>>> Something like >>>>>=20 >>>>> If the DF flag is not set and the IPv4 packet will result in an = IPv6 >>>>> packet larger than a user-defined length (hereinafter referred = to as >>>>> "lowest-ipv6-mtu", and which defaults to 1280 bytes), the packet = SHOULD >>>>> be fragmented so the resulting IPv6 packet (with Fragment Header = added >>>>> to each fragment) will be less than or equal to lowest-ipv6-mtu. >>>>> (...) >>>>>=20 >>>>>=20 >>>>>> If the DF bit is set and the packet is not a fragment (i.e., the = More >>>>>> Fragments (MF) flag is not set and the Fragment Offset is equal = to >>>>>> zero), then the translator SHOULD NOT add a Fragment Header to = the >>>>>> resulting packet. The IPv6 header fields are set as follows: >>>>>>=20 >>>>> Why is this worth mentioning? You already said "an IPv6 Fragment = Header is only included if the IPv4 packet is already fragmented." >>>>>=20 >>>>> I also recommend separating the last sentence into another = paragraph. >>>>>=20 >>>>>=20 >>>>>> If the IPv4 packet is discarded, then the translator SHOULD be = able >>>>>> to send back an ICMPv4 error message to the original sender of = the >>>>>> packet, unless the discarded packet is itself an ICMPv4 message. >>>>>>=20 >>>>> s/is itself an ICMPv4 message/is itself an ICMPv4 error message >>>>>=20 >>>>> I've always seen pings generating ICMP errors no problem. >>>>>=20 >>>>>=20 >>>>>> The translator MUST support stateless address mapping algorithm >>>>>> defined in [RFC6052], >>>>>> The stateless translator MUST support explicit address = mapping >>>>>> algorithm defined in [I-D.ietf-v6ops-siit-eam]. >>>>>> [stateless/stateful] IP/ICMP translators that are built = specifically to >>>>>> implement such a protocol, MAY forego implementing the above = address >>>>>> mapping algorithms. >>>>>>=20 >>>>> Is this not a contradiction? MUST MUST then MAY. >>>>>=20 >>>>> Even in the stateless case, why are both mandatory? >>>>>=20 >>>>> Traditional SIIT became an RFC without EAM and nobody complained. = In addition, the EAMT can hold 0.0.0.0/0 as an entry, = which will match any IPv4 packets, thereby removing the need for 6052 = translation. In fact, 0.0.0.0/0 can behave just like = a /96 6052 prefix. (If the user doesn't need the other prefix lengths, = why force the implementation to support 6052?) >>>>>=20 >>>>>=20 >>>>>> Thanks to Tore Anderson and Alberto Leiva Popper for the proposal = of >>>>>> the explicit address mapping (EAM) algorithm. >>>>>>=20 >>>>> Can you please remove my second last name there :-)? I'm the only = one with two. >>>>>=20 >>>>> Thanks >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_2AD5B6DB-CF89-457D-B792-9DCDDB94544D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVhvFvkayAOS/EQ8MAQLLog//T7Tc9HD+WqgX+Rq5OFX2HShdk2vca+ZX L+RpksC1YwPKahKraAMiCGpHY3whUxAdQzrQfWGuJdDWE9cgleUxsSz3zyASbE/O qEREZtt9ohSlYQHFnbxGSwbI935F1pZpv5ddEgR6bj4+cov/MEwfABC/4J8QMiur psZp1YY4FUqOgtS87xwqlSlK737Faw1RcuKmgzpioyuaiBO7oR7PskLqP67JG5Xc b5G1q3fSlWKdL7xcySMzGGOnafLWvOFpD/JoOwZKh1VahKGmXqXAZQabK2l/LRlp WQEYdIT8X3TAY4QIec65/YyMd9+rXGtAF21y3AnD3/hV2OAynBiTBLZ46Q+y9H3K BsI/j1stw35Xea868q3orKT1LkhfYcOtBlOGAElDIJb7pF2uAMXqxIjMNlnY6ZB8 MDJGkmRZtbcEC7fGH15z2O77KcJNNSTeNbiRPjEUQfKn0fLmZQfCudmvv11kUcvA ZUXxrNPbKGSzmcsy0LdSX0/1hR6KJBLyvb7JcT+7Cj0rKsR5dTtujLDsrMNmbSoT knu34vKCwGZxHBwUV8oERx9aK4v60+VHuddLidWG4VQII7djO8/yi/oRjZcOpjgr ctivpuNmoZPyByN8VjuoMiNDXO+KuPUhy8wrZHHQejn6OjfADy4XDD4txn3JEoCL L3bqqAfJdF4= =hpON -----END PGP SIGNATURE----- --Apple-Mail=_2AD5B6DB-CF89-457D-B792-9DCDDB94544D-- From nobody Mon Oct 12 10:28:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6FA1A8A8C for ; Mon, 12 Oct 2015 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHyHnYfVneyX for ; Mon, 12 Oct 2015 10:28:52 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44741A8A7C for ; Mon, 12 Oct 2015 10:28:52 -0700 (PDT) Received: by igkz10 with SMTP id z10so51652076igk.1 for ; Mon, 12 Oct 2015 10:28:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LRJg9rsULQoLhRIRgZ+o6ihWA0S8k2hRrUx/eFwhbr8=; b=AKSIiuhqQDdn8+9aVHr8QPx8JXYGwNvNFMeR+9Vpcc9cvlHO7pvyqkrt8bzV6Mn6os xVl6Hmmyb19wqCxUlISv+3D+MdyvXcuCIZNAm/NscTKRNerE2Sj5l6QB507xgEUt4mRE rlzFB51X9ra2r5Ylff1KNNPPeYnAb9YF3p5YYi361qcR2FJf0NxRily2QfJO2X4MW/R/ nqZVNj+3kaC0bArvsS8esEYzZuEK93VMAWF8tgQwzTWWE5fq19SBAwuyxKlln9AJXdn2 rrJejxKau0+Gta+UpSSZVQGvO5TLblBhOz4oWDdfME7Ptrhr3tK4bUJen3MV5neDNq6x +p3g== X-Gm-Message-State: ALoCoQnZUoKDGEJlzt2j9ohNg2RtFpnU78wMqvFMImqMjOsDGpOze5AK+UZL1NG14FLYbiPfCkzD MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr14070757igl.89.1444670931795; Mon, 12 Oct 2015 10:28:51 -0700 (PDT) Received: by 10.107.25.74 with HTTP; Mon, 12 Oct 2015 10:28:51 -0700 (PDT) In-Reply-To: <20151012170646.23529.74862.idtracker@ietfa.amsl.com> References: <20151012170646.23529.74862.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 10:28:51 -0700 Message-ID: From: Tom Herbert To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 17:28:54 -0000 Changes from 00 - Moved motivation section earlier in the draft and expanded it - ILA addresses (locators) are only used in destination addresses - Description the networking virtualization architecture with reference to NVo3 arch - Moved techniques to generated task identifiers to the appendix - Update email address Thanks, Tom ---------- Forwarded message ---------- From: Date: Mon, Oct 12, 2015 at 10:06 AM Subject: New Version Notification for draft-herbert-nvo3-ila-01.txt To: Tom Herbert A new version of I-D, draft-herbert-nvo3-ila-01.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-nvo3-ila Revision: 01 Title: Identifier-locator addressing for network virtualization Document date: 2015-10-09 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-herbert-nvo3-ila-01.txt Status: https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/ Htmlized: https://tools.ietf.org/html/draft-herbert-nvo3-ila-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-nvo3-ila-01 Abstract: This specification describes identifier-locator addressing (ILA) in IPv6 for network virtualization. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. Identifier-locator addressing can be used to efficiently implement overlay networks for network virtualization Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 12 10:36:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42331A8AC7 for ; Mon, 12 Oct 2015 10:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfaGrbvajxhv for ; Mon, 12 Oct 2015 10:36:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349BD1A8AC6 for ; Mon, 12 Oct 2015 10:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=598; q=dns/txt; s=iport; t=1444671396; x=1445880996; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XQNoUj6tdzteGek+FPxJs4ddlvt8WPIN8f//2s7PGu8=; b=cSbNj2/hfB74PYWJON6zUdlQnEP7WYT5wX100WlWMnsJx5Zz8T2ydgxp 4MxXMfCGhnrnCIaxJlqOY8wTvuTqviqq/jaM6jgoYQx+w8tBMxCJpUmdd yl3UuhG6NgY9oGE3x5sMKoUVVm/3uDMa1GMiVoPk7c07R6iVjRuRzxq9o o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CGAgCe7htW/5BdJa1dgyaBQga9fgENgVqDE4IKfwKBNjgUAQEBAQEBAYEKhCYBAQEEOj0OBAIBCBEEAQEfCQcyFAkIAgQBEgiIJr8fAQEBAQEBAQEBAQEBAQEBAQEBARmLcYUUBoQoAQSWEwGNEpwJAR8BAUKEAnGFa4EGAQEB X-IronPort-AV: E=Sophos;i="5.17,674,1437436800"; d="scan'208";a="196037925" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 12 Oct 2015 17:36:35 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9CHaZkc021994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2015 17:36:35 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Oct 2015 12:36:22 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Mon, 12 Oct 2015 12:36:22 -0500 From: "Hemant Singh (shemant)" To: Tom Herbert , "v6ops@ietf.org" Thread-Topic: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt Thread-Index: AQHRBROA6muq9f0VpEmDQRyKRPB+mJ5oHTBA Date: Mon, 12 Oct 2015 17:36:22 +0000 Message-ID: <0675e8c5ee324a81aeb67619b4b82675@XCH-RCD-005.cisco.com> References: <20151012170646.23529.74862.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.71.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 17:36:38 -0000 >-----Original Message----- >From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom Herbert >Sent: Monday, October 12, 2015 1:29 PM >To: v6ops@ietf.org >Subject: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-= 01.txt >Changes from 00 > - Moved motivation section earlier in the draft and expanded it This is great because even my thought was to have the motivation section ea= rlier in the draft so that folks would know why the work is needed. When I= get a chance I will review the latest version and get back to you all. Thanks, Hemant =20 From nobody Tue Oct 13 06:25:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF34E1B2A11; Tue, 13 Oct 2015 06:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-U5kYzFDDIB; Tue, 13 Oct 2015 06:25:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0E1B2A17; Tue, 13 Oct 2015 06:24:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151013132459.10107.7371.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 06:24:59 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Reducing energy consumption of Router Advertisements) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:25:07 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Reducing energy consumption of Router Advertisements' as Best Current Practice 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 2015-10-27. 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 Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Oct 13 06:56:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62791B405F; Tue, 13 Oct 2015 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f92rCA_ooBJ7; Tue, 13 Oct 2015 06:56:40 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 8F9941B405D; Tue, 13 Oct 2015 06:56:40 -0700 (PDT) Received: from 17-182-245-190.fibertel.com.ar ([190.245.182.17] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zm04A-0007Xm-Sj; Tue, 13 Oct 2015 15:56:35 +0200 References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> Message-ID: <561D0CB7.3040606@si6networks.com> Date: Tue, 13 Oct 2015 10:52:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Internet Area Subject: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 13:56:42 -0000 FYI. This rev hopefully addresses some/most/all of the comments received so far (mostly by Eric Vyncke and James Woodyatt). More comments/feedback will be welcome. Thanks, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt Date: Tue, 13 Oct 2015 06:45:30 -0700 From: internet-drafts@ietf.org To: Fred Baker , Fernando Gont A new version of I-D, draft-gont-opsawg-firewalls-analysis-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsawg-firewalls-analysis Revision: 01 Title: On Firewalls in Network Security Document date: 2015-10-13 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/ Htmlized: https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-opsawg-firewalls-analysis-01 Abstract: This document analyzes the role of firewalls in network security, and suggests a line of reasoning about their usage. It analyzes common kinds of firewalls and the claims made for them. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Oct 13 07:20:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F391B4371 for ; Tue, 13 Oct 2015 07:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3mRmBlLtB-V for ; Tue, 13 Oct 2015 07:20:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801EC1B436E for ; Tue, 13 Oct 2015 07:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=490; q=dns/txt; s=iport; t=1444746050; x=1445955650; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kCbPpdUPlJQeKkknI9bbGfhRFqLxegS+0K7mVbkFekk=; b=XNV3Drlg+VC8A3xhz5RbUavNtQ9rq5RXoNuCgqZi9GOeQUBEw3FQ1g80 4FMclxu3RLcM3mCPyon0gnk2DoyiuzxzpHfubT2GetWORXOR2fXB9OjMV 44XFlqFDh5ToNPqyCXVVS1AjBleVPVFJFr3DPyhryRimvYm2dDet2THH+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWAgBpEh1W/5JdJa1egyaBQga+DQENgVqDE4IKfwKBPzgUAQEBAQEBAYEKhCYBAQEEOj0OBAIBCBEEAQEfCQcyFAkIAgQBEgiIJsEuAQEBAQEBAQEBAQEBAQEBAQEBAQEYi3OFFAaEKAEElhYBjRKcDgEfAQFChAJxhWuBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,678,1437436800"; d="scan'208";a="35278122" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 13 Oct 2015 14:20:49 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t9DEKn8i007857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2015 14:20:49 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 09:20:36 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Tue, 13 Oct 2015 09:20:36 -0500 From: "Hemant Singh (shemant)" To: Tom Herbert , "v6ops@ietf.org" Thread-Topic: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt Thread-Index: AQHRBROA6muq9f0VpEmDQRyKRPB+mJ5pehBg Date: Tue, 13 Oct 2015 14:20:36 +0000 Message-ID: <2f9ec509d8b542489f3971baf2b99c20@XCH-RCD-005.cisco.com> References: <20151012170646.23529.74862.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.71.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:20:56 -0000 >-----Original Message----- >From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom Herbert >Sent: Monday, October 12, 2015 1:29 PM >To: v6ops@ietf.org >Subject: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-= 01.txt >Changes from 00 > - ILA addresses (locators) are only used in destination addresses Since multicast traffic is routed using the src-address of the packet, won'= t we need ILA addresses in source addresses?=20 Thanks, Hemant From nobody Tue Oct 13 09:24:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740FC1B4835 for ; Tue, 13 Oct 2015 09:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnO4G9Fpxbkt for ; Tue, 13 Oct 2015 09:24:01 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C401B4834 for ; Tue, 13 Oct 2015 09:24:01 -0700 (PDT) Received: by igkz10 with SMTP id z10so20417485igk.1 for ; Tue, 13 Oct 2015 09:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NmZ6BQ2ZpG9ykDDfIWGAyy3AA6ysbmsK6fxrh0stR8o=; b=W75TYwsGQtUOhOPWgFeqIBYK5XiOUNOXIHxjtYnJwLk6C0u8FBQL7RiPqdxbwQjUXA TR1uSEZ9kGqTERHCWkydiPAvWddKfTU5iW9MRNyyBPpkvIoBMzZcJigOD/TXx9LSJDre iBUuOOMBinL8ICSizKBreEiqGN1iX30DI4EjdCKxuNHWnQU654cdOaQvKMbdJA02GXLm KeWCTTZgEMOq/fhNDdKbhnxory34DDpAfj49Kxs/Sr/01jC94kJBv6PvCaA6+fck7iwt HluTr84NKQ/d1M5bFzVvw3SUHxtXa3DyeCiSBXRj88m6dt0o4M6FJWw2rYYlzcajHg7I AFAQ== X-Gm-Message-State: ALoCoQmtp47E3O4PrBuchlrhqPOz39KlGm9m0/NzSC9YlVCIHQIgh0eXnaJrAAnZwPWO/rg+Y1Oc MIME-Version: 1.0 X-Received: by 10.50.41.74 with SMTP id d10mr21214671igl.94.1444753440617; Tue, 13 Oct 2015 09:24:00 -0700 (PDT) Received: by 10.107.25.74 with HTTP; Tue, 13 Oct 2015 09:24:00 -0700 (PDT) In-Reply-To: <2f9ec509d8b542489f3971baf2b99c20@XCH-RCD-005.cisco.com> References: <20151012170646.23529.74862.idtracker@ietfa.amsl.com> <2f9ec509d8b542489f3971baf2b99c20@XCH-RCD-005.cisco.com> Date: Tue, 13 Oct 2015 09:24:00 -0700 Message-ID: From: Tom Herbert To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:24:03 -0000 On Tue, Oct 13, 2015 at 7:20 AM, Hemant Singh (shemant) wrote: > >>-----Original Message----- >>From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom Herbert >>Sent: Monday, October 12, 2015 1:29 PM >>To: v6ops@ietf.org >>Subject: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt > >>Changes from 00 >> - ILA addresses (locators) are only used in destination addresses > > Since multicast traffic is routed using the src-address of the packet, won't we need ILA addresses in source addresses? > Yes, good point! I imagine that a multicast sender should use an ILA address and not SIR address in the source. At a receiver the source address should be translated back to the SIR address before delivery to the application, however we also want to allow multicast receivers that don't participate in ILA so it would be possible to receive multicast packets with an ILA source address. Tom > Thanks, > > Hemant From nobody Tue Oct 13 09:59:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EF51B4BC1; Tue, 13 Oct 2015 09:59:04 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3JnUBUITGZW; Tue, 13 Oct 2015 09:59:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE61B4BC4; Tue, 13 Oct 2015 09:59:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 09:59:03 -0700 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 16:59:05 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 3, "Mitigation", I'm reading this. Mitigation of the potential for PTB messages to be mis-delivered involves ensuring that an ICMPv6 error message is distributed to the same anycast server responsible for the flow for which the error is generated. Ideally, mitigation could be done by the mechanism hosts ^^^^^^^ use to identify the flow, by looking into the payload of the ICMPv6 message (to determine which TCP flow it was associated with) before making a forwarding decision. Because the encapsulated IP header occurs at a fixed offset in the ICMP message it is not outside the realm of possibility that routers with sufficient header processing capability could parse that far into the payload. Employing a mediation device that handles the parsing and distribution of PTB messages after policy routing or on each load-balancer/server is a possibility. Most of the document is about using other mitigations that make this mitigation unnecessary, but it's still a bit odd to see Deep Packet Inspection characterised as "ideally", now that RFC 7258 is now BCP 188, and we've chartered TCPINC to make that DPI fail as often as possible. Could that one word go away? I see in email that Fred asked if any reviews were needed before submitting this draft for publication, and David Black suggested reviews from INT and TSV, and that made it as far as the shepherd writeup, but I'm not seeing a request for review popping up in TSV (at least not with "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this particular draft, but I wish it hadn't slipped through that particular crack. Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase that. Just something to watch for, in the future. And yes, Martin and I have a call set up to talk with the TSVdir triage team next week ... From nobody Tue Oct 13 21:25:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FAF1B2B34; Tue, 13 Oct 2015 21:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS-W9AsFztBk; Tue, 13 Oct 2015 21:25:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F631B2B31; Tue, 13 Oct 2015 21:25:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 21:25:45 -0700 Archived-At: Cc: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-dc-2xlat.ad@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-dc-2xlat@ietf.org, draft-ietf-v6ops-siit-dc-2xlat.shepherd@ietf.org Subject: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 04:25:47 -0000 Barry Leiba has entered the following ballot position for draft-ietf-v6ops-siit-dc-2xlat-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A small editorial thing in the abstract: This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. With the comma after "IPv6", it looks like you mean this: which allows 1. applications, protocols, or nodes that are incompatible with IPv6 and/or 2. Network Address Translation to operate correctly in an SIIT-DC environment. ...when what you mean is this: which allows applications, protocols, or nodes that are incompatible with 1. IPv6 and/or 2. Network Address Translation to operate correctly in an SIIT-DC environment. I suggest removing the comma. From nobody Wed Oct 14 01:31:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F51B2C3F; Wed, 14 Oct 2015 01:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eomLhiFNhvYJ; Wed, 14 Oct 2015 01:31:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BA1B2C5A; Wed, 14 Oct 2015 01:31:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014083128.19839.60576.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 01:31:28 -0700 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, bonica@juniper.net, draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 08:31:30 -0000 Benoit Claise has entered the following ballot position for draft-ietf-v6ops-siit-eam-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From Ron Bonica's OPS DIR review: The Nit Checker says: == There are 1 instance of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. I understand why you had to break the rule for 0/0. But could the IPv6 addresses have been taken from documentation space? From nobody Wed Oct 14 02:19:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D1C1B2D3A; Wed, 14 Oct 2015 02:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as7NUna9hXKN; Wed, 14 Oct 2015 02:19:20 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22AD1A1B5C; Wed, 14 Oct 2015 02:10:27 -0700 (PDT) Received: from [2a02:fe0:c410:d91::8b1] (port=45567 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZmI4j-00073d-He; Wed, 14 Oct 2015 11:10:21 +0200 Date: Wed, 14 Oct 2015 11:10:21 +0200 From: Tore Anderson To: "Barry Leiba" Message-ID: <20151014111021.6f79c8da@envy.fud.no> In-Reply-To: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> References: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-dc-2xlat.ad@ietf.org, fred.baker@cisco.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-dc-2xlat@ietf.org, The IESG , draft-ietf-v6ops-siit-dc-2xlat.shepherd@ietf.org Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:19:21 -0000 * Barry Leiba > A small editorial thing in the abstract: > > This document describes an extension of the Stateless IP/ICMP > Translation for IPv6 Internet Data Centre Environments architecture > (SIIT-DC), which allows applications, protocols, or nodes that are > incompatible with IPv6, and/or Network Address Translation to operate > correctly in an SIIT-DC environment. > > With the comma after "IPv6", it looks like you mean this: > > which allows > 1. applications, protocols, or nodes that are > incompatible with IPv6 > and/or > 2. Network Address Translation > to operate correctly in an SIIT-DC environment. > > ...when what you mean is this: > > which allows applications, protocols, or nodes that are > incompatible with > 1. IPv6 > and/or > 2. Network Address Translation > to operate correctly in an SIIT-DC environment. > > I suggest removing the comma. Good catch - thank you! Tore From nobody Wed Oct 14 02:21:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1CC1B2CCE; Wed, 14 Oct 2015 02:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6mEKh-FqW_R; Wed, 14 Oct 2015 02:20:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353CD1A03A2; Wed, 14 Oct 2015 02:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2545; q=dns/txt; s=iport; t=1444814180; x=1446023780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JIbDzAr3b8ujFvpFxCuGZIhbayNOWZElbrq7JSF2464=; b=MATaTUcUzk+zHkqyIQOGjSfG169gFHFjVedk+8+o6Z3smQqBgUxVOcEp EoKlYL5h0bfqDZljSU/J6V6YP6GDAlTAPj6FqnhVN72YTMlaRBGVtSz4q fH8yhti1gAgowzeZf5vHtvo87GYCVcq04ORHpFPcu5GAgOLUkDXfvgGni E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwDmHB5W/4MNJK1egyaBQga5W4QhDoFagxOCCn8CgTc4FAEBAQEBAQGBCoQmAQEBAwF5BQsCAQgSBi4yFw4CBAENBQ6IGAjCbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReJBoJuhQ0HgxqBFAEElhUBgk2BYYhsnAkBHwFDgkSBPnGFaYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="asc'?scan'208";a="37454118" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 14 Oct 2015 09:16:19 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9E9GJGp010501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 09:16:19 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 04:16:05 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 04:16:05 -0500 From: "Fred Baker (fred)" To: Tore Anderson , Barry Leiba Thread-Topic: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) Thread-Index: AQHRBmD0lt62WGKWpkCXRdo4JY6dDg== Date: Wed, 14 Oct 2015 09:16:05 +0000 Message-ID: <56CCDCAC-48E6-4CDE-A0C2-DDC20561ECA7@cisco.com> References: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> <20151014111021.6f79c8da@envy.fud.no> In-Reply-To: <20151014111021.6f79c8da@envy.fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.192.67] Content-Type: multipart/signed; boundary="Apple-Mail=_A3128A67-6741-4AC0-BF47-1C39C5B1076D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-siit-dc-2xlat.ad@ietf.org" , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-siit-dc-2xlat@ietf.org" , The IESG , "draft-ietf-v6ops-siit-dc-2xlat.shepherd@ietf.org" Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:21:00 -0000 --Apple-Mail=_A3128A67-6741-4AC0-BF47-1C39C5B1076D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dumb question: is that something the RFC Editor could address rather = than having Tore spin the draft? > On Oct 14, 2015, at 3:10 AM, Tore Anderson wrote: >=20 > * Barry Leiba >=20 >> A small editorial thing in the abstract: >>=20 >> This document describes an extension of the Stateless IP/ICMP >> Translation for IPv6 Internet Data Centre Environments architecture >> (SIIT-DC), which allows applications, protocols, or nodes that are >> incompatible with IPv6, and/or Network Address Translation to = operate >> correctly in an SIIT-DC environment. >>=20 >> With the comma after "IPv6", it looks like you mean this: >>=20 >> which allows >> 1. applications, protocols, or nodes that are >> incompatible with IPv6 >> and/or >> 2. Network Address Translation >> to operate correctly in an SIIT-DC environment. >>=20 >> ...when what you mean is this: >>=20 >> which allows applications, protocols, or nodes that are >> incompatible with >> 1. IPv6 >> and/or >> 2. Network Address Translation >> to operate correctly in an SIIT-DC environment. >>=20 >> I suggest removing the comma. >=20 > Good catch - thank you! >=20 > Tore --Apple-Mail=_A3128A67-6741-4AC0-BF47-1C39C5B1076D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVh4daUayAOS/EQ8MAQJOwA/+IJjx8gFHH5qUQr4UVoa/ZcqlbkxkzBFs 3VEeBPwa2wjO7kIUnteoKhqHdG5hCs1EPp/EHrCdRkHL/qrG4pjBrexke8BQ+1Hn Dqi3hsFFu+rQc7SPMnWgcRy8JkMc2uHXQ+1docAWDewvNCCms6P+D7kxMHbDBQbN A8YZii10AdDKSolGzQOUSbOeJI2FPju4c0Bxoe8+qnTc3Q9ioVYnYlCAKXaV0pIE UpWYimt/p8T9BSQ+BJQi/b9QQyHrW4FolCKeLzJbO6lp6jBRu5KzWaOahllH+bbv TXOMcu8dDtSM3l+W4a69Ljcn3D/eCnyoKAYlNybaeAxBVFG+WUBqRLlTlS3824NH kFA9ouDQ7Hvx9kO6b4lGGMnxusivrP9w3FE03Pp00MseuKrd/L/H1k30tmbTDFrs LsA38mB4Mu5kct0qqYOPyDufFVrg3gBvJEKt9bHuqVC8IwTHCdlST1pRMAscmKSF 6UtDfFKvjHHWuvxrJMPNLkOEtwS3Gl8sgYahDoTp8jJdDZj5odrDvSOaRShxUxnP /xjz9S6Ah98kvSUX+1T8STHn888GhuQi9U2dXUC+T/+d04JJ8wBaAglba1ebz89K qyhpg9JSWIfLmVYdYNKJW9nL9tGO3hOolegpdVPcTC+x4ghMPqkQmfebmbCGWfak W5wDwB8jfE4= =g0SN -----END PGP SIGNATURE----- --Apple-Mail=_A3128A67-6741-4AC0-BF47-1C39C5B1076D-- From nobody Wed Oct 14 02:25:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C821B2CE0; Wed, 14 Oct 2015 02:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK_TpA5wVICS; Wed, 14 Oct 2015 02:25:25 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB6C1B2CD0; Wed, 14 Oct 2015 02:25:15 -0700 (PDT) Received: from [2a02:fe0:c410:d91::8b1] (port=45603 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZmIJ6-0007RM-MJ; Wed, 14 Oct 2015 11:25:12 +0200 Date: Wed, 14 Oct 2015 11:25:12 +0200 From: Tore Anderson To: "Benoit Claise" Message-ID: <20151014112512.3c904aac@envy.fud.no> In-Reply-To: <20151014083128.19839.60576.idtracker@ietfa.amsl.com> References: <20151014083128.19839.60576.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, bonica@juniper.net, The IESG , draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: Re: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:25:26 -0000 * Benoit Claise > >From Ron Bonica's OPS DIR review: > The Nit Checker says: >=20 > =3D=3D There are 1 instance of lines with non-RFC5735-compliant IPv4 > addresses > in the document. If these are example addresses, they should be > changed. >=20 > =3D=3D There are 3 instances of lines with non-RFC3849-compliant IPv6 > addresses > in the document. If these are example addresses, they should be > changed. >=20 > I understand why you had to break the rule for 0/0. But could the IPv6 > addresses have been taken from documentation space? Hi Benoit, Idnits doesn't show this unless you run it in verbose mode, but non-RFC5735/3849 addresses used present in the document are from: - 64:ff9b::/96 (the well-known prefix used for IPv4-embedded IPv6 addresses, defined in RFC6052) - 192.0.0.0/29 (the well-known prefix used for local unrouted IPv4 interfaces that are part of a IPv6 transition solution, defined in RFC7335) The prefixes are used as mandated by RFC6052/RFC7335, and those documents are referenced. In my opinion, their use makes for a better document than the use of the generic documentation prefixes, because it their use are then immediately obvious. By replacing these prefixes with RFC5735/3849 ones, some statements will immediately become incorrect. Consider for example if the current statement: =C2=AB[...] even if the well-known prefix 64:ff9b::/96 is used [...]=C2=BB would be replaced with: =C2=AB[...] even if the well-known prefix 2001:db8::/96 is used [...]=C2=BB This new statement would IMHO just cause confusion, because 2001:db8::/96 is simply *not* the RFC6052 well-known prefix. So I would strongly prefer to have the document use RFC6052/RFC7335 prefixes where this is appropriate, but will of course yield if the consensus says otherwise. Tore From nobody Wed Oct 14 02:31:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5701B2CFD; Wed, 14 Oct 2015 02:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxygN7oIEoq8; Wed, 14 Oct 2015 02:31:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C4A1B2CDD; Wed, 14 Oct 2015 02:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1817; q=dns/txt; s=iport; t=1444815115; x=1446024715; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7CFsp+YywXnmQZYvLVPoppBUwEnwoOMWDypYj+qhNe8=; b=CI05lQ38AjF8y8ozCEzc8wGHPl3pNJOSZiqwpvuoB+LSNqUwDFpcAWGk /tw/l6VHmqKI7NJvnBR+S9fqMCz3cHG1niCicJFtwZiUdnNg1DXdIYuvo OdluxbCYTYfS6UiALPJQCoo69QGrS0wOGyvUZ8xew9GwxK8B8a8pTEuBp Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwDiHx5W/5pdJa1egyaBQga5W4QhDoFagxOCCn8CgTc4FAEBAQEBAQGBCoQmAQEBAwF5BQsCAQgYLjIlAgQBDQUOiBgIwnUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiQaCboUNB4MagRQBBJYVAYJNgWGIbJwJAR8BQ4IRHRaBPnGFaYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="asc'?scan'208";a="35559455" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2015 09:31:54 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9E9VrWc008684 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 09:31:54 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 04:31:40 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 04:31:40 -0500 From: "Fred Baker (fred)" To: Tore Anderson , "Benoit Claise (bclaise)" Thread-Topic: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) Thread-Index: AQHRBmMhcZ7i4FeVw0KN4wYpggxQgA== Date: Wed, 14 Oct 2015 09:31:40 +0000 Message-ID: References: <20151014083128.19839.60576.idtracker@ietfa.amsl.com> <20151014112512.3c904aac@envy.fud.no> In-Reply-To: <20151014112512.3c904aac@envy.fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.192.67] Content-Type: multipart/signed; boundary="Apple-Mail=_B508419F-99B0-4BBC-B8B2-B46A1C5EB173"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-siit-eam@ietf.org" , "draft-ietf-v6ops-siit-eam.shepherd@ietf.org" , "v6ops-chairs@ietf.org" , "bonica@juniper.net" , The IESG , "draft-ietf-v6ops-siit-eam.ad@ietf.org" Subject: Re: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:31:57 -0000 --Apple-Mail=_B508419F-99B0-4BBC-B8B2-B46A1C5EB173 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 14, 2015, at 3:25 AM, Tore Anderson wrote: >=20 > So I would strongly prefer to have the document use RFC6052/RFC7335 > prefixes where this is appropriate, but will of course yield if the > consensus says otherwise. My recollection is that I said that in the shepherd's write-up. Did I = miss that? I certainly think that if we are discussing a mandated prefix, we should = say what prefix we're talking about, and it's not the documentation = prefix. --Apple-Mail=_B508419F-99B0-4BBC-B8B2-B46A1C5EB173 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVh4hD0ayAOS/EQ8MAQLxmw/9HpsWSC28VNvq0r80rmFsVqtNXq2PzkkL dKvS907b6wpOe7QvKtBuFdFdmz8BIdwiCGlx3YMByrJ3Xa5lodqEDtfmvCbPA/s+ bZJ3v2rdHwZaQF5ofkVBgWUzUF4s+WQ0fqw3B+weFUxk04tILPO8ZkrS5Z0PUudZ 9pP/J3FXXn6FCRCHRtqs60OANWfIHnzNpfRpnmiaXKl4+kBC21g32pKa0pPjZbA7 NRkfxmzLKQVfvQ0x7o0U64AoNcxOU37SZaRog86mvMULEXKCPTrvPkDHeJSnKlAJ r36TT444BebyJch+38HxnsKe1+Inh3LEiGNzEyZVseqoyYl53oIfwKX706skqt60 u2nM7297646jGNLjQz7wMh+ECwsGzkEZZ6Wolw8VGvBetvbL/O+zj/EUXc8Xrxyr uuUhNCbTwI21J5lgAGQJcBm4taUgaJnPxJcGmXo+Srx6e9/YkYmmW215/8nA+4Bs n5dSRDUo8Qa2fN9sAUPcY0aAW3bDoLYlyUQBgoodHsRNPWkYnPYRKcR4J22HwQNi S2ujNyy85dFPEvKkHWs52LO3n6PleJpkuqTm1tneOk9IB5PLqyv4/mb9cIAoW56C Ogs/9qe1yuVv2vJF8ScDTENjegYT3AydxNaprKJvoVnUoa0x8tbOhNA5FDRNncFB 7cTyDsqlKy0= =apEk -----END PGP SIGNATURE----- --Apple-Mail=_B508419F-99B0-4BBC-B8B2-B46A1C5EB173-- From nobody Wed Oct 14 02:43:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A531A879D; Wed, 14 Oct 2015 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmqS4Mq6F-4y; Wed, 14 Oct 2015 02:43:29 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867E71A86FF; Wed, 14 Oct 2015 02:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=618; q=dns/txt; s=iport; t=1444815809; x=1446025409; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PBMuqW7c2AvGVKDM7Fk1J36UFmKz6NliELZWZWMkhFY=; b=bqA0RLMB2FC7IlEwWn0gZs6daA2JcsprRqZ6lNyEhg7KfYUt7p/lAQus zWwjlwZwKrXDpuh3+HKgoCeypllma2GqIIDLtOklxbWSzzjgU0aF48UUk rYv52znixoNPoQ7WUnBV/NRuBhtqSbPjVXuSYoGS4loIqE64cs/Pwg8Sn k=; X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208";a="607605866" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Oct 2015 09:43:26 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9E9hQp6018515; Wed, 14 Oct 2015 09:43:26 GMT To: "Fred Baker (fred)" , Tore Anderson References: <20151014083128.19839.60576.idtracker@ietfa.amsl.com> <20151014112512.3c904aac@envy.fud.no> From: Benoit Claise Message-ID: <561E23B1.6050106@cisco.com> Date: Wed, 14 Oct 2015 11:43:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-siit-eam@ietf.org" , "draft-ietf-v6ops-siit-eam.shepherd@ietf.org" , "v6ops-chairs@ietf.org" , The IESG , "draft-ietf-v6ops-siit-eam.ad@ietf.org" Subject: Re: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 09:43:30 -0000 On 10/14/2015 11:31 AM, Fred Baker (fred) wrote: >> On Oct 14, 2015, at 3:25 AM, Tore Anderson wrote: >> >> So I would strongly prefer to have the document use RFC6052/RFC7335 >> prefixes where this is appropriate, but will of course yield if the >> consensus says otherwise. > My recollection is that I said that in the shepherd's write-up. Did I miss that? No, I simply overlooked it. Thanks Fred and Tore. We're good. Regards, Benoit > > I certainly think that if we are discussing a mandated prefix, we should say what prefix we're talking about, and it's not the documentation prefix. From nobody Wed Oct 14 06:15:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6C01A6F64; Wed, 14 Oct 2015 06:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSW9lkvCDNRP; Wed, 14 Oct 2015 06:15:36 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E891A6F45; Wed, 14 Oct 2015 06:15:36 -0700 (PDT) Received: by vkaw128 with SMTP id w128so29112996vka.0; Wed, 14 Oct 2015 06:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NDCDg9W87X8LeRjKaGHr+UwDn5amFAGLtcAH4uJOaos=; b=RRkchDv3R45TyWMUTwz1my/NmEGPTxhFg199iUH/R56TZzQk7WOuvfF6Sc+Jhc5ohk cE4yjJnLMqMbaNgwR243TEO5zlkUZQEB3ft4gvlQhYsWm6/E6nof3k+mYKRsNUJ+mNki i6GGifM2ExhmfbyUAz7VWBINQap669deffYADsjaWd3ay5TU6dKprq6u5jJ0lLzCfyzQ SqV8i0/6VCx8ED/Itxo9VMvjHP+JiJJCtCuJrJNg1w85mM5C6WqNjRXHZxnMpsa44KZF gIrOd9nHmVZwWM0D7zW9TdU0eRB2j7D4AFkmkUbUdtagk5IvBhpYcQ+PgxdqSqNsVOeP Go4Q== MIME-Version: 1.0 X-Received: by 10.31.170.80 with SMTP id t77mr1651944vke.156.1444828535799; Wed, 14 Oct 2015 06:15:35 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Wed, 14 Oct 2015 06:15:35 -0700 (PDT) In-Reply-To: <56CCDCAC-48E6-4CDE-A0C2-DDC20561ECA7@cisco.com> References: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> <20151014111021.6f79c8da@envy.fud.no> <56CCDCAC-48E6-4CDE-A0C2-DDC20561ECA7@cisco.com> Date: Wed, 14 Oct 2015 09:15:35 -0400 X-Google-Sender-Auth: pi5K7EidIqnvUZSO44_YyFFog0M Message-ID: From: Barry Leiba To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-siit-dc-2xlat.ad@ietf.org" , Tore Anderson , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-siit-dc-2xlat@ietf.org" , The IESG , "draft-ietf-v6ops-siit-dc-2xlat.shepherd@ietf.org" Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 13:15:38 -0000 > Dumb question: is that something the RFC Editor could address rather > than having Tore spin the draft? Oh, absolutely, it'd be fine as an RFC Editor note, if there are no other changes to make. I only mentioned it because I don't know that the RFC Editor would have picked it up, as they aren't necessarily aware of what the text is meant to say. Barry >> On Oct 14, 2015, at 3:10 AM, Tore Anderson wrote: >> >> * Barry Leiba >> >>> A small editorial thing in the abstract: >>> >>> This document describes an extension of the Stateless IP/ICMP >>> Translation for IPv6 Internet Data Centre Environments architecture >>> (SIIT-DC), which allows applications, protocols, or nodes that are >>> incompatible with IPv6, and/or Network Address Translation to operate >>> correctly in an SIIT-DC environment. >>> >>> With the comma after "IPv6", it looks like you mean this: >>> >>> which allows >>> 1. applications, protocols, or nodes that are >>> incompatible with IPv6 >>> and/or >>> 2. Network Address Translation >>> to operate correctly in an SIIT-DC environment. >>> >>> ...when what you mean is this: >>> >>> which allows applications, protocols, or nodes that are >>> incompatible with >>> 1. IPv6 >>> and/or >>> 2. Network Address Translation >>> to operate correctly in an SIIT-DC environment. >>> >>> I suggest removing the comma. >> >> Good catch - thank you! >> >> Tore > From nobody Wed Oct 14 06:17:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6A1A6F3F; Wed, 14 Oct 2015 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgCXT5a5DGQi; Wed, 14 Oct 2015 06:17:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3071A6F81; Wed, 14 Oct 2015 06:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3099; q=dns/txt; s=iport; t=1444828628; x=1446038228; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=img5V/t1qNGMkgBwSqkeXTzSN+/VgaiCq9i17zhFEyI=; b=bdLuTQT04KBZJHEg+TTkM82xDqFoFXMEBl6+cdkGeMNvIXnZC4LAUGwn +easH/qLw7Djlb+XXKL/JY449O8t0LTm2uxLfNtc/ODSiyFVhnZ2DsLs1 KNKYJcJgwtPJBeou2ivKQ1SCyA9ejS3KAbAo/RpKtwRbeHwelWyfJPelQ 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwBaVR5W/5RdJa1egyaBQga5EYQhDoFagxOCCn8CgT44FAEBAQEBAQGBCoQmAQEBAwF5BQsCAQgSBi4yFw4CBA4FDogYCMJgAQEBAQEBAQEBAQEBAQEBAQEBAQEYiQaCboUNB4MagRQFlhUBgk2BYYhsnAkBHwFDgkSBPnGFaYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="asc'?scan'208";a="41335808" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2015 13:17:07 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9EDH5YY002806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 13:17:06 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 08:16:51 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 08:16:51 -0500 From: "Fred Baker (fred)" To: Barry Leiba Thread-Topic: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) Thread-Index: AQHRBoKWShSS0kvFpEW8xupDLVHs0w== Date: Wed, 14 Oct 2015 13:16:51 +0000 Message-ID: <96D1176F-2623-4F4B-B9B8-35DFB1551D9C@cisco.com> References: <20151014042545.32717.95557.idtracker@ietfa.amsl.com> <20151014111021.6f79c8da@envy.fud.no> <56CCDCAC-48E6-4CDE-A0C2-DDC20561ECA7@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.192.67] Content-Type: multipart/signed; boundary="Apple-Mail=_A6EF6972-16A9-4470-B677-B1843FE4A8A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-siit-dc-2xlat.ad@ietf.org" , Tore Anderson , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-siit-dc-2xlat@ietf.org" , The IESG , "draft-ietf-v6ops-siit-dc-2xlat.shepherd@ietf.org" Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 13:17:09 -0000 --Apple-Mail=_A6EF6972-16A9-4470-B677-B1843FE4A8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK. If Tore has other updates to make he can pick this up too. But it = seems silly to spin the draft for a comma. > On Oct 14, 2015, at 7:15 AM, Barry Leiba = wrote: >=20 >> Dumb question: is that something the RFC Editor could address rather >> than having Tore spin the draft? >=20 > Oh, absolutely, it'd be fine as an RFC Editor note, if there are no > other changes to make. I only mentioned it because I don't know that > the RFC Editor would have picked it up, as they aren't necessarily > aware of what the text is meant to say. >=20 > Barry >=20 >>> On Oct 14, 2015, at 3:10 AM, Tore Anderson wrote: >>>=20 >>> * Barry Leiba >>>=20 >>>> A small editorial thing in the abstract: >>>>=20 >>>> This document describes an extension of the Stateless IP/ICMP >>>> Translation for IPv6 Internet Data Centre Environments = architecture >>>> (SIIT-DC), which allows applications, protocols, or nodes that are >>>> incompatible with IPv6, and/or Network Address Translation to = operate >>>> correctly in an SIIT-DC environment. >>>>=20 >>>> With the comma after "IPv6", it looks like you mean this: >>>>=20 >>>> which allows >>>> 1. applications, protocols, or nodes that are >>>> incompatible with IPv6 >>>> and/or >>>> 2. Network Address Translation >>>> to operate correctly in an SIIT-DC environment. >>>>=20 >>>> ...when what you mean is this: >>>>=20 >>>> which allows applications, protocols, or nodes that are >>>> incompatible with >>>> 1. IPv6 >>>> and/or >>>> 2. Network Address Translation >>>> to operate correctly in an SIIT-DC environment. >>>>=20 >>>> I suggest removing the comma. >>>=20 >>> Good catch - thank you! >>>=20 >>> Tore >>=20 --Apple-Mail=_A6EF6972-16A9-4470-B677-B1843FE4A8A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVh5V10ayAOS/EQ8MAQK4pBAAxu9Rc3sBzauk05fy6T32Oupij2Gda3Ii nm9Aw/JtdoRc7kbSRC0zCK7KN0QlkQyUWUBK5fzMJGsOOMMJ8FzHn9rZVmaA6itO DnptHjWilKdrBE5uP5vOWmREiR5HMWOuk+sfkcL+4xcZET6eown23cXrIs+Vhkon frvADPK/NTFaXVZebNcjseiFhh0GXCbF9CVOs0CS/+KHJiSewGnAIuwPMoNYT3m9 8OvLIdvp7D7ItB7/juknsRkblSYDmEniViBRKFnVk7vMIRVu5Y6REGp9bZfJAnon f+MvA3voCeUob26Don5ILEPD3acg00fFXSpNC9eL0MmoN6dDdqLOWjHqtWktKEX5 2sy/RgJkNPXUVN5fBfowEoWfGnmAYn7ywtjeWhc15IBHpzmX+AmibPohi2KNmbHV 4IkNFE6PZNKwHRkS4NlulZjHpze09uq0Trj2w+SUsrVM/yzAGq5kSp5PkeODmdlk VHvU/NvgQzmMQot5uyq8lUwjhNRBX4yCljhSO2S+FUJqZQJhKNjyp6wWVFnsToo4 eRWZwhYOC4a38WQcUvm6IJDqvQt6dKU7y4UA9MN3oamVR41TyiFDip+XS4Dcs5eo WJixTGXylGGJH9381fSvJ2pZ635Y+5aELvW4hL5u403JiNqOtVP9XsYULszaoGQ+ VhsoyhdUvYI= =m3Aq -----END PGP SIGNATURE----- --Apple-Mail=_A6EF6972-16A9-4470-B677-B1843FE4A8A7-- From nobody Wed Oct 14 07:31:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBE1A889D; Wed, 14 Oct 2015 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSMOWTt2zJCh; Wed, 14 Oct 2015 07:31:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D38181A888F; Wed, 14 Oct 2015 07:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014143155.22010.51439.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 07:31:55 -0700 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: [v6ops] Brian Haberman's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:31:57 -0000 Brian Haberman has entered the following ballot position for draft-ietf-v6ops-siit-eam-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no issues with the publication of this draft, but want to point out that there an abundance of misuses of 2119 keywords. Section 3.1 provides useful examples: An SIIT implementation MUST include an Explicit Address Mapping Table (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be able to populate the EAMT using the implementation's normal configuration interfaces. The implementation MAY additionally support other ways of populating the EAMT. - How a SIIT implementation manages the mappings has no bearing on the functionality. So, saying "MUST include an EAMT" is not needed. - SHOULD be empty? At what point? During implementation? - Why "MUST be able to populate"? From nobody Wed Oct 14 08:20:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A861A92AF; Wed, 14 Oct 2015 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDWUU0sn3Ase; Wed, 14 Oct 2015 08:20:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F02921AC3C3; Wed, 14 Oct 2015 08:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014152032.22846.40625.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 08:20:32 -0700 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: [v6ops] Brian Haberman's Yes on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:20:45 -0000 Brian Haberman has entered the following ballot position for draft-ietf-v6ops-pmtud-ecmp-problem-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given the current state of affairs, I think this is a quite useful document. I just have a question for my own knowledge. Is there any data that indicates how many of these PTB messages are due to tunneling? From nobody Wed Oct 14 09:45:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FCE1ACE4A; Wed, 14 Oct 2015 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijz59sRW4XWH; Wed, 14 Oct 2015 09:45:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FEE1A886E; Wed, 14 Oct 2015 09:39:25 -0700 (PDT) Received: from mb.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9EGdNJU021134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Oct 2015 16:39:24 GMT (envelope-from joelja@bogus.com) To: Brian Haberman , The IESG References: <20151014152032.22846.40625.idtracker@ietfa.amsl.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <561E853C.5010005@bogus.com> Date: Wed, 14 Oct 2015 09:39:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Thunderbird/41.0 MIME-Version: 1.0 In-Reply-To: <20151014152032.22846.40625.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M7JFAiLjD83HrPKmFm3hm5UtHcKGOKt2f" Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Brian Haberman's Yes on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 16:45:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M7JFAiLjD83HrPKmFm3hm5UtHcKGOKt2f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/14/15 8:20 AM, Brian Haberman wrote: > Brian Haberman has entered the following ballot position for > draft-ietf-v6ops-pmtud-ecmp-problem-04: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Given the current state of affairs, I think this is a quite useful > document. I just have a question for my own knowledge. >=20 > Is there any data that indicates how many of these PTB messages are due= > to tunneling? I have some although I doubt that they are valid statistically for the whole internet. by way of characterization the vast majority of sessions for which pmtud messages were distributed at zynga had an mss of 1440 so these are otherwise unsuspecting machines facing a constraint on an intermediate hop. the pool of ipv6 enabled words with friends users was actually pretty high, e.g. tmobile verizon and other lte phones with ipv6 or dual stack pdp contexts, and those would be fine. if on ther other hand the same user has a problem when attached to their home CPE then they might have a tunnel. older work in this space is stuff like http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesi= s.pdf as a content provider however I'm not that concerned with the total population only that of my customers where it turns out this is rare, albiet not rare enough to ignore. >=20 >=20 > ______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --M7JFAiLjD83HrPKmFm3hm5UtHcKGOKt2f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYehT0ACgkQ8AA1q7Z/VrIrVACePe3OqJJqJ+ca6QeiNevRI1Dn D/QAn08tNC3+ZMK/b8v0RWO8KdRoQRun =Phja -----END PGP SIGNATURE----- --M7JFAiLjD83HrPKmFm3hm5UtHcKGOKt2f-- From nobody Wed Oct 14 14:49:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B141A8A51; Wed, 14 Oct 2015 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c_nQzCsmIMQ; Wed, 14 Oct 2015 14:49:12 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3EC1A8A47; Wed, 14 Oct 2015 14:49:12 -0700 (PDT) Received: from [2a02:fe0:c410:d91::8b1] (port=51816 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZmTv2-0007rt-W8; Wed, 14 Oct 2015 23:49:09 +0200 Date: Wed, 14 Oct 2015 23:49:08 +0200 From: Tore Anderson To: "Brian Haberman" Message-ID: <20151014234908.4168256d@envy.fud.no> In-Reply-To: <20151014143155.22010.51439.idtracker@ietfa.amsl.com> References: <20151014143155.22010.51439.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: Re: [v6ops] Brian Haberman's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:49:13 -0000 Hello Brian, * Brian Haberman > I have no issues with the publication of this draft, but want to point > out that there an abundance of misuses of 2119 keywords. If that is an acceptable way forward for you, I am hoping to get help from the RFC Editor in identifying and improving sorting these out. > Section 3.1 provides useful examples: > > An SIIT implementation MUST include an Explicit Address Mapping Table > (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be > able to populate the EAMT using the implementation's normal > configuration interfaces. The implementation MAY additionally > support other ways of populating the EAMT. > > - How a SIIT implementation manages the mappings has no bearing on the > functionality. So, saying "MUST include an EAMT" is not needed. Well, without an EAM Table, there's nowhere to insert EAMs, and thus you cannot fully implement the draft. It follows logically, therefore, that an implementation MUST have an EAMT. (This is analogous to the BIB and Session Tables described in RFC6146.) That said, perhaps the above goes without saying, and the sentence in question could be rewritten to drop the "MUST". > - SHOULD be empty? At what point? During implementation? In its default configuration state. > - Why "MUST be able to populate"? Because if the operator is unable to populate the EAMT, then the functionality is pretty much useless. But then again, maybe that goes without saying too. Tore From nobody Wed Oct 14 15:22:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DBB1ACEF9; Wed, 14 Oct 2015 15:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwxk3-QDjTz0; Wed, 14 Oct 2015 15:22:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6721ACEB1; Wed, 14 Oct 2015 15:22:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4AF3C88124; Wed, 14 Oct 2015 15:22:22 -0700 (PDT) Received: from Littlejohn.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 58BC9328081A; Wed, 14 Oct 2015 15:22:21 -0700 (PDT) To: Tore Anderson References: <20151014143155.22010.51439.idtracker@ietfa.amsl.com> <20151014234908.4168256d@envy.fud.no> From: Brian Haberman X-Enigmail-Draft-Status: N1110 Message-ID: <561ED69C.9090002@innovationslab.net> Date: Wed, 14 Oct 2015 18:26:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151014234908.4168256d@envy.fud.no> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TPbs9ueUVVjoUFbdSlFoANwUq0kvBNPuH" Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: Re: [v6ops] Brian Haberman's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 22:22:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TPbs9ueUVVjoUFbdSlFoANwUq0kvBNPuH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tore, On 10/14/15 5:49 PM, Tore Anderson wrote: > Hello Brian, >=20 > * Brian Haberman >=20 >> I have no issues with the publication of this draft, but want to point= >> out that there an abundance of misuses of 2119 keywords. >=20 > If that is an acceptable way forward for you, I am hoping to get help > from the RFC Editor in identifying and improving sorting these out. The RFC Editor is not tasked with sorting out the use of 2119 keywords, so I don't think we can rely on that. That being said, my comments are non-blocking so please await guidance from Joel and/or the chairs. >=20 >> Section 3.1 provides useful examples: >> >> An SIIT implementation MUST include an Explicit Address Mapping Tab= le >> (EAMT). By default, the EAMT SHOULD be empty. The operator MUST b= e >> able to populate the EAMT using the implementation's normal >> configuration interfaces. The implementation MAY additionally >> support other ways of populating the EAMT. >> >> - How a SIIT implementation manages the mappings has no bearing on the= >> functionality. So, saying "MUST include an EAMT" is not needed. >=20 > Well, without an EAM Table, there's nowhere to insert EAMs, and thus > you cannot fully implement the draft. It follows logically, therefore, > that an implementation MUST have an EAMT. (This is analogous to the BIB= > and Session Tables described in RFC6146.) I can accomplish the same mapping using a Patricia Trie or similar data structures. >=20 > That said, perhaps the above goes without saying, and the sentence in > question could be rewritten to drop the "MUST". >=20 >> - SHOULD be empty? At what point? During implementation? >=20 > In its default configuration state. >=20 >> - Why "MUST be able to populate"? >=20 > Because if the operator is unable to populate the EAMT, then the > functionality is pretty much useless. But then again, maybe that goes > without saying too. I should have continued the quote. Yes, the operator needs to be able to populate the table. But, that doesn't have to be its "normal" configuration interface, right? Yes, some of my comments are a bit pedantic, but I get concerned when 2119 keywords are used when they are not needed. For example, would this text work (or something similar) for the first paragraph of 3.1? A SIIT implementation includes a conceptual table that maps between IPv4 and IPv6 prefixes/addresses. An operator populates the conceptual table to provide the mappings between the two address families. How the SIIT implementation provides the interface for adding these mappings is out of scope for this document. I will reiterate that this is all non-blocking. Regards, Brian --TPbs9ueUVVjoUFbdSlFoANwUq0kvBNPuH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWHtaiAAoJEBOZRqCi7goqKkkIAL80YJHAg2bCGq+BNNYoBGN7 ALJt6c5IFpi4NmYB5GbU1nH1d1GXO/T/kvxrvhCnUhs0O9XY6K8UfAvZ/mesmZOO x02BoCatAr5XKn4poYfWGd782sTYWtGYkc9o/o2kdDlolaRfhgw9N8YNLBHlDp6f z1ojptje3IHQoI0i6f5Py8HdEX3yZXIQpJEE39kmGnxO2hTSSCRYT1jy52OIa5wu /XGatuoLsaOTO1Y25RznmO+KxvcQyqA0Hc7IJbkv36WY7xiTI/DlEeySA42Kl26X c/KVJrpDhg9FzCngHgVKW2KcHZX6Xf4f925XxbQ9JCz553uEKthxGMasXV4XMSY= =tiLK -----END PGP SIGNATURE----- --TPbs9ueUVVjoUFbdSlFoANwUq0kvBNPuH-- From nobody Wed Oct 14 16:43:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459FB1A8AEA; Wed, 14 Oct 2015 16:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw6rPggxN2FL; Wed, 14 Oct 2015 16:43:50 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2DF1A8AE5; Wed, 14 Oct 2015 16:43:50 -0700 (PDT) Received: from [2a02:fe0:c410:d91::8b1] (port=53644 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZmVhy-000238-K6; Thu, 15 Oct 2015 01:43:46 +0200 Date: Thu, 15 Oct 2015 01:43:46 +0200 From: Tore Anderson To: Brian Haberman Message-ID: <20151015014346.17b6b0f5@envy.fud.no> In-Reply-To: <561ED69C.9090002@innovationslab.net> References: <20151014143155.22010.51439.idtracker@ietfa.amsl.com> <20151014234908.4168256d@envy.fud.no> <561ED69C.9090002@innovationslab.net> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-eam.shepherd@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-siit-eam.ad@ietf.org Subject: Re: [v6ops] Brian Haberman's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 23:43:52 -0000 Hi again Brian, * Brian Haberman > The RFC Editor is not tasked with sorting out the use of 2119 > keywords, so I don't think we can rely on that. That being said, my > comments are non-blocking so please await guidance from Joel and/or > the chairs. Okay. In that case, I would appreciate any suggestions on how to improve the text. I will readily admit to not having much experience in writing formal and "pedantically correct" I-D texts. In any case, I'm very happy to let Joel/Fred/Lee decide on how to proceed. > >> Section 3.1 provides useful examples: > >> > >> An SIIT implementation MUST include an Explicit Address Mapping > >> Table (EAMT). By default, the EAMT SHOULD be empty. The operator > >> MUST be able to populate the EAMT using the implementation's normal > >> configuration interfaces. The implementation MAY additionally > >> support other ways of populating the EAMT. > >> > >> - How a SIIT implementation manages the mappings has no bearing on > >> the functionality. So, saying "MUST include an EAMT" is not > >> needed. > > > > Well, without an EAM Table, there's nowhere to insert EAMs, and thus > > you cannot fully implement the draft. It follows logically, > > therefore, that an implementation MUST have an EAMT. (This is > > analogous to the BIB and Session Tables described in RFC6146.) > > I can accomplish the same mapping using a Patricia Trie or similar > data structures. Ah, I see our disconnect now. The text doesn't (read: isn't meant to) mandate any particular way on how exactly the EAMT is stored and looked up in "under the hood". So you're absolutely free to store the EAMT in a trie or a linked list or whatever you want - as long as it looks like a table to the operator, you'd be within spec. An analogous concept would be an IP routing table. > >> - Why "MUST be able to populate"? > > > > Because if the operator is unable to populate the EAMT, then the > > functionality is pretty much useless. But then again, maybe that > > goes without saying too. > > I should have continued the quote. Yes, the operator needs to be able > to populate the table. But, that doesn't have to be its "normal" > configuration interface, right? Well, if I bought a router that's normally managed through an SSH command line interface I'd be rather annoyed if the EAMT could not be maintained through that interface. But then again, it probably goes without saying. > Yes, some of my comments are a bit pedantic, but I get concerned when > 2119 keywords are used when they are not needed. For example, would > this text work (or something similar) for the first paragraph of 3.1? > > A SIIT implementation includes a conceptual table that maps between > IPv4 and IPv6 prefixes/addresses. An operator populates the > conceptual table to provide the mappings between the two address > families. How the SIIT implementation provides the interface for > adding these mappings is out of scope for this document. Absolutely. I'll probably rewrite it to use the precise defined terms (e.g., "EAM" rather than "mapping"), but as far as the lack of RFC2119 keywords go this text is completely fine with me. Tore From nobody Wed Oct 14 22:53:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72C31B2B77; Wed, 14 Oct 2015 22:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfLM5yV1vE_R; Wed, 14 Oct 2015 22:53:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E473F1B2B76; Wed, 14 Oct 2015 22:53:21 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4204:51:e8d8:3b7c:d0c0:9e49]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9F5rJlV027914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Oct 2015 05:53:19 GMT (envelope-from joelja@bogus.com) To: Kathleen Moriarty , The IESG References: <20151014141627.7396.28624.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <561F3F4E.1000609@bogus.com> Date: Wed, 14 Oct 2015 22:53:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Thunderbird/41.0 MIME-Version: 1.0 In-Reply-To: <20151014141627.7396.28624.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vRAEVw6LbpskGtH2kMB8s308QKk01umNe" Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Kathleen Moriarty's No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 05:53:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vRAEVw6LbpskGtH2kMB8s308QKk01umNe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/14/15 7:16 AM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The following sentence int he Security Considerations section is hard t= o > read, can you adjust it? >=20 > The proxy replication results in devices not associated with the flow= > that generated the PTB being recipients of an ICMPv6 message which > contains a fragment of a packet. The proxy replication results in devices on the subnet not associated with the flow that generated the PTB, being recipients of the ICMPv6 PTB message; whi= ch contains a large fragment of the packet that exceeded the allowable MTU= =2E >=20 >=20 --vRAEVw6LbpskGtH2kMB8s308QKk01umNe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYfP04ACgkQ8AA1q7Z/VrJl/ACeOdntMd2lJfycRnBqOPt3hK9F m8YAn06rJ5AwrvMcO+dQGS/2Gr/A0m23 =KIL+ -----END PGP SIGNATURE----- --vRAEVw6LbpskGtH2kMB8s308QKk01umNe-- From nobody Thu Oct 15 00:32:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84231A00E8; Thu, 15 Oct 2015 00:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSbPo_vgUIjd; Thu, 15 Oct 2015 00:32:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5EE1A00E7; Thu, 15 Oct 2015 00:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015073253.7278.16534.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 00:32:53 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 07:32:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Authors : Fernando Gont J. Linkova Tim Chown Will(Shucheng) Liu Filename : draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt Pages : 16 Date : 2015-10-15 Abstract: This document presents real-world data regarding the extent to which packets with IPv6 extension headers are dropped in the Internet (as measured in August 2014), and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-in-real-world-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 15 00:41:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C081A064C for ; Thu, 15 Oct 2015 00:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnvla6cMc_aQ for ; Thu, 15 Oct 2015 00:41:45 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 3572F1A0100 for ; Thu, 15 Oct 2015 00:41:45 -0700 (PDT) Received: from [181.165.117.147] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZmdAP-0006se-Sc; Thu, 15 Oct 2015 09:41:39 +0200 References: <20151015073253.7278.83929.idtracker@ietfa.amsl.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 To: IPv6 Operations X-Forwarded-Message-Id: <20151015073253.7278.83929.idtracker@ietfa.amsl.com> Message-ID: <561F58C8.5010100@gont.com.ar> Date: Thu, 15 Oct 2015 04:42:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151015073253.7278.83929.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" , "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: [v6ops] Revision of "IPv6 EHs in the Real World" (Fwd: New Version Notification for draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 07:41:47 -0000 Folks, We have posted a revision of the aforementioned I-D. It is available at: The only pending changes that we had (and that were applied to this rev) was that of replacing "filtering" with "dropping" where appropriate, as suggested by Mikael and other folks. I'd note that while there was a lengthy discussion on the topic of "IPv6 EHs drops" in the v6ops list, the discussion was about text that has been removed from this I-D since the first draft-ietf version. All of the discussion regarding why operators filter packets with IPv6 EHs is now in this other document: Any comments on any of the two I-Ds will be appreciated (please update the "Subject" as appropriate). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt Date: Thu, 15 Oct 2015 00:32:53 -0700 From: internet-drafts@ietf.org To: Will Liu (Shucheng) , J. Linkova , Shucheng LIU (Will) , Tim Chown , Tim Chown , Fernando Gont , Fernando Gont , J. Linkova A new version of I-D, draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-ietf-v6ops-ipv6-ehs-in-real-world Revision: 01 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Document date: 2015-10-15 Group: v6ops Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-ehs-in-real-world-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ Htmlized: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-in-real-world-01 Abstract: This document presents real-world data regarding the extent to which packets with IPv6 extension headers are dropped in the Internet (as measured in August 2014), and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- 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 Oct 15 00:48:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE19D1A7011; Thu, 15 Oct 2015 00:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD9vv4DKU7MZ; Thu, 15 Oct 2015 00:48:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707A51A7001; Thu, 15 Oct 2015 00:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3175; q=dns/txt; s=iport; t=1444895280; x=1446104880; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sofFj94FxC+pJZDqeck+8QwIJZlLHZnPX6g8OLt+XDM=; b=IqS4pLEWbVAMYv3GWiZxQmunmpF4jOInFCTamgitSCR9x+/pPRKVFCRn 1MrTm2ZFWh3zhXK89aGxu1VtZPd+MVv36E/Rfkk4PFsVuh8nAlxdrspD3 1PIfUANMoJBXAsss5nVDK39zoDnm4QT87KJ6rD3LAdLEvrysBicvPnhT8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfBAAGWR9W/xbLJq1UCoN6brkQhgghhXsCggwBAQEBAQGBC4QnAQEEIxUtEwEQCxoCBRYLAgIJAwIBAgFFBgEMCAEBiCoNr1OTOQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKFVIR+hCoGCwEGSweCaYFFAQSHPY5ahRmIAoFYhDqDAZJ4Y4JEgUE8MwGEJoFAAQEB X-IronPort-AV: E=Sophos;i="5.17,684,1437436800"; d="scan'208";a="607622389" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 15 Oct 2015 07:47:58 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9F7lww3015690; Thu, 15 Oct 2015 07:47:58 GMT To: Spencer Dawkins , The IESG References: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <561F5A20.7040209@cisco.com> Date: Thu, 15 Oct 2015 09:47:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 07:48:04 -0000 Spencer, > Spencer Dawkins has entered the following ballot position for > draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In section 3, "Mitigation", I'm reading this. > > Mitigation of the potential for PTB messages to be mis-delivered > involves ensuring that an ICMPv6 error message is distributed to the > same anycast server responsible for the flow for which the error is > generated. Ideally, mitigation could be done by the mechanism hosts > ^^^^^^^ > use to identify the flow, by looking into the payload of the ICMPv6 > message (to determine which TCP flow it was associated with) before > making a forwarding decision. Because the encapsulated IP header > occurs at a fixed offset in the ICMP message it is not outside the > realm of possibility that routers with sufficient header processing > capability could parse that far into the payload. Employing a > mediation device that handles the parsing and distribution of PTB > messages after policy routing or on each load-balancer/server is a > possibility. > > Most of the document is about using other mitigations that make this > mitigation unnecessary, but it's still a bit odd to see Deep Packet > Inspection characterised as "ideally", now that RFC 7258 is now BCP 188, > and we've chartered TCPINC to make that DPI fail as often as possible. From a resource consumption point of view, the ideal situation would be NOT to distribute the PTB message to all anycast servers. This is a fact. Therefore, I don't have a problem with "ideally" in this context. After all, this document is not a spec on using DPI. Regards, Benoit > > Could that one word go away? > > I see in email that Fred asked if any reviews were needed before > submitting this draft for publication, and David Black suggested reviews > from INT and TSV, and that made it as far as the shepherd writeup, but > I'm not seeing a request for review popping up in TSV (at least not with > "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this > particular draft, but I wish it hadn't slipped through that particular > crack. > > Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and > yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase > that. Just something to watch for, in the future. > > And yes, Martin and I have a call set up to talk with the TSVdir triage > team next week ... > > > . > From nobody Thu Oct 15 05:43:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65631B311D; Thu, 15 Oct 2015 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43RhGsoahV_k; Thu, 15 Oct 2015 05:43:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 67E261B311C; Thu, 15 Oct 2015 05:43:13 -0700 (PDT) Received: from [181.165.117.147] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zmhs6-0008M0-56; Thu, 15 Oct 2015 14:43:02 +0200 References: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> To: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> Message-ID: <561F9F7C.2030907@si6networks.com> Date: Thu, 15 Oct 2015 09:43:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" Subject: [v6ops] Revision of "Why operators drop IPv6 packets with EHs" (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:43:16 -0000 Folks, We have revised our I-D "Operational Implications of IPv6 Packets with Extension Headers". The new revision is available at: This version hopefully addresses at least part of the comments received from Eric Vyncke. Your feedback will be very appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt Date: Thu, 15 Oct 2015 05:37:05 -0700 From: internet-drafts@ietf.org To: Gert Doering , Nick Hilliard , Shucheng LIU (Will) , Gert Doering , Warren Kumari , Will Liu (Shucheng) , Fernando Gont , Nick Hilliard , Fernando Gont , Warren Kumari A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 01 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2015-10-15 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-01 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Oct 15 05:56:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896F61B3128; Thu, 15 Oct 2015 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlPCKJdq_sUx; Thu, 15 Oct 2015 05:56:42 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1F81B2F43; Thu, 15 Oct 2015 05:56:42 -0700 (PDT) Received: by vkex70 with SMTP id x70so41245940vke.3; Thu, 15 Oct 2015 05:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V56udJ40lWGPB30RszdxaTQGIpQEHC27PWmvw8boWeA=; b=xWcXQOKJQUfsoz/qPBtnyU83JTT44KUC8zFyWLo6aU+7whdZ+dvlHZqoXLFjmGCNsz /pX+4/6XLWndHZwyHhhL3TxNwhffJ98vRLY5Ais+PF3oZi4DzmMncEpvXFpKwsk5gLWd DD/mx/1+Fk2DXct7ncpRi7ptReYmLoon2n3HT6+7ew7hi1jLvhe3JqVT97GS/S+Gx039 A9KTBoBoOez567JHD4REF4AoIJqS2A1MKQZJrf4r9HePQ0jyS2kwwW6vRXk7HoafqpsH T812uLRU9l9wpbWBWW1OvdssU6ynrOUAmpiGKHW8IkPXqraFpPhshyGWk3zjhEGasSI+ 2ocg== MIME-Version: 1.0 X-Received: by 10.31.54.134 with SMTP id d128mr5341032vka.154.1444913801229; Thu, 15 Oct 2015 05:56:41 -0700 (PDT) Received: by 10.31.54.8 with HTTP; Thu, 15 Oct 2015 05:56:41 -0700 (PDT) In-Reply-To: <561F5A20.7040209@cisco.com> References: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> <561F5A20.7040209@cisco.com> Date: Thu, 15 Oct 2015 07:56:41 -0500 Message-ID: From: Spencer Dawkins at IETF To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11438ee8da7f1e0522243506 Archived-At: Cc: v6ops list , The IESG , draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:56:45 -0000 --001a11438ee8da7f1e0522243506 Content-Type: text/plain; charset=UTF-8 Hi, Benoit, On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise wrote: > Spencer, > > Spencer Dawkins has entered the following ballot position for >> draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In section 3, "Mitigation", I'm reading this. >> >> Mitigation of the potential for PTB messages to be mis-delivered >> involves ensuring that an ICMPv6 error message is distributed to the >> same anycast server responsible for the flow for which the error is >> generated. Ideally, mitigation could be done by the mechanism hosts >> ^^^^^^^ >> use to identify the flow, by looking into the payload of the ICMPv6 >> message (to determine which TCP flow it was associated with) before >> making a forwarding decision. Because the encapsulated IP header >> occurs at a fixed offset in the ICMP message it is not outside the >> realm of possibility that routers with sufficient header processing >> capability could parse that far into the payload. Employing a >> mediation device that handles the parsing and distribution of PTB >> messages after policy routing or on each load-balancer/server is a >> possibility. >> Most of the document is about using other mitigations that make this >> mitigation unnecessary, but it's still a bit odd to see Deep Packet >> Inspection characterised as "ideally", now that RFC 7258 is now BCP 188, >> and we've chartered TCPINC to make that DPI fail as often as possible. >> > From a resource consumption point of view, the ideal situation would be > NOT to distribute the PTB message to all anycast servers. This is a fact. > Therefore, I don't have a problem with "ideally" in this context. After > all, this document is not a spec on using DPI. I agree with your observation. I would think that in order for something to be ideal, it should be possible (ideally we should be able to send packets at greater than the speed of light, but we can't, so. Ideally we should be able to send the PTB only to the place it needs to go, but we can't, so). But I'm a TSV guy who is poking at this because of RFC 7258, so if the SEC folk don't care, I'm fine. Spencer > Regards, Benoit > >> >> Could that one word go away? >> >> I see in email that Fred asked if any reviews were needed before >> submitting this draft for publication, and David Black suggested reviews >> from INT and TSV, and that made it as far as the shepherd writeup, but >> I'm not seeing a request for review popping up in TSV (at least not with >> "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this >> particular draft, but I wish it hadn't slipped through that particular >> crack. >> >> Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and >> yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase >> that. Just something to watch for, in the future. >> >> And yes, Martin and I have a call set up to talk with the TSVdir triage >> team next week ... >> >> >> . >> >> > --001a11438ee8da7f1e0522243506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Benoit,

On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise <bclaise@cisco.c= om> wrote:
Spencer,

Spencer Dawkins has entered the following ballot position for
draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-v6ops-pmtud-ecmp-problem/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 3, "Mitigation", I'm reading this.

=C2=A0 =C2=A0 Mitigation of the potential for PTB messages to be mis-delive= red
=C2=A0 =C2=A0 involves ensuring that an ICMPv6 error message is distributed= to the
=C2=A0 =C2=A0 same anycast server responsible for the flow for which the er= ror is
=C2=A0 =C2=A0 generated.=C2=A0 Ideally, mitigation could be done by the mec= hanism hosts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^
=C2=A0 =C2=A0 use to identify the flow, by looking into the payload of the = ICMPv6
=C2=A0 =C2=A0 message (to determine which TCP flow it was associated with) = before
=C2=A0 =C2=A0 making a forwarding decision.=C2=A0 Because the encapsulated = IP header
=C2=A0 =C2=A0 occurs at a fixed offset in the ICMP message it is not outsid= e the
=C2=A0 =C2=A0 realm of possibility that routers with sufficient header proc= essing
=C2=A0 =C2=A0 capability could parse that far into the payload.=C2=A0 Emplo= ying a
=C2=A0 =C2=A0 mediation device that handles the parsing and distribution of= PTB
=C2=A0 =C2=A0 messages after policy routing or on each load-balancer/server= is a
=C2=A0 =C2=A0 possibility.
=C2=A0 =C2=A0 Most of the document is about using other mitigations that ma= ke this
mitigation unnecessary, but it's still a bit odd to see Deep Packet
Inspection characterised as "ideally", now that RFC 7258 is now B= CP 188,
and we've chartered TCPINC to make that DPI fail as often as possible.<= br>
>From a resource consumption point of view, the ideal situation would be NOT= to distribute the PTB message to all anycast servers. This is a fact. Ther= efore, I don't have a problem with "ideally" in this context.= After all, this document is not a spec on using DPI.

=
I agree with your observation. I would think that in order for s= omething to be ideal, it should be possible (ideally we should be able to s= end packets at greater than the speed of light, but we can't, so. Ideal= ly we should be able to send the PTB only to the place it needs to go, but = we can't, so).=C2=A0

But I'm a TSV guy who= is poking at this because of RFC 7258, so if the SEC folk don't care, = I'm fine.

Spencer
=C2=A0
Regards, Benoit

Could that one word go away?

I see in email that Fred asked if any reviews were needed before
submitting this draft for publication, and David Black suggested reviews from INT and TSV, and that made it as far as the shepherd writeup, but
I'm not seeing a request for review popping up in TSV (at least not wit= h
"PMTUD" and "V6OPS" in an e-mail). I don't have con= cerns about this
particular draft, but I wish it hadn't slipped through that particular<= br> crack.

Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and
yes, there was an IETF Last Call, so I'm not hitting "Defer" = to chase
that. Just something to watch for, in the future.

And yes, Martin and I have a call set up to talk with the TSVdir triage
team next week ...


 .



--001a11438ee8da7f1e0522243506-- From nobody Thu Oct 15 06:32:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3741B2B5E; Thu, 15 Oct 2015 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NiMTiDnto5T; Thu, 15 Oct 2015 06:32:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF961B31DA; Thu, 15 Oct 2015 06:32:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015133232.9056.27955.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 06:32:32 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-dc@ietf.org Subject: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-03: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:32:34 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-v6ops-siit-dc-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would have thought that the BR and ER would be new targets for DoS attack, however, I'm not sure those are really different in this respect compared to other existing routers in a data centre - did the wg consider if there are any such differences that are worth noting? (I thought about it for 2 minutes, without finding any;-) From nobody Thu Oct 15 06:42:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD81B3214; Thu, 15 Oct 2015 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-Hgs51YC019; Thu, 15 Oct 2015 06:42:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB761A1EFE; Thu, 15 Oct 2015 06:42:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015134204.15626.94656.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 06:42:04 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-siit-dc-2xlat@ietf.org Subject: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:42:06 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-v6ops-siit-dc-2xlat-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.2.1: I don't quite get the last sentence, and it sounds a bit like it might be somewhat hacky - can you explain that some more to me? Thanks. From nobody Thu Oct 15 06:59:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC971B3240; Thu, 15 Oct 2015 06:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnZfLYHSMrwK; Thu, 15 Oct 2015 06:59:33 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD701B3242; Thu, 15 Oct 2015 06:59:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id EDCC838; Thu, 15 Oct 2015 15:59:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1444917568; bh=BUuAMksv/2A+jsChBadYUdxGa9/ZfJX+xcifOy/hon4=; b=G PoCgsALA4jlPcQyqvOXsi+LE/rOrXtg5KVU5olcgYc4ENsVOCIKO79YK28jeXNab JfhpSFw84oX6shxC6GR56iat/zWgRe/xUI2/9F5d//af0KUCy/lfKGkOFX7KehL6 e+kt89SfdSBZwSe+P40e1KNokNdNr4EByjoW7vsN7c= 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 CYily5yjcORB; Thu, 15 Oct 2015 15:59:28 +0200 (CEST) Received: from [IPv6:2a00:8640:1::3c04:b1d8:9444:4243] (unknown [IPv6:2a00:8640:1:0:3c04:b1d8:9444:4243]) by mail.sintact.nl (Postfix) with ESMTPSA id 25B6037; Thu, 15 Oct 2015 15:59:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <20151015134204.15626.94656.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 15:59:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D242FE7-9830-4611-8480-3A8BDCD565A8@steffann.nl> References: <20151015134204.15626.94656.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3094) Archived-At: Cc: fred.baker@cisco.com, v6ops@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-siit-dc-2xlat@ietf.org Subject: Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-2xlat-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:59:35 -0000 Hi Stephen, > Op 15 okt. 2015, om 15:42 heeft Stephen Farrell = het volgende geschreven: >=20 > [...] >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 3.2.1: I don't quite get the last sentence, and it sounds > a bit like it might be somewhat hacky - can you explain > that some more to me? Thanks. It just says that the ER could do (proxy-like?) ND to attract IPv6 = traffic for the service addresses. As the ER is actually responsible for = handling/translating traffic to those addresses it doesn't sound very = hacky to me. Cheers, Sander From nobody Thu Oct 15 07:32:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040521B32D7; Thu, 15 Oct 2015 07:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF9YgQOfjxdS; Thu, 15 Oct 2015 07:32:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2BA1B3299; Thu, 15 Oct 2015 07:32:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015143214.25716.96146.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 07:32:14 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com Subject: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-siit-eam-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:32:16 -0000 Benoit Claise has entered the following ballot position for draft-ietf-v6ops-siit-eam-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for answering my comment. Regards, Benoit From nobody Thu Oct 15 08:18:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C11A8892 for ; Thu, 15 Oct 2015 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuO0ZA7cMpMu for ; Thu, 15 Oct 2015 08:18:37 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1191B3374 for ; Thu, 15 Oct 2015 08:18:31 -0700 (PDT) Received: by iofl186 with SMTP id l186so93440397iof.2 for ; Thu, 15 Oct 2015 08:18:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VUjrmPn1DUYy6zOt7kGKcrEuv1CNaNeYpzAzerJfius=; b=EjgapCDkIcvsrkpxSrx3cuIuTIiWPbjiqH4LONUn7JJV4Q7BPtuRSBtqz5hD4UD/YL Xq8+5lgJhT9AVpBzitpMqlFQ2rolUROtytlVZ5f3VbZWHS71F66eahnUu1XbcsLScx5t 1rXfMTBUcDkPi8p7OiEjLozBJEnNp25PoiIsz5aDOT1Ab3lrmVXBDdjvsTNdkU60gFD5 2mcxHYrRu8iKyV8Tx+FR/GjZkV8yeqgsf0OgAzz6OpLwQ+9tqa5HApgrnQZvtQBz5j5N ZHcVq04hnOqv3jsrxoxKovUm2lQ6thrA/+nCASBIKoD9lo4mJsBEdauTg5lTewB0N6D6 Srfg== X-Gm-Message-State: ALoCoQkZkEopd8zYZVs/Zm2+q2nK5cfNZnlcqTDjybqiitMmUk3a2nOGdbqKFGNVvhuwZReAjkBE MIME-Version: 1.0 X-Received: by 10.107.16.158 with SMTP id 30mr8015482ioq.50.1444922310561; Thu, 15 Oct 2015 08:18:30 -0700 (PDT) Received: by 10.107.25.74 with HTTP; Thu, 15 Oct 2015 08:18:30 -0700 (PDT) In-Reply-To: <561F9F7C.2030907@si6networks.com> References: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> <561F9F7C.2030907@si6networks.com> Date: Thu, 15 Oct 2015 08:18:30 -0700 Message-ID: From: Tom Herbert To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations , "opsawg@ietf.org" Subject: Re: [v6ops] Revision of "Why operators drop IPv6 packets with EHs" (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:18:42 -0000 On Thu, Oct 15, 2015 at 5:43 AM, Fernando Gont wrote: > Folks, > > We have revised our I-D "Operational Implications of IPv6 Packets with > Extension Headers". > > The new revision is available at: > > > This version hopefully addresses at least part of the comments received > from Eric Vyncke. > > Your feedback will be very appreciated. > Hi Fernado, In section 4.1.3: "As layer-4 port information increases the entropy of the hash, it is highly desirable to use it where possible." IMO, the use of IPv6 flow label for ECMP as described in RFC6438 is a much better solution to target. The flow label can provide the equivalent of layer-4 entropy without requiring devices to parse the transport layer. This will work not only with extension headers present, as well as other "unusual" protocols that devices may not or cannot parse like GRE, IPIP, ESP, etc. Major OSes are now setting flow labels for entropy, and AFAIK some switch and NIC vendors now have support to use flow label as input to ECMP hash. It might be worth it to mention this alternative in the draft. Thanks, Tom > Thanks! > > Best regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt > Date: Thu, 15 Oct 2015 05:37:05 -0700 > From: internet-drafts@ietf.org > To: Gert Doering , Nick Hilliard , > Shucheng LIU (Will) , Gert Doering > , Warren Kumari , Will Liu (Shucheng) > , Fernando Gont , Nick > Hilliard , Fernando Gont , Warren > Kumari > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 01 > Title: Operational Implications of IPv6 Packets with Extension Headers > Document date: 2015-10-15 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-01 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 15 08:37:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9E1B3381; Thu, 15 Oct 2015 08:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe9dKSVYtv3D; Thu, 15 Oct 2015 08:37:16 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 554401B3215; Thu, 15 Oct 2015 08:37:16 -0700 (PDT) Received: from [190.19.233.70] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zmkac-0001CH-EQ; Thu, 15 Oct 2015 17:37:10 +0200 To: Tom Herbert References: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> <561F9F7C.2030907@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <561FC729.4070701@si6networks.com> Date: Thu, 15 Oct 2015 12:32:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , "opsawg@ietf.org" Subject: Re: [v6ops] Revision of "Why operators drop IPv6 packets with EHs" (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:37:18 -0000 Hi, Tom, Thanks so much for your prompt feedback! Please find my comments in-line... On 10/15/2015 12:18 PM, Tom Herbert wrote: > Hi Fernado, > > In section 4.1.3: > > "As layer-4 port information increases the entropy of the hash, it is > highly desirable to use it where possible." > > IMO, the use of IPv6 flow label for ECMP as described in RFC6438 is a > much better solution to target. The flow label can provide the > equivalent of layer-4 entropy without requiring devices to parse the > transport layer. This will work not only with extension headers > present, as well as other "unusual" protocols that devices may not or > cannot parse like GRE, IPIP, ESP, etc. I agree with this. But my understanding was that implementations we're still setting this to 0 -- that's why this wasn't mentioned as an option. > Major OSes are now setting flow > labels for entropy, and AFAIK some switch and NIC vendors now have > support to use flow label as input to ECMP hash. It might be worth it > to mention this alternative in the draft. I guess that mean Linux, Mac OS, *BSD, and MS Windows? If you know of anything we can reference regarding this change, that would be awesome. -- I will try to perform some tests myself, anyway. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Oct 15 09:08:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF911A6F49 for ; Thu, 15 Oct 2015 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqUPiyGMtpQC for ; Thu, 15 Oct 2015 09:08:21 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2B11AC3F7 for ; Thu, 15 Oct 2015 09:08:21 -0700 (PDT) Received: by ioii196 with SMTP id i196so94575332ioi.3 for ; Thu, 15 Oct 2015 09:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4bbg5BynOw1tqMeu6+2sCNpL6Oh2qEeRVxrjHYgosJQ=; b=c99mpr4eKzad9BKwsnl/5uzvl66eihrSCojADiOk9Y+jRHr3I8BD85mdbmMXTwWh4V eQReHVjJVimA9EQHC6ewG3ycR4kFP8Mz5BcnCyQIDNLbZD2v00UNH98jFpNKUNaf/eIP PVt0cJnJN01+FanlZ+EUt4sqA7epF5R5uSoFATNWx98uGh+ng/eVsQAlDT0PvWb0Cudq EgzUAhCONI4Xb+CgBot+h5KuKk6lTv7JxxUMbAYO+7G/LGzrEWgfKl77RLLUZiuk8Xa3 y0MJ3gQxJWbc65G+GGOPhK7LnWItlEdshPkNBcVvpeJLt5tVOWx03yhTMjm3zafzC85+ tnAA== X-Gm-Message-State: ALoCoQnebQOQ1irmTvoUMFHXHeVpv4wCmPBfJCyCTJq4ZPw3S0O5wJ3bfQKPqXFhAT3S/831KkIT MIME-Version: 1.0 X-Received: by 10.107.16.158 with SMTP id 30mr8364287ioq.50.1444925300797; Thu, 15 Oct 2015 09:08:20 -0700 (PDT) Received: by 10.107.25.74 with HTTP; Thu, 15 Oct 2015 09:08:20 -0700 (PDT) In-Reply-To: <561FC729.4070701@si6networks.com> References: <20151015123705.4548.36728.idtracker@ietfa.amsl.com> <561F9F7C.2030907@si6networks.com> <561FC729.4070701@si6networks.com> Date: Thu, 15 Oct 2015 09:08:20 -0700 Message-ID: From: Tom Herbert To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations , "opsawg@ietf.org" Subject: Re: [v6ops] Revision of "Why operators drop IPv6 packets with EHs" (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:08:23 -0000 >> Major OSes are now setting flow >> labels for entropy, and AFAIK some switch and NIC vendors now have >> support to use flow label as input to ECMP hash. It might be worth it >> to mention this alternative in the draft. > > I guess that mean Linux, Mac OS, *BSD, and MS Windows? > > If you know of anything we can reference regarding this change, that > would be awesome. -- I will try to perform some tests myself, anyway. > Mac OS (and BSD) is already deployed with setting non-zero flow labels which we have verified. Starting with Linux 4.3 flow labels will be set by default. I don't know about Windows. Within the data center network we view the use of flow labels for ECMP as a critical feature since it eliminates one barrier we have to deploying extension headers or new/alternative protocols. Switches should not need to parse the transport layer for packet forwarding, only edge devices will need to parse transport headers to implement security. Tom > Thanks so much! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Oct 15 16:26:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1551A8868 for ; Thu, 15 Oct 2015 16:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKn9Jo0-ne07 for ; Thu, 15 Oct 2015 16:26:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EFC1A8866 for ; Thu, 15 Oct 2015 16:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4403; q=dns/txt; s=iport; t=1444951586; x=1446161186; h=from:to:subject:date:message-id:mime-version; bh=HaCaD270nks+/0D7QsRBnU8iQt3iO1cju4dufA2E4RY=; b=hi/M08S1fwQb1Vc6Kpave4XyudjZcBLtz/GruoVhMUcxDzjKzhZQn+S3 7PXbK3X/QbQ0E6RR6felAnoHGVf7Q0AYua2MV+xOKzqoWhTtW+GiJ3zc5 T5tQ3ulcnB/OKcNfZsO/FIQXeytyOLe+xviui/nm24jBC5oLdgy3223SR w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKAgCUNSBW/5BdJa1egyZUdLkfhCEOgVkhhzQ4FAEBAQEBAQF/C4Qtbh0BgQAnBCGIIA2gQKMkAQEBAQEBBAEBAQEBAQEBFgSJBoscgRQFlh0Bgk2BYYhsnA8BHwFDhAOFUoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="asc'?scan'208";a="198363725" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 15 Oct 2015 23:26:25 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9FNQO2b008252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Oct 2015 23:26:24 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 18:26:09 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 18:26:09 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Preliminary Agenda for IETF 94: opportunity to bash the agenda Thread-Index: AQHRB6DfkSYCSrXcTUSCBvWu2GC1ww== Date: Thu, 15 Oct 2015 23:26:09 +0000 Message-ID: <46CC9607-BA69-464D-ADE7-B3FA65F252DB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.124] Content-Type: multipart/signed; boundary="Apple-Mail=_B4B4C6D3-8B38-4D14-AE8F-D25D7D1243B5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Preliminary Agenda for IETF 94: opportunity to bash the agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 23:26:27 -0000 --Apple-Mail=_B4B4C6D3-8B38-4D14-AE8F-D25D7D1243B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lee and I have posted a proposed agenda based on what's in the queue = today. I can imagine drafts being posted between now and Monday evening = and people commenting that they find the topics brilliantly interesting. = Barring that, and barring people bashing this agenda, this is what we'll = be looking at. https://www.ietf.org/proceedings/94/agenda/agenda-94-v6ops Summarizing the chairs' objectives in the meeting: draft-herbert-nvo3-ila-01.txt is actually from the nvo3 WG, but the = author contacted me saying he thought v6ops or 6man might find it = interesting. I asked the list, and some found it interesting. It is also = relevant to the /64-to-the-host discussion. draft-ietf-v6ops-host-addr-availability is currently stuck in a mailing = list discussion. The authors like its proposal, as do at least some = others in the WG. Owen Delong would like to see a longer prefix, and = Barbara Stark wants the scope for the recommendation more clearly = spelled out. The chairs would like to finish the discussion. The chairs would also like to finish the discussions of = draft-bao-v6ops-rfc6145bis and draft-ietf-v6ops-ipv6-ehs-in-real-world. Fernando would like to see draft-gont-v6ops-ipv6-ehs-packet-drops = adopted by the working group. The chairs have a number of questions, and = would like to see a game plan for the draft, whatever that game plan = might be. As you can see following, we have a number of other drafts that we don't = know what to do with as they have not been updated since IETF 93 (we = also have six that are in their way into history). Some belong, per the = discussion in Prague, in sunset4 (my error, regarding IPv4-as-a-service) = and should be discussed on the sunset4 list. As to the rest, we want to = know the working group's viewpoint - finish them, kill them, or = something else? ISE Queue 2015-10-14 draft-ietf-v6ops-mobile-device-profile Approved-announcement to be sent 2015-10-15 draft-ietf-v6ops-pmtud-ecmp-problem 2015-10-15 draft-ietf-v6ops-siit-dc 2015-10-15 draft-ietf-v6ops-siit-dc-2xlat 2015-10-15 draft-ietf-v6ops-siit-eam In IETF Last Call 2015-10-14 draft-ietf-v6ops-reducing-ra-energy-consumption Unupdated WG Document 2015-07-06 draft-ietf-v6ops-dhcpv6-slaac-problem 2015-05-03 draft-ietf-v6ops-ula-usage-recommendations 2015-07-06 draft-ietf-v6ops-design-choices Updated WG Document 2015-10-15 draft-ietf-v6ops-ipv6-ehs-in-real-world 2015-09-03 draft-ietf-v6ops-host-addr-availability Unupdated Individual Submission 2015-07-06 draft-akira-v6ops-mape-experience 2015-07-06 draft-xcf-v6ops-chinatelecom-deployment 2015-07-05 draft-hui-v6ops-ipv6trans-select-nfv 2015-07-05 draft-xli-v6ops-cernet-deployment 2015-07-05 draft-yang-v6ops-ipv6tran-select 2015-06-26 draft-vyncke-v6ops-ipv6-only-thin-clients 2015-06-25 draft-sun-v6ops-xlat-multi Updated Individual Submission 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops 2015-10-10 draft-bao-v6ops-rfc6145bis 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack --Apple-Mail=_B4B4C6D3-8B38-4D14-AE8F-D25D7D1243B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBViA2HUayAOS/EQ8MAQJnCw/8D/OMpQrXnTTCfLf3vBlxY3wBMGCB81c3 /+G+DqDxrXWd7cugFlifPRDLFvzHSp8JReAgWZvlXorpsf7EelEItBgdn1BXw/Uu hFlxy/U6mJsPXL3by/E2HS0YeRRJcfcZ3C7YyV/aP2pNTUMId8bTnMoFmDMT6+hs csaN0ELD4he9O050SEIGLci6Hj8c1aQjT/MZLJqA+fRPzWnWnGg/bU4eA3+ZDKVk Ey31lxjJM4pEQnFJwxAnQRZTWP5SDGEmA3YQ3F3ii5EgAqoHeFuJmEChwER39KEM XOTQVHh6YiPHfNdSSf3vDqfzPnudG+Lis63oJixLWnUDx1JbTtbCaRrv3XP3AFUy 3aGuxRZftD6P0ffWr3U5Oc+qn8yT0q+PTY7YrKBFwa8IRXZqsSMUFW+JhUlq7cp3 iJFeEQ3dAVU0+b6Hym0U+Kcy3eBRJVGEwJ8otjdvS8SHu4VyfXAoxjJqh3IMJjRX V1OazaYxdPAweXpBgIXfUCityRMLsBY2oAvO+5BpgYhJ9TVBMZ8VWYIa5kqAAaPr FtXSKLATDZueJCE60+kBX3/Gil9YCeHU0lPWjUEt5NYsZrJGRUuoF2W+W7LHMp0Y oThpL/2er+i0A/20RJcujM2hx9DHggkqbhhosgFDiCb8oETgF3lx6YbxMqTpJo0P UIG/7UnjW3o= =Z3wR -----END PGP SIGNATURE----- --Apple-Mail=_B4B4C6D3-8B38-4D14-AE8F-D25D7D1243B5-- From nobody Fri Oct 16 01:01:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A164C1B304A; Fri, 16 Oct 2015 01:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATQ4WXMTV3IP; Fri, 16 Oct 2015 01:01:08 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6611B3049; Fri, 16 Oct 2015 01:01:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t9G80pHB021984; Fri, 16 Oct 2015 09:00:51 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t9G80pHB021984 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1444982451; bh=svhHc6015RcTOKYM7bZUwogulkE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=P7Hdo/lZCJ7sZr3tpeA46lEzYfzH9GDx6J86kWScgkX3W1Xp61PZW60Z+rOMfWSgB 2Vx877KiD0nVSqTBPDL/nKDxY6a7P7v+u2UtxKwW3QXJpEsOVMogRdnigLYL1A9HDx 8c0pyk903LyQyszLy2pYKmcFMNnyUP/yGkPEvk5E= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r9F90p0608107903dJ ret-id none; Fri, 16 Oct 2015 09:00:51 +0100 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:7592:f905:231:a3d4] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t9FK6ADf021521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Oct 2015 21:06:10 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_0EF6FF4A-0856-4B7C-846E-5454D310A0EF" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Tim Chown In-Reply-To: Date: Thu, 15 Oct 2015 21:06:12 +0100 Message-ID: References: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> <561F5A20.7040209@cisco.com> <2F7D0142-5BE8-4FD4-A012-2AC0497B6D1A@ecs.soton.ac.uk> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3094) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r9F8g9060810790300; tid=r9F90p0608107903dJ; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=18 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t9G80pHB021984 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: v6ops list , The IESG , draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 08:01:10 -0000 --Apple-Mail=_0EF6FF4A-0856-4B7C-846E-5454D310A0EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 15 Oct 2015, at 13:56, Spencer Dawkins at IETF = wrote: >=20 > Hi, Benoit, >=20 > On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise > wrote: > Spencer, >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In section 3, "Mitigation", I'm reading this. >=20 > Mitigation of the potential for PTB messages to be mis-delivered > involves ensuring that an ICMPv6 error message is distributed to = the > same anycast server responsible for the flow for which the error = is > generated. Ideally, mitigation could be done by the mechanism = hosts > ^^^^^^^ > use to identify the flow, by looking into the payload of the = ICMPv6 > message (to determine which TCP flow it was associated with) = before > making a forwarding decision. Because the encapsulated IP header > occurs at a fixed offset in the ICMP message it is not outside the > realm of possibility that routers with sufficient header = processing > capability could parse that far into the payload. Employing a > mediation device that handles the parsing and distribution of PTB > messages after policy routing or on each load-balancer/server is a > possibility. > Most of the document is about using other mitigations that make = this > mitigation unnecessary, but it's still a bit odd to see Deep Packet > Inspection characterised as "ideally", now that RFC 7258 is now BCP = 188, > and we've chartered TCPINC to make that DPI fail as often as possible. > >=46rom a resource consumption point of view, the ideal situation = would be NOT to distribute the PTB message to all anycast servers. This = is a fact. Therefore, I don't have a problem with "ideally" in this = context. After all, this document is not a spec on using DPI. >=20 > I agree with your observation. I would think that in order for = something to be ideal, it should be possible (ideally we should be able = to send packets at greater than the speed of light, but we can't, so. = Ideally we should be able to send the PTB only to the place it needs to = go, but we can't, so).=20 None of the mitigations are =E2=80=98ideal=E2=80=99. But the document is useful for noting the problem,describing it well, = and discussing wha *could* be done. Tim >=20 > But I'm a TSV guy who is poking at this because of RFC 7258, so if the = SEC folk don't care, I'm fine. >=20 > Spencer > =20 > Regards, Benoit >=20 > Could that one word go away? >=20 > I see in email that Fred asked if any reviews were needed before > submitting this draft for publication, and David Black suggested = reviews > from INT and TSV, and that made it as far as the shepherd writeup, but > I'm not seeing a request for review popping up in TSV (at least not = with > "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this > particular draft, but I wish it hadn't slipped through that particular > crack. >=20 > Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, = and > yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase > that. Just something to watch for, in the future. >=20 > And yes, Martin and I have a call set up to talk with the TSVdir = triage > team next week ... >=20 >=20 > . >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_0EF6FF4A-0856-4B7C-846E-5454D310A0EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 15 Oct 2015, at 13:56, = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Benoit,

On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise = <bclaise@cisco.com> wrote:
Spencer,

Spencer Dawkins has entered the following ballot position for
draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-pr= oblem/



= ----------------------------------------------------------------------
COMMENT:
= ----------------------------------------------------------------------

In section 3, "Mitigation", I'm reading this.

    Mitigation of the potential for PTB messages to be = mis-delivered
    involves ensuring that an ICMPv6 error message is = distributed to the
    same anycast server responsible for the flow for which the = error is
    generated.  Ideally, mitigation could be done by the = mechanism hosts
                ^^^^^^^
    use to identify the flow, by looking into the payload of = the ICMPv6
    message (to determine which TCP flow it was associated = with) before
    making a forwarding decision.  Because the = encapsulated IP header
    occurs at a fixed offset in the ICMP message it is not = outside the
    realm of possibility that routers with sufficient header = processing
    capability could parse that far into the payload.  = Employing a
    mediation device that handles the parsing and distribution = of PTB
    messages after policy routing or on each = load-balancer/server is a
    possibility.
    Most of the document is about using other mitigations that = make this
mitigation unnecessary, but it's still a bit odd to see Deep Packet
Inspection characterised as "ideally", now that RFC 7258 is now BCP = 188,
and we've chartered TCPINC to make that DPI fail as often as = possible.
>=46rom a resource consumption point of view, the ideal situation = would be NOT to distribute the PTB message to all anycast servers. This = is a fact. Therefore, I don't have a problem with "ideally" in this = context. After all, this document is not a spec on using = DPI.

I = agree with your observation. I would think that in order for something = to be ideal, it should be possible (ideally we should be able to send = packets at greater than the speed of light, but we can't, so. Ideally we = should be able to send the PTB only to the place it needs to go, but we = can't, so). 

None of the mitigations are =E2=80=98ideal=E2=80=99.

But the document is useful for noting = the problem,describing it well, and discussing wha *could* be = done.

Tim


But I'm a TSV guy who is poking at this because of RFC 7258, = so if the SEC folk don't care, I'm fine.

Spencer
 
Regards, = Benoit

Could that one word go away?

I see in email that Fred asked if any reviews were needed before
submitting this draft for publication, and David Black suggested = reviews
from INT and TSV, and that made it as far as the shepherd writeup, = but
I'm not seeing a request for review popping up in TSV (at least not = with
"PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this
particular draft, but I wish it hadn't slipped through that = particular
crack.

Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, = and
yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase
that. Just something to watch for, in the future.

And yes, Martin and I have a call set up to talk with the TSVdir = triage
team next week ...


 .



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

= --Apple-Mail=_0EF6FF4A-0856-4B7C-846E-5454D310A0EF-- From nobody Fri Oct 16 05:19:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D911A1AB9; Fri, 16 Oct 2015 05:19:28 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCN9hbZzZtch; Fri, 16 Oct 2015 05:19:21 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF271A86FF; Fri, 16 Oct 2015 05:19:21 -0700 (PDT) Received: by wijp11 with SMTP id p11so7615528wij.0; Fri, 16 Oct 2015 05:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5PIs9VpKhm466HCXmgkaItbZ1+ZQxOehfgHU/B33/zk=; b=relHq23TfQcCWEaDxAfnwp+/5iB9NzymxP65HWthyCE1EClwe3hsTgnHs4VQPLtLNR +lMGXznCHOYg6MvR1ctIInYqWkud/rebUftNH4lVTSzv89hru49fqfFPGWD9VVRnQjK/ 2nNrWT9R3nxr7V+uQeIlNqZVkoGiZeIVedBD4LxQ7ASyrgOw1pylHJtyV7bPti2oiWKM 4fqx3FRPwc3QWoPZq6U/oZuhH/2KWl4n9RDKj2TmptqzQ4gzICoaVzk8/YhsOO3D+iqJ WgVqbHjSuPUY6xlXqd+vBGxhrUlw2PaDnUJK6n90pBjCfKcNGHfLnL7x80Fr4jrvspFM dEuQ== MIME-Version: 1.0 X-Received: by 10.180.211.8 with SMTP id my8mr4362596wic.21.1444997959851; Fri, 16 Oct 2015 05:19:19 -0700 (PDT) Received: by 10.27.108.76 with HTTP; Fri, 16 Oct 2015 05:19:19 -0700 (PDT) In-Reply-To: <561D0CB7.3040606@si6networks.com> References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> Date: Fri, 16 Oct 2015 08:19:19 -0400 Message-ID: From: Rick Casarez To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c38e0e193a8b052237ce50 Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:19:28 -0000 --001a11c38e0e193a8b052237ce50 Content-Type: text/plain; charset=UTF-8 While I get amused reading such things are we sure we need lines like this in the document? "...and attempts to end the bickering on the topic, which is, for the most part, of little value in illuminating the discussion." A few parts of the introduction I think can be re-worded to express the issues professionally without getting people defensive by making the statements you are making. Rise above it. In Section 2: Firewall - I am wondering if a better definition can be made. From what you wrote I cannot distinguish between a Firewall and an ACL. No mention of state tracking for instance etc. Defense-in-depth - I think you should define this term in this section since you go on to use it in following sections. It helps by also showing the differences between it and perimeter. Section 3.3: The sentence: "By that line of reasoning, a firewall primarily protects infrastructure, by preventing traffic that would attack it from it." I think flows better as: "By that line of reasoning, a firewall primarily protects infrastructure, by preventing traffic that would attack it." or "A firewall primarily protects against infrastructure attacks." Section 5.1: "The drawback of this approach is that the security goal of "block traffic unless it is explicitly allowed" prevents useful new applications." I am not sure I understand this line. It blocks new applications from immediately traversing the firewall. I know from experience though that when a discussion is had with the NetSec team the application can be added to the allow list. So not sure a "default deny" means new stuff never gets allowed as the text insinuates. Section 6: There are temporary IPv4 addresses too. Usually the prefix is allowed with a set access or security profile. The only problems I am aware of is if you mix hosts with differing access/security profiles into one subnet. This is fixed by designating subnets for specific profiles. IPv6 is not any different and can work the same way. As for application being tunneled over well-known ports that sounds like a breakdown of communication between the Service Owners and NetSec. Simple communication *should* lead to the creation of a profile for that new application and its individual port. By doing what you describe it sounds like a Service Owner trying to get out of doing due diligence with NetSec or not knowing what port their application needs for access (More common than you might think). ------------------- Cheers, Rick Experiences not things. On Tue, Oct 13, 2015 at 9:52 AM, Fernando Gont wrote: > FYI. > > This rev hopefully addresses some/most/all of the comments received so > far (mostly by Eric Vyncke and James Woodyatt). > > More comments/feedback will be welcome. > > Thanks, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-opsawg-firewalls-analysis-01.txt > Date: Tue, 13 Oct 2015 06:45:30 -0700 > From: internet-drafts@ietf.org > To: Fred Baker , Fernando Gont > > > A new version of I-D, draft-gont-opsawg-firewalls-analysis-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-opsawg-firewalls-analysis > Revision: 01 > Title: On Firewalls in Network Security > Document date: 2015-10-13 > Group: Individual Submission > Pages: 17 > URL: > > https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/ > Htmlized: > https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-gont-opsawg-firewalls-analysis-01 > > Abstract: > This document analyzes the role of firewalls in network security, and > suggests a line of reasoning about their usage. It analyzes common > kinds of firewalls and the claims made for them. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c38e0e193a8b052237ce50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While I get amused reading such things are we sure we need lines lik= e this in the document?

"...and attempts to end the bickering o= n the topic, which is, for the most part, of little value in illuminating the discussion."=

A few parts of the introduction I think can be re-worded to e= xpress the issues professionally without getting people defensive by making= the statements you are making. Rise above it.

In Section 2:
Firewall - I am wondering if a better definition can be ma= de. From what you wrote I cannot distinguish between a Firewall and an ACL.= No mention of state tracking for instance etc.

Defense-i= n-depth - I think you should define this term in this section since you go = on to use it in following sections. It helps by also showing the difference= s between it and perimeter.

Section 3.3:

Th= e sentence:

"By that line of reasoning, a firewall primarily pr= otects infrastructure, by preventing traffic that would attack it from it."= ;

I think flows better as:

"By that line of reason= ing, a firewall primarily protects infrastructure, by preventing traffic that would attack it."
or

"A firewall primarily protects against infrastr= ucture attacks."

Section 5.1:

"The drawback o= f this approach is that the security goal of "block traffic unless it is explicitly allowed" prevents useful new applications."

I am not sure I understand this line. I= t blocks new applications from immediately traversing the firewall. I know = from experience though that when a discussion is had with the NetSec team t= he application can be added to the allow list. So not sure a "default = deny" means new stuff never gets allowed as the text insinuates.
<= br>
Section 6:

There are temporary IPv4 addresses too. Us= ually the prefix is allowed with a set access or security profile. The only= problems I am aware of is if you mix hosts with differing access/security = profiles into one subnet. This is fixed by designating subnets for specific= profiles. IPv6 is not any different and can work the same way.

As for application being tunneled over well-known ports that sounds like= a breakdown of communication between the Service Owners and NetSec. Simple= communication *should* lead to the creation of a profile for that new appl= ication and its individual port. By doing what you describe it sounds like = a Service Owner trying to get out of doing due diligence with NetSec or not= knowing what port their application needs for access (More common than you= might think).

=
-------------------
Chee= rs, Rick

Experiences not things.

On Tue, Oct 13, 2015 at 9:52 AM, Fernando Go= nt <fgont@si6networks.com> wrote:
FYI.

This rev hopefully addresses some/most/all of the comments received so
far (mostly by Eric Vyncke and James Woodyatt).

More comments/feedback will be welcome.

Thanks,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsawg-firewalls-analysis-01.txt
Date: Tue, 13 Oct 2015 06:45:30 -0700
From: internet-drafts@ietf.org<= /a>
To: Fred Baker <fred@cisco.com>= , Fernando Gont <fgont@si6netwo= rks.com>


A new version of I-D, draft-gont-opsawg-firewalls-analysis-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-opsawg-firewalls-a= nalysis
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Firewalls in Network Security Document date:=C2=A0 2015-10-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:
https://www.ietf.org= /internet-drafts/draft-gont-opsawg-firewalls-analysis-01.txt
Status:
https://datatracker.ietf.org/d= oc/draft-gont-opsawg-firewalls-analysis/
Htmlized:
https://tools.ietf.org/html/draft= -gont-opsawg-firewalls-analysis-01
Diff:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-gont-opsawg-firewalls-analysis-01

Abstract:
=C2=A0 =C2=A0This document analyzes the role of firewalls in network securi= ty, and
=C2=A0 =C2=A0suggests a line of reasoning about their usage.=C2=A0 It analy= zes common
=C2=A0 =C2=A0kinds of firewalls and the claims made for them.





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

The IETF Secretariat




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

--001a11c38e0e193a8b052237ce50-- From nobody Fri Oct 16 13:39:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9A1A033A; Fri, 16 Oct 2015 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyYecmtA78Yh; Fri, 16 Oct 2015 13:39:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 AF86D1A0235; Fri, 16 Oct 2015 13:39:18 -0700 (PDT) Received: from [190.19.233.70] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZnBmS-0004v7-NZ; Fri, 16 Oct 2015 22:39:13 +0200 To: Rick Casarez References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <562155BC.6030701@si6networks.com> Date: Fri, 16 Oct 2015 16:53:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 20:39:21 -0000 Hi, Rick, Thanks so much for your feedback! Please find my responses in-line... On 10/16/2015 09:19 AM, Rick Casarez wrote: > While I get amused reading such things are we sure we need lines like > this in the document? > > "...and attempts to end the bickering on the topic, which is, for the > most part, of little value in illuminating the discussion." > > A few parts of the introduction I think can be re-worded to express the > issues professionally without getting people defensive by making the > statements you are making. Rise above it. I'll re-check the text -- The Intro was going to be re-worked, anyway. > In Section 2: > > Firewall - I am wondering if a better definition can be made. From what > you wrote I cannot distinguish between a Firewall and an ACL. An ACL is a policy. A firewall is a device that enforces filtering policies. > No mention > of state tracking for instance etc. Ok, will try to add somethin in this respect. > Defense-in-depth - I think you should define this term in this section > since you go on to use it in following sections. Will do. > Section 3.3: > > The sentence: > > "By that line of reasoning, a firewall primarily protects > infrastructure, by preventing traffic that would attack it from it." > > I think flows better as: > > "By that line of reasoning, a firewall primarily protects > infrastructure, by preventing traffic that would attack it." > > or > > "A firewall primarily protects against infrastructure attacks." This seond option my work. (Your first option changes the meaning of the sentence). > Section 5.1: > > "The drawback of this approach is that the security goal of "block > traffic unless it is explicitly allowed" prevents useful new applications." > > I am not sure I understand this line. It blocks new applications from > immediately traversing the firewall. I know from experience though that > when a discussion is had with the NetSec team the application can be > added to the allow list. So not sure a "default deny" means new stuff > never gets allowed as the text insinuates. Well, that depends on where the firewall is being deployed, and if it is actively managed. > Section 6: > > There are temporary IPv4 addresses too. Not by definition I'd say. Or... would you mind elaborating a bit more in this respect? > As for application being tunneled over well-known ports that sounds like > a breakdown of communication between the Service Owners and NetSec. > Simple communication *should* lead to the creation of a profile for that > new application and its individual port. By doing what you describe it > sounds like a Service Owner trying to get out of doing due diligence > with NetSec or not knowing what port their application needs for access > (More common than you might think). Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls. -- Ironically, at times these protocols are referred to as "firewall friendly". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 16 14:13:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1301A1AD0; Fri, 16 Oct 2015 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtcQJTUPptO4; Fri, 16 Oct 2015 14:13:51 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4BD1A002A; Fri, 16 Oct 2015 14:13:50 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so25142251wic.1; Fri, 16 Oct 2015 14:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V5g+OCcLHbMHHyzh/GlYvcnndyM9wWLHYLTD7S+fCEg=; b=ZRURDvwGrdoriQneGudU0INPqxa2C1xSGyZcf0LARy+Pb7l0tyqIfWghGo3FqHX4KG ouyEd1UpNfSKxPoCMXU5/ufxebolOjPowW8S0+ygMg6G7zqJV/BJ2awaVIw5puD+VdoP XspxBkoJnysh4LAF8zeiiqvKnQeJ3VorX1V6J2iQ2boFn6GWB3xZ5e5H3YuIb6DTKnJp 7qREyJn60/mLBvVXE7MkgjYqeN9DGdSoFy/+/XCfaoaBPu6/0CodID1a8Rw/JNRTqjro 3b94FB/lvpjf8H365MJ1GUe6L99NtRZ7ImmhtPz7Dq53zM0b60khGr22zn+GbHP1BEh0 iF0w== MIME-Version: 1.0 X-Received: by 10.180.104.69 with SMTP id gc5mr7313825wib.69.1445030029313; Fri, 16 Oct 2015 14:13:49 -0700 (PDT) Received: by 10.194.192.40 with HTTP; Fri, 16 Oct 2015 14:13:49 -0700 (PDT) In-Reply-To: <562155BC.6030701@si6networks.com> References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> <562155BC.6030701@si6networks.com> Date: Fri, 16 Oct 2015 14:13:49 -0700 Message-ID: From: Ca By To: Fernando Gont Content-Type: multipart/alternative; boundary=f46d043bdbe6964ea605223f453b Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 21:13:53 -0000 --f46d043bdbe6964ea605223f453b Content-Type: text/plain; charset=UTF-8 I think this is important work, but i think this draft is too broad to be effective in its current form. I think it would be a great value to adopt the common enterprise network view and scope of a "stateful firewall" that most people think of... from the likes of Checkpoint, Palo Alto, ... On Fri, Oct 16, 2015 at 12:53 PM, Fernando Gont wrote: > Hi, Rick, > > Thanks so much for your feedback! Please find my responses in-line... > > On 10/16/2015 09:19 AM, Rick Casarez wrote: > > While I get amused reading such things are we sure we need lines like > > this in the document? > > > > "...and attempts to end the bickering on the topic, which is, for the > > most part, of little value in illuminating the discussion." > > > > A few parts of the introduction I think can be re-worded to express the > > issues professionally without getting people defensive by making the > > statements you are making. Rise above it. > > I'll re-check the text -- The Intro was going to be re-worked, anyway. > > > > > In Section 2: > > > > Firewall - I am wondering if a better definition can be made. From what > > you wrote I cannot distinguish between a Firewall and an ACL. > > An ACL is a policy. A firewall is a device that enforces filtering > policies. > > This defintion makes every on path device a firewall. This is not a good places to go. > > No mention > > of state tracking for instance etc. > > Ok, will try to add somethin in this respect. > > > This is the core of what 99% of the world thinks a firewall is. > > > Defense-in-depth - I think you should define this term in this section > > since you go on to use it in following sections. > > Will do. > > > > > Section 3.3: > > > > The sentence: > > > > "By that line of reasoning, a firewall primarily protects > > infrastructure, by preventing traffic that would attack it from it." > > > > I think flows better as: > > > > "By that line of reasoning, a firewall primarily protects > > infrastructure, by preventing traffic that would attack it." > > > > or > > > > "A firewall primarily protects against infrastructure attacks." > > This seond option my work. (Your first option changes the meaning of the > sentence). > > > eh...what is infrastructure... slippery slope here. > > Section 5.1: > > > > "The drawback of this approach is that the security goal of "block > > traffic unless it is explicitly allowed" prevents useful new > applications." > > > > I am not sure I understand this line. It blocks new applications from > > immediately traversing the firewall. I know from experience though that > > when a discussion is had with the NetSec team the application can be > > added to the allow list. So not sure a "default deny" means new stuff > > never gets allowed as the text insinuates. > > Well, that depends on where the firewall is being deployed, and if it is > actively managed. > > Actively managed vs not actively are worlds apart. Do not lump them together. Same with stateful vs stateless > > > > Section 6: > > > > There are temporary IPv4 addresses too. > > Not by definition I'd say. Or... would you mind elaborating a bit more > in this respect? > > > > > As for application being tunneled over well-known ports that sounds like > > a breakdown of communication between the Service Owners and NetSec. > > Simple communication *should* lead to the creation of a profile for that > > new application and its individual port. By doing what you describe it > > sounds like a Service Owner trying to get out of doing due diligence > > with NetSec or not knowing what port their application needs for access > > (More common than you might think). > > Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls. > -- Ironically, at times these protocols are referred to as "firewall > friendly". > > Yes... own the PC via Phishing or Flash, then use PCP from the PC to open all the rules you want! CB > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043bdbe6964ea605223f453b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is important work, but i think this draft is = too broad to be effective in its current form.=C2=A0 I think it would be a = great value to adopt the common enterprise network view and scope of a &quo= t;stateful firewall" that most people=C2=A0
think of... from the l= ikes of Checkpoint, Palo Alto, ...


<= div class=3D"gmail_quote">On Fri, Oct 16, 2015 at 12:53 PM, Fernando Gont <= span dir=3D"ltr"><fgont@si6networks.com> wrote:
Hi, Rick,

Thanks so much for your feedback! Please find my responses in-line...

On 10/16/2015 09:19 AM, Rick Casarez wrote:
> While I get amused reading such things are we sure we need lines like<= br> > this in the document?
>
> "...and attempts to end the bickering on the topic, which is, for= the
> most part, of little value in illuminating the discussion."
>
> A few parts of the introduction I think can be re-worded to express th= e
> issues professionally without getting people defensive by making the > statements you are making. Rise above it.

I'll re-check the text -- The Intro was going to be re-worked, a= nyway.



> In Section 2:
>
> Firewall - I am wondering if a better definition can be made. From wha= t
> you wrote I cannot distinguish between a Firewall and an ACL.

An ACL is a policy. A firewall is a device that enforces filtering p= olicies.

=C2=A0
This definti= on makes every on path device a firewall.=C2=A0 This is not a good places t= o go.


> No mention
> of state tracking for instance etc.

Ok, will try to add somethin in this respect.



This is the core of what 99% of= the world thinks a firewall is.
=C2=A0

> Defense-in-depth - I think you should define this term in this section=
> since you go on to use it in following sections.

Will do.



> Section 3.3:
>
> The sentence:
>
> "By that line of reasoning, a firewall primarily protects
> infrastructure, by preventing traffic that would attack it from it.&qu= ot;
>
> I think flows better as:
>
> "By that line of reasoning, a firewall primarily protects
> infrastructure, by preventing traffic that would attack it."
>
> or
>
> "A firewall primarily protects against infrastructure attacks.&qu= ot;

This seond option my work. (Your first option changes the meaning of= the
sentence).



eh...what is infrastructure... = slippery slope here.=C2=A0


> Section 5.1:
>
> "The drawback of this approach is that the security goal of "= ;block
> traffic unless it is explicitly allowed" prevents useful new appl= ications."
>
> I am not sure I understand this line. It blocks new applications from<= br> > immediately traversing the firewall. I know from experience though tha= t
> when a discussion is had with the NetSec team the application can be > added to the allow list. So not sure a "default deny" means = new stuff
> never gets allowed as the text insinuates.

Well, that depends on where the firewall is being deployed, and if i= t is
actively managed.


Actively manag= ed vs not actively are worlds apart.=C2=A0 Do not lump them together.
=

Same with stateful vs stateless
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

> Section 6:
>
> There are temporary IPv4 addresses too.

Not by definition I'd say. Or... would you mind elaborating a bi= t more
in this respect?



> As for application being tunneled over well-known ports that sounds li= ke
> a breakdown of communication between the Service Owners and NetSec. > Simple communication *should* lead to the creation of a profile for th= at
> new application and its individual port. By doing what you describe it=
> sounds like a Service Owner trying to get out of doing due diligence > with NetSec or not knowing what port their application needs for acces= s
> (More common than you might think).

Yes. Or, at times, a user/app trying to circumvent unmanaged firewal= ls.
-- Ironically, at times these protocols are referred to as "firewall friendly".


Yes... own the PC via Phishing or Flas= h, then use PCP from the PC to open all the rules you want!

<= /div>
CB
=C2=A0
Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




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

--f46d043bdbe6964ea605223f453b-- From nobody Sun Oct 18 05:35:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274CC1A1EF1; Sun, 18 Oct 2015 05:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVAglF89nYob; Sun, 18 Oct 2015 05:35:53 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D45B1A1BF5; Sun, 18 Oct 2015 05:35:53 -0700 (PDT) Received: by wikq8 with SMTP id q8so17132669wik.1; Sun, 18 Oct 2015 05:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LoDuQ1J6h2LokW6XxnptwZ6YAbq6HrznNEjVoH4it14=; b=C9dSsn0ZJN+SQlK+EdYw17yq7zz1B3XM2hT/KAu/VgibBpP7PeDNnwQHaHVCA+BuIa oE42xVtdOJnOcMB6Cdt7oG5NxzMVj7l4+CDNL5w2TRW1mY9/Jq2Yub3bfAyIWzZSmYam Zo+FO4JKMCNbOS56p2MQbfUA0HagjTAAFMUSDbXSPUSSHVamKPwSV0Q3MBnFjyCkNmO1 CuI4DYd37kYyYBupvCuPS6alOSjqNicgSJ5xASZYDCG7DrbfQ8jOl2nqNlCkl8k8U08y 5V3voeV7eAS3gCx+Id9veUcdH/nzlsnT2ky6xdtZ6SwWh37M/KnFhTa9599RtALN+adI U/tg== MIME-Version: 1.0 X-Received: by 10.180.211.8 with SMTP id my8mr14347969wic.21.1445171751683; Sun, 18 Oct 2015 05:35:51 -0700 (PDT) Received: by 10.27.108.76 with HTTP; Sun, 18 Oct 2015 05:35:51 -0700 (PDT) In-Reply-To: <562155BC.6030701@si6networks.com> References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> <562155BC.6030701@si6networks.com> Date: Sun, 18 Oct 2015 08:35:51 -0400 Message-ID: From: Rick Casarez To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c38e0ee60cfd05226044ae Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 12:35:56 -0000 --001a11c38e0ee60cfd05226044ae Content-Type: text/plain; charset=UTF-8 Just trying to help. Answers in line. ------------------- Cheers, Rick Experiences not things. On Fri, Oct 16, 2015 at 3:53 PM, Fernando Gont wrote: > Hi, Rick, > > Thanks so much for your feedback! Please find my responses in-line... > > On 10/16/2015 09:19 AM, Rick Casarez wrote: > > While I get amused reading such things are we sure we need lines like > > this in the document? > > > > "...and attempts to end the bickering on the topic, which is, for the > > most part, of little value in illuminating the discussion." > > > > A few parts of the introduction I think can be re-worded to express the > > issues professionally without getting people defensive by making the > > statements you are making. Rise above it. > > I'll re-check the text -- The Intro was going to be re-worked, anyway. > > [Rick] Sounds good. Thanks. > > > > In Section 2: > > > > Firewall - I am wondering if a better definition can be made. From what > > you wrote I cannot distinguish between a Firewall and an ACL. > > An ACL is a policy. A firewall is a device that enforces filtering > policies. > > [Rick] Your definition would encompass routers and switches who have ACL/Filters on interfaces/SVIs. I would not consider these firewalls. > > > No mention > > of state tracking for instance etc. > > Ok, will try to add somethin in this respect. > > [Rick] Please do, as Ca mentions this is how the vast majority of the world define it as. This even includes common compliance audits like PCI/SOC etc. > > > > Defense-in-depth - I think you should define this term in this section > > since you go on to use it in following sections. > > Will do. > > > > > Section 3.3: > > > > The sentence: > > > > "By that line of reasoning, a firewall primarily protects > > infrastructure, by preventing traffic that would attack it from it." > > > > I think flows better as: > > > > "By that line of reasoning, a firewall primarily protects > > infrastructure, by preventing traffic that would attack it." > > > > or > > > > "A firewall primarily protects against infrastructure attacks." > > This seond option my work. (Your first option changes the meaning of the > sentence). > > > > > Section 5.1: > > > > "The drawback of this approach is that the security goal of "block > > traffic unless it is explicitly allowed" prevents useful new > applications." > > > > I am not sure I understand this line. It blocks new applications from > > immediately traversing the firewall. I know from experience though that > > when a discussion is had with the NetSec team the application can be > > added to the allow list. So not sure a "default deny" means new stuff > > never gets allowed as the text insinuates. > > Well, that depends on where the firewall is being deployed, and if it is > actively managed. > > [Rick] I am unaware of any firewall deployed that is no longer managed. The only cases I can think of is if the company has fired all engineers after initial deployment. This would make it a business problem, not a technical one since appropriate staffing is a business item. Placement of the firewall is moot since if staffing is done correctly the scenario I describe above should happen. If not staffed properly the business has issues not related to creating new applications. In other words it is not really the firewalls fault but the business for not having anyone to maintain a piece of gear they deployed. > > > > Section 6: > > > > There are temporary IPv4 addresses too. > > Not by definition I'd say. Or... would you mind elaborating a bit more > in this respect? > > [Rick] My apologies on this one got some wires crossed. This is good to go. > > > > As for application being tunneled over well-known ports that sounds like > > a breakdown of communication between the Service Owners and NetSec. > > Simple communication *should* lead to the creation of a profile for that > > new application and its individual port. By doing what you describe it > > sounds like a Service Owner trying to get out of doing due diligence > > with NetSec or not knowing what port their application needs for access > > (More common than you might think). > > Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls. > -- Ironically, at times these protocols are referred to as "firewall > friendly". > [Rick] The scenario makes no sense other than a mismanaged company frankly. You are essentially encouraging something against BCP. Even beyond security you will make it difficult to troubleshoot if everything is using the same port to traverse the firewall. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a11c38e0ee60cfd05226044ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just trying to help. Answers in line.

-------------------<= br>Cheers, Rick

Experiences not things.

On Fri, Oct 16, 2015 at 3:53 PM, Fernando Go= nt <fgont@si6networks.com> wrote:
Hi, Rick,

Thanks so much for your feedback! Please find my responses in-line...

On 10/16/2015 09:19 AM, Rick Casarez wrote:
> While I get amused reading such things are we sure we need lines like<= br> > this in the document?
>
> "...and attempts to end the bickering on the topic, which is, for= the
> most part, of little value in illuminating the discussion."
>
> A few parts of the introduction I think can be re-worded to express th= e
> issues professionally without getting people defensive by making the > statements you are making. Rise above it.

I'll re-check the text -- The Intro was going to be re-worked, anyway.<= br>
[Rick] Sounds good. Thanks.


> In Section 2:
>
> Firewall - I am wondering if a better definition can be made. From wha= t
> you wrote I cannot distinguish between a Firewall and an ACL.

An ACL is a policy. A firewall is a device that enforces filtering policies= .

[Rick] Your definition would encompass routers and sw= itches who have ACL/Filters on interfaces/SVIs. I would not consider these = firewalls.

> No mention
> of state tracking for instance etc.

Ok, will try to add somethin in this respect.

[Rick] Please do, as Ca mentions this is how the vast= majority of the world define it as. This even includes common compliance a= udits like PCI/SOC etc.


> Defense-in-depth - I think you should define this term in this section=
> since you go on to use it in following sections.

Will do.



> Section 3.3:
>
> The sentence:
>
> "By that line of reasoning, a firewall primarily protects
> infrastructure, by preventing traffic that would attack it from it.&qu= ot;
>
> I think flows better as:
>
> "By that line of reasoning, a firewall primarily protects
> infrastructure, by preventing traffic that would attack it."
>
> or
>
> "A firewall primarily protects against infrastructure attacks.&qu= ot;

This seond option my work. (Your first option changes the meaning of the sentence).



> Section 5.1:
>
> "The drawback of this approach is that the security goal of "= ;block
> traffic unless it is explicitly allowed" prevents useful new appl= ications."
>
> I am not sure I understand this line. It blocks new applications from<= br> > immediately traversing the firewall. I know from experience though tha= t
> when a discussion is had with the NetSec team the application can be > added to the allow list. So not sure a "default deny" means = new stuff
> never gets allowed as the text insinuates.

Well, that depends on where the firewall is being deployed, and if it is actively managed.

[Rick] I am unaware of any firewall deployed that is = no longer managed. The only cases I can think of is if the company has fire= d all engineers after initial deployment. This would make it a business pro= blem, not a technical one since appropriate staffing is a business item.
Placement of the firewall is moot since if staffing is done= correctly the scenario I describe above should happen. If not staffed prop= erly the business has issues not related to creating new applications. In o= ther words it is not really the firewalls fault but the business for not ha= ving anyone to maintain a piece of gear they deployed.=C2=A0


> Section 6:
>
> There are temporary IPv4 addresses too.

Not by definition I'd say. Or... would you mind elaborating a bit more<= br> in this respect?

=C2=A0[Rick] My apologies on this one got some wires = crossed. This is good to go.


> As for application being tunneled over well-known ports that sounds li= ke
> a breakdown of communication between the Service Owners and NetSec. > Simple communication *should* lead to the creation of a profile for th= at
> new application and its individual port. By doing what you describe it=
> sounds like a Service Owner trying to get out of doing due diligence > with NetSec or not knowing what port their application needs for acces= s
> (More common than you might think).

Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls.
-- Ironically, at times these protocols are referred to as "firewall friendly".
=C2=A0
=C2=A0[Rick] The scen= ario makes no sense other than a mismanaged company frankly. You are essent= ially encouraging something against BCP. Even beyond security you will make= it difficult to troubleshoot if everything is using the same port to trave= rse the firewall.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a11c38e0ee60cfd05226044ae-- From nobody Sun Oct 18 15:58:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4B1B29C9; Sun, 18 Oct 2015 15:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_wq6mJ4fhOs; Sun, 18 Oct 2015 15:58:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D9D1B29BA; Sun, 18 Oct 2015 15:58:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 9CF4E1FCAB7; Sun, 18 Oct 2015 22:58:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3B95F16003C; Sun, 18 Oct 2015 22:58:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC831160086; Sun, 18 Oct 2015 22:58:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gPnxRCjBhg93; Sun, 18 Oct 2015 22:58:14 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id DCE2816003C; Sun, 18 Oct 2015 22:58:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A33903AB089A; Mon, 19 Oct 2015 09:58:06 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> In-reply-to: Your message of "Sun, 18 Oct 2015 11:11:50 +1300." <5622C7A6.6000200@gmail.com> Date: Mon, 19 Oct 2015 09:58:06 +1100 Message-Id: <20151018225806.A33903AB089A@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org, 6man@ietf.org, John Leslie Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 22:58:17 -0000 In message <5622C7A6.6000200@gmail.com>, Brian E Carpenter writes: > I think that > (a) This draft should not be Informational, it should become a BCP. > (b) I suspect it belongs in v6ops rather than 6man, since it doesn't > change anything in the standards. Isn't this similar to RFC6691 which was only informational? That said I don't care which w.g. processes this so long as it gets processed. Similarly w.r.t. to the category. Lets let the chairs decide which w.g. For v6ops this is https://datatracker.ietf.org/doc/draft-andrews-tcp-and-ipv6-use-minmtu/ Mark > (c) I think it doesn't say quite enough about how this is a very serious > and recurrent operational problem which causes real damage to IPv6 deployment > . > > Also - it's not OK that POSIX hasn't yet picked up the advanced socket API > and that it isn't available in all programming languages with socket calls. > We, for some value of "we", need to campaign to get this fixed. > > Brian > > > On 17/10/2015 11:56, Mark Andrews wrote: > > In message <56217BAB.2040608@gmail.com>, Brian E Carpenter writes: > >> On 17/10/2015 09:31, Mark Andrews wrote: > >>> > >>> In message <20151016202620.GI1442@verdi>, John Leslie writes: > >>>> Mark Andrews wrote: > >>>>> > >>>>> Please see > >>>>> https://www.ietf.org/id/draft-andrews-tcp-and-ipv6-use-minmtu-00.txt > >>>>> > >>>>> It addresses what should be obviously done but isn't by many > >>>>> implementations. > >>>> > >>>> Alas, this draft gives no clue _how_ to check IPV6_USE_MINMTU ... > >>>> (or, for that matter, how to set it). > >>>> > >>>> One could reasonably guess that s/he should look through RFC3542 to > >>>> find how to check this; but RFC3542 contains no such string. (It does > >>>> contain the string IPV6_USE_MIN_MTU; but I don't feel justified in > >>>> guessing that far astream... > >> > >> Incidentally, it recently came to my attention that standard Python > >> doesn't support RFC3542. I don't know how widespread that issue is, but > >> it may be behind some of these broken MSS deployments. > >> > >> Brian > > > > The entire advanced socket API is poorly supported because POSIX > > didn't pick it up. > > > > That said I've updated the document based on the feedback received > > to date. > > > > https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-03 > > > >>> Yes, I typo'd that, repeatedly. > >>> > >>>> Perhaps adding a citation to the specific section of a particular > >>>> RFC would help? > >>>> > >>>> -- > >>>> John Leslie -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Oct 18 16:17:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96801B29E9; Sun, 18 Oct 2015 16:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkVrUxoCp6tU; Sun, 18 Oct 2015 16:17:39 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CB01A00F0; Sun, 18 Oct 2015 16:17:39 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so74790322pac.3; Sun, 18 Oct 2015 16:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O5lOpavDoEY3DPfA8BK3W+jEJeICDZ/OkDpIwQFOz30=; b=MP5YNzmkGuP53C8gpmlewxXOLcKzCbg8dkABOUT7SH2mj15d4xYvkBXh9NpddwA/Is lfYGXkDF5Wu7BCsX+UIrn13WENApAtCbCy3upmTfekjpMsKWms26gBVhrLO7xKkjazex u650iO2U7musUaFSGkQaja79D4ioORq8ElxbF00job0SuWTIz8GRMqCEMCUMZRvYpHiS f68bdq895RUQtmc1rhiVmLrpGzZBCFdQLsc7nRRezeenKBVkTx4ZacdKnRNLy05H2Rok xYfxOlvFDnmOkC/GTIsIkbAwYm+E/DiIM+BsEN+d2acYNel7T5inbaFLSbGEFUiU/4lA mZqQ== X-Received: by 10.68.164.98 with SMTP id yp2mr30493587pbb.125.1445210258592; Sun, 18 Oct 2015 16:17:38 -0700 (PDT) Received: from [192.168.178.25] (221.231.69.111.dynamic.snap.net.nz. [111.69.231.221]) by smtp.gmail.com with ESMTPSA id zi1sm13670706pbc.10.2015.10.18.16.17.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 16:17:37 -0700 (PDT) To: Mark Andrews References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5624288D.9040400@gmail.com> Date: Mon, 19 Oct 2015 12:17:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151018225806.A33903AB089A@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, 6man@ietf.org, John Leslie Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 23:17:43 -0000 On 19/10/2015 11:58, Mark Andrews wrote: > In message <5622C7A6.6000200@gmail.com>, Brian E Carpenter writes: >> I think that >> (a) This draft should not be Informational, it should become a BCP. >> (b) I suspect it belongs in v6ops rather than 6man, since it doesn't >> change anything in the standards. > > Isn't this similar to RFC6691 which was only informational? IMHO that's an error and 6691 should be standards track, but I wasn't involved in that discussion so there may be a reason. > That said I don't care which w.g. processes this so long as it gets > processed. Similarly w.r.t. to the category. Lets let the chairs > decide which w.g. Sure. I would argue for BCP because it really is an operational requirement to get this fixed in all implementations. Brian > > For v6ops this is > https://datatracker.ietf.org/doc/draft-andrews-tcp-and-ipv6-use-minmtu/ > > Mark > >> (c) I think it doesn't say quite enough about how this is a very serious >> and recurrent operational problem which causes real damage to IPv6 deployment >> . >> >> Also - it's not OK that POSIX hasn't yet picked up the advanced socket API >> and that it isn't available in all programming languages with socket calls. >> We, for some value of "we", need to campaign to get this fixed. >> >> Brian >> >> >> On 17/10/2015 11:56, Mark Andrews wrote: >>> In message <56217BAB.2040608@gmail.com>, Brian E Carpenter writes: >>>> On 17/10/2015 09:31, Mark Andrews wrote: >>>>> >>>>> In message <20151016202620.GI1442@verdi>, John Leslie writes: >>>>>> Mark Andrews wrote: >>>>>>> >>>>>>> Please see >>>>>>> https://www.ietf.org/id/draft-andrews-tcp-and-ipv6-use-minmtu-00.txt >>>>>>> >>>>>>> It addresses what should be obviously done but isn't by many >>>>>>> implementations. >>>>>> >>>>>> Alas, this draft gives no clue _how_ to check IPV6_USE_MINMTU ... >>>>>> (or, for that matter, how to set it). >>>>>> >>>>>> One could reasonably guess that s/he should look through RFC3542 to >>>>>> find how to check this; but RFC3542 contains no such string. (It does >>>>>> contain the string IPV6_USE_MIN_MTU; but I don't feel justified in >>>>>> guessing that far astream... >>>> >>>> Incidentally, it recently came to my attention that standard Python >>>> doesn't support RFC3542. I don't know how widespread that issue is, but >>>> it may be behind some of these broken MSS deployments. >>>> >>>> Brian >>> >>> The entire advanced socket API is poorly supported because POSIX >>> didn't pick it up. >>> >>> That said I've updated the document based on the feedback received >>> to date. >>> >>> https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-03 >>> >>>>> Yes, I typo'd that, repeatedly. >>>>> >>>>>> Perhaps adding a citation to the specific section of a particular >>>>>> RFC would help? >>>>>> >>>>>> -- >>>>>> John Leslie From nobody Sun Oct 18 16:18:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDCE1B29F4; Sun, 18 Oct 2015 16:18:34 -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=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta0lQuh3E0Sg; Sun, 18 Oct 2015 16:18:33 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E2E1B29EA; Sun, 18 Oct 2015 16:18:32 -0700 (PDT) Received: by vkex70 with SMTP id x70so88007430vke.3; Sun, 18 Oct 2015 16:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h2hd3cQeoVYItdUGP8cgTId9HgQVsJp1QNNIZ+OP7ko=; b=zifdAF21LaGKIQhDKLRnX/cTvcT0wfANE50EfXyvoKHMT+yBEnDH3qUaWABvC77bwI y2ADhxiXr/caKCtoSIuOy7dKp7PMkuqWXF4QBRaVLyZphVw35OPRmsCFI85AlccmyxD+ Q4cYG1lEM1T5yWGadcDYGCbls84fKzjV7stm83ZEHzOzg6Mef10RukjWdK+zynN3EjLC nxNDrm1UPNvF3X8e1nLXxx/SEqetesRuWtHqf2nJ+FtYtkGaiRn7HECcgb9UN08L5S77 go3pCGC9BX4KIp+8BuWp4jLRJezhD9hNTQq5T84QNMEQJVoVsLc94G9iotrewuwA8oa0 0cCw== MIME-Version: 1.0 X-Received: by 10.31.60.145 with SMTP id j139mr17924024vka.89.1445210311856; Sun, 18 Oct 2015 16:18:31 -0700 (PDT) Received: by 10.103.98.132 with HTTP; Sun, 18 Oct 2015 16:18:31 -0700 (PDT) Received: by 10.103.98.132 with HTTP; Sun, 18 Oct 2015 16:18:31 -0700 (PDT) In-Reply-To: <20151018225806.A33903AB089A@rock.dv.isc.org> References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> Date: Mon, 19 Oct 2015 10:18:31 +1100 Message-ID: From: Mark Smith To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1143a3f04399b50522693f9e Archived-At: Cc: v6ops@ietf.org, 6man@ietf.org, John Leslie Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 23:18:34 -0000 --001a1143a3f04399b50522693f9e Content-Type: text/plain; charset=UTF-8 On 19 Oct 2015 09:58, "Mark Andrews" wrote: > > > In message <5622C7A6.6000200@gmail.com>, Brian E Carpenter writes: > > I think that > > (a) This draft should not be Informational, it should become a BCP. > > (b) I suspect it belongs in v6ops rather than 6man, since it doesn't > > change anything in the standards. > > Isn't this similar to RFC6691 which was only informational? > I think Bob is saying this is an important enough issue that it should be given BCP status. > That said I don't care which w.g. processes this so long as it gets > processed. Similarly w.r.t. to the category. Lets let the chairs > decide which w.g. > > For v6ops this is > https :// datatracker.ietf.org /doc/ draft-andrews-tcp-and-ipv6-use-minmtu / > > Mark > > > (c) I think it doesn't say quite enough about how this is a very serious > > and recurrent operational problem which causes real damage to IPv6 deployment > > . > > > > Also - it's not OK that POSIX hasn't yet picked up the advanced socket API > > and that it isn't available in all programming languages with socket calls. > > We, for some value of "we", need to campaign to get this fixed. > > > > Brian > > > > > > On 17/10/2015 11:56, Mark Andrews wrote: > > > In message <56217BAB.2040608@gmail.com>, Brian E Carpenter writes: > > >> On 17/10/2015 09:31, Mark Andrews wrote: > > >>> > > >>> In message <20151016202620.GI1442@verdi>, John Leslie writes: > > >>>> Mark Andrews wrote: > > >>>>> > > >>>>> Please see > > >>>>> https :// www.ietf.org /id/ draft-andrews-tcp -and-ipv6-use-minmtu-00.txt > > >>>>> > > >>>>> It addresses what should be obviously done but isn't by many > > >>>>> implementations. > > >>>> > > >>>> Alas, this draft gives no clue _how_ to check IPV6_USE_MINMTU ... > > >>>> (or, for that matter, how to set it). > > >>>> > > >>>> One could reasonably guess that s/he should look through RFC3542 to > > >>>> find how to check this; but RFC3542 contains no such string. (It does > > >>>> contain the string IPV6_USE_MIN_MTU; but I don't feel justified in > > >>>> guessing that far astream... > > >> > > >> Incidentally, it recently came to my attention that standard Python > > >> doesn't support RFC3542. I don't know how widespread that issue is, but > > >> it may be behind some of these broken MSS deployments. > > >> > > >> Brian > > > > > > The entire advanced socket API is poorly supported because POSIX > > > didn't pick it up. > > > > > > That said I've updated the document based on the feedback received > > > to date. > > > > > > https :// tools.ietf.org / html / draft-andrews-tcp-and-ipv6-use-minmtu-03 > > > > > >>> Yes, I typo'd that, repeatedly. > > >>> > > >>>> Perhaps adding a citation to the specific section of a particular > > >>>> RFC would help? > > >>>> > > >>>> -- > > >>>> John Leslie > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@ isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https :// www.ietf.org /mailman/ listinfo / v6ops --001a1143a3f04399b50522693f9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 19 Oct 2015 09:58, "Mark Andrews" <marka@isc.org> wrote:
>
>
> In message <5622C7A6.= 6000200@gmail.com>, Brian E Carpenter writes:
> > I think that
> > (a) This draft should not be Informational, it should become a BC= P.
> > (b) I suspect it belongs in v6ops rather than 6man, since it does= n't
> > change anything in the standards.
>
> Isn't this similar to RFC6691 which was only informational?
>

I think Bob is saying this is an important enough issue that= it should be given BCP status.

> That said I don't care which w.g. processes this so= long as it gets
> processed.=C2=A0 Similarly w.r.t. to the category.=C2=A0 Lets let the = chairs
> decide which w.g.
>
> For v6ops this is
> https://datatracker.ie= tf.org/doc/draft-andrews-tcp-and-ipv6-use-minmtu<= /a>/
>
> Mark
>
> > (c) I think it doesn't say quite enough about how this is a v= ery serious
> > and recurrent operational problem which causes real damage to IPv= 6 deployment
> > .
> >
> > Also - it's not OK that POSIX hasn't yet picked up the ad= vanced socket API
> > and that it isn't available in all programming languages with= socket calls.
> > We, for some value of "we", need to campaign to get thi= s fixed.
> >
> >=C2=A0 =C2=A0 =C2=A0Brian
> >
> >
> > On 17/10/2015 11:56, Mark Andrews wrote:
> > > In message <56217BAB.2040608@gmail.com>, Brian E Carpenter writes:
> > >> On 17/10/2015 09:31, Mark Andrews wrote:
> > >>>
> > >>> In message <20151016202620.GI1442@verdi>, John= Leslie writes:
> > >>>> Mark Andrews <marka@isc.org> wrote:
> > >>>>>
> > >>>>> Please see
> > >>>>> https://= www.ietf.org/id/draft-andrews-tcp-and-ipv6-us= e-minmtu-00.txt
> > >>>>>
> > >>>>> It addresses what should be obviously done b= ut isn't by many
> > >>>>> implementations.
> > >>>>
> > >>>>=C2=A0 =C2=A0 Alas, this draft gives no clue _how= _ to check IPV6_USE_MINMTU ...
> > >>>> (or, for that matter, how to set it).
> > >>>>
> > >>>>=C2=A0 =C2=A0 One could reasonably guess that s/h= e should look through RFC3542 to
> > >>>> find how to check this; but RFC3542 contains no = such string. (It does
> > >>>> contain the string IPV6_USE_MIN_MTU; but I don&#= 39;t feel justified in
> > >>>> guessing that far astream...
> > >>
> > >> Incidentally, it recently came to my attention that stan= dard Python
> > >> doesn't support RFC3542. I don't know how widesp= read that issue is, but
> > >> it may be behind some of these broken MSS deployments. > > >>
> > >>=C2=A0 =C2=A0 =C2=A0Brian
> > >
> > > The entire advanced socket API is poorly supported because P= OSIX
> > > didn't pick it up.
> > >
> > > That said I've updated the document based on the feedbac= k received
> > > to date.
> > >
> > > https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-= minmtu-03
> > >
> > >>> Yes, I typo'd that, repeatedly.
> > >>>
> > >>>>=C2=A0 =C2=A0 Perhaps adding a citation to the sp= ecific section of a particular
> > >>>> RFC would help?
> > >>>>
> > >>>> --
> > >>>> John Leslie <= john@jlc.net>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INTERNET: marka@isc.o= rg
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops<= /a>

--001a1143a3f04399b50522693f9e-- From nobody Sun Oct 18 18:34:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C1D1B2B2E; Sun, 18 Oct 2015 18:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZyoKT-npGVp; Sun, 18 Oct 2015 18:34:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C911B2B45; Sun, 18 Oct 2015 18:34:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019013404.6554.80883.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 18:34:04 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 01:34:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-05.txt Pages : 9 Date : 2015-10-18 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 18:40:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E071B2B76; Sun, 18 Oct 2015 18:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-srsA2HGSbk; Sun, 18 Oct 2015 18:40:28 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A1E1B2B73; Sun, 18 Oct 2015 18:40:28 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so77739081pac.3; Sun, 18 Oct 2015 18:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3Ud3weCuTSxLBXUedKezt9X8KfWbV1HrDtZZjoe9Hhs=; b=enzi9lpMaY2ydosUTmWnzkaCBaZnTqIO2n7aN54c5Ui7ieWFPvlmlsuCDEWFn/65bS kJAXX449wShmbZHuSvFOwmgBjpr+mt2dHbrK6CIm6h8bKI4+cjObleOQaNb/Eo8DQW+E Gw5vdMK9ECO2bSdrVe17nM+z2LsTDSw6Qxc+a9eu7clEtXFBNM4xRI9oppRwgTe9HyLE DKTt1RDbiQdeoOrNOSsXqQZ1DbWyLJZgPcRVTjC5528TapgVjFGsGSfcNQ2tPs3egpXK OpT40/bSiOf2TP9XP7GEOYJAv3t1sMKWS8lmdheEGaf55VOhpHG7u0UPUbXOVRZoMMkv ZNPw== X-Received: by 10.66.66.196 with SMTP id h4mr30108336pat.77.1445218828034; Sun, 18 Oct 2015 18:40:28 -0700 (PDT) Received: from [192.168.178.25] (221.231.69.111.dynamic.snap.net.nz. [111.69.231.221]) by smtp.gmail.com with ESMTPSA id eg5sm33316711pac.30.2015.10.18.18.40.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 18:40:26 -0700 (PDT) To: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org References: <20151015123705.4548.5970.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56244A06.5040603@gmail.com> Date: Mon, 19 Oct 2015 14:40:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151015123705.4548.5970.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 01:40:29 -0000 Hi, > 2. Previous Work on IPv6 Extension Headers ... > ... [RFC7045] clarifies how intermediate > nodes should deal with IPv6 extension headers. More than that, it means that they can find the end of the header chain, which is the critical issue for this draft. Middleboxes that implement 7045 can find the end of any header chain conforming to headers standardised up to the date of implementation. > 4.1.1. Enforcing infrastructure ACLs I think you should list ICMP PTB and fragment headers as likely permitted traffic here. (Yes, I know you discuss PTB as an attack vector later, but in general it needs to be permitted everywhere.) > 4.1.3. ECMP and Hash-based Load-Sharing You could note that the flow label is a specific mitigation for this aspect (RFC 6437, 6438). > 4.2. Route-Processor Protection ... > The Hop-by-Hop Options header is particularly challenging since, in > most (if not all) implementations, it causes the corresponding packet > to be punted to a software path. As a result, operators usually drop > IPv6 packets containing this extension header. You definitely need a reference to draft-baker-6man-hbh-header-handling here. Regards Brian From nobody Sun Oct 18 18:42:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943B51A0334; Sun, 18 Oct 2015 18:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ridc05s86QLz; Sun, 18 Oct 2015 18:42:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1691B2BA5; Sun, 18 Oct 2015 18:42:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019014239.14893.86380.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 18:42:39 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 01:42:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-06.txt Pages : 9 Date : 2015-10-18 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 18:49:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FF41A0AFE; Sun, 18 Oct 2015 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK1JasKEr4ul; Sun, 18 Oct 2015 18:49:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C544F1B2BCF; Sun, 18 Oct 2015 18:49:14 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4204:51:750a:9ddd:9af7:53ff]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9J1n7kR055206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 19 Oct 2015 01:49:08 GMT (envelope-from joelja@bogus.com) To: Tim Chown , Spencer Dawkins at IETF References: <20151013165903.19562.54680.idtracker@ietfa.amsl.com> <561F5A20.7040209@cisco.com> <2F7D0142-5BE8-4FD4-A012-2AC0497B6D1A@ecs.soton.ac.uk> From: joel jaeggli Message-ID: <56244C12.2010201@bogus.com> Date: Sun, 18 Oct 2015 18:49:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eetgB79LGJdX1knhkSOOHC1H48OR8ukvl" Archived-At: Cc: v6ops list , The IESG , draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 01:49:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eetgB79LGJdX1knhkSOOHC1H48OR8ukvl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/15/15 1:06 PM, Tim Chown wrote: >> I agree with your observation. I would think that in order for >> something to be ideal, it should be possible (ideally we should be >> able to send packets at greater than the speed of light, but we can't,= >> so. Ideally we should be able to send the PTB only to the place it >> needs to go, but we can't, so).=20 >=20 > None of the mitigations are =91ideal=92. >=20 > But the document is useful for noting the problem,describing it well, > and discussing wha *could* be done. I tweaked it to remove ideal... https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-pmtud-ecmp-problem-0= 4&url2=3Ddraft-ietf-v6ops-pmtud-ecmp-problem-06 > Tim >=20 >> >> But I'm a TSV guy who is poking at this because of RFC 7258, so if the= >> SEC folk don't care, I'm fine. >> >> Spencer >> =20 >> >> Regards, Benoit >> >> >> Could that one word go away? >> >> I see in email that Fred asked if any reviews were needed befo= re >> submitting this draft for publication, and David Black >> suggested reviews >> from INT and TSV, and that made it as far as the shepherd >> writeup, but >> I'm not seeing a request for review popping up in TSV (at >> least not with >> "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about= >> this >> particular draft, but I wish it hadn't slipped through that >> particular >> crack. >> >> Yes, Fred copied TSVWG and TSVAREA on his note asking for >> guidance, and >> yes, there was an IETF Last Call, so I'm not hitting "Defer" >> to chase >> that. Just something to watch for, in the future. >> >> And yes, Martin and I have a call set up to talk with the >> TSVdir triage >> team next week ... >> >> >> . >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --eetgB79LGJdX1knhkSOOHC1H48OR8ukvl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYkTBMACgkQ8AA1q7Z/VrJn0wCfUddFWt/CQfTUAIAHcSVCwmGQ qCUAnjec3ZmP+BfcJoMp5y3TuO5Q+MR4 =BYwp -----END PGP SIGNATURE----- --eetgB79LGJdX1knhkSOOHC1H48OR8ukvl-- From nobody Sun Oct 18 19:00:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE861A000B; Sun, 18 Oct 2015 19:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj-gNqd_bnk7; Sun, 18 Oct 2015 19:00:43 -0700 (PDT) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC051A0006; Sun, 18 Oct 2015 19:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=tsahara@iij.ad.jp;s=omgo2;t=1445220041;x= 1446429641; bh=4f1swuRZXJeHgM47eYLuSDdsE5qD9wsH7fB1XZVjhq0=; b=T0gfFykQrirvGRMf WMVvL+m6+uWx2BrwgLMaBJZ2FJXb71F+bow394kPQjuTu/PE0D71pi6IaFkMQEjXerdhFsrdcn9wH aBiEXupGGBKdem+HscQAzFdeGOVqX7zCSQpE0dcqMC/nMPHQVU05HdK0UdtUeYFY/Z16gaq8rlQ+R EN3ByDHxCpan2TYDvOmMbDm5SlMjeFuF3gV4OJ9sfrd8h871A2Ovcul/qVuANDgLxau4/qANXBVdR JuLy8FCtavN5VT8laTvus2kMXGHa7h8/FQcvNdsISot4n6QFSwIovrFfI16FGVJMDaVvLqUIFoFre d6i28CnTXIn1L5Il9w==; Received: by omgo.iij.ad.jp (mo00) id t9J20f6f004418; Mon, 19 Oct 2015 11:00:41 +0900 Received: from unknown [10.131.17.50] (EHLO mix901.iiji.jp) by of-mxl-mas900.iiji.jp(mxl_mta-7.2.4-6) with ESMTP id 3ce44265.0.45256.00-447.90033.of-mxl-mas900.iiji.jp (envelope-from ); Mon, 19 Oct 2015 11:00:35 +0900 (JST) X-MXL-Hash: 56244ec37c5bf9cf-119d04cdcb06409833c48ad21621381ad15c5e53 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Tomoyuki Sahara In-Reply-To: Date: Mon, 19 Oct 2015 11:00:35 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <655154DA-E515-4FDE-AAA2-975D4575B70B@iij.ad.jp> References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> To: 6man@ietf.org X-Mailer: Apple Mail (2.3094) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 02:00:44 -0000 > > > I think that > > > (a) This draft should not be Informational, it should become a = BCP. > > > (b) I suspect it belongs in v6ops rather than 6man, since it = doesn't > > > change anything in the standards. > > > > Isn't this similar to RFC6691 which was only informational? > > >=20 > I think Bob is saying this is an important enough issue that it should = be given BCP status. I agree that this is an important issue, but what practice can we recommend? As is written in the draft, current TCP implementations ignore IPv6_USE_MIN_MTU when they send TCP SYNs with MSS options (I have tested and confirmed it on FreeBSD 10, NetBSD 6.1 and OpenBSD 5.7). Linux distributions (CentOS/Ubuntu) don't support IPv6_USE_MIN_MTU at all, even on raw IPv6 sockets. Thanks, Tomoyuki From nobody Sun Oct 18 19:55:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3395E1A0108; Sun, 18 Oct 2015 19:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLWfvWWTAz5A; Sun, 18 Oct 2015 19:55:55 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8781A00FD; Sun, 18 Oct 2015 19:55:55 -0700 (PDT) Received: by padhk11 with SMTP id hk11so14733701pad.1; Sun, 18 Oct 2015 19:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ULNbGjokookdLNJL/drfp4/xBDagYmhvrubEd9mvNCM=; b=ZETKLG6wvaJ1iwT+yNsWKPklJWLBzSrpEAWTEY/jVKJ8S0MbAyth30n3hlbMy0MNn2 ubP6RXUx5k/V9aDwOj77sQ8R88wvsbYdWa3kihM89jBFZyeof0hTzvclxumlMnQnMu7y ZatIIN8NRZ4VAk7DqnxbcY5g/G3V8H5yCqsRAoHAUoQJAhqKDQcCsXGJfm7Eiv0Zatm1 XWzghuVdv/BKbCJQk4afqkgj5w1Ct1bUF0nb+D88pxWvLzvF721jbEA1ssTbRTHWYiJh 5eqtDU7T95Jo13yfQlv7X24BTeI4KOZVp1Qjt3QPxtNG7yBlXKPm6Gzt4bQnKmb0f8fs pltQ== X-Received: by 10.68.212.101 with SMTP id nj5mr7426272pbc.32.1445223354891; Sun, 18 Oct 2015 19:55:54 -0700 (PDT) Received: from [192.168.178.25] (221.231.69.111.dynamic.snap.net.nz. [111.69.231.221]) by smtp.gmail.com with ESMTPSA id jt1sm23269730pbc.83.2015.10.18.19.55.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 19:55:53 -0700 (PDT) To: Tomoyuki Sahara , 6man@ietf.org References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> <655154DA-E515-4FDE-AAA2-975D4575B70B@iij.ad.jp> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56245BB6.8000200@gmail.com> Date: Mon, 19 Oct 2015 15:55:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <655154DA-E515-4FDE-AAA2-975D4575B70B@iij.ad.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 02:55:56 -0000 On 19/10/2015 15:00, Tomoyuki Sahara wrote: >>>> I think that >>>> (a) This draft should not be Informational, it should become a BCP. >>>> (b) I suspect it belongs in v6ops rather than 6man, since it doesn't >>>> change anything in the standards. >>> >>> Isn't this similar to RFC6691 which was only informational? >>> >> >> I think Bob is saying this is an important enough issue that it should be given BCP status. > > I agree that this is an important issue, but what practice can we > recommend? > > As is written in the draft, current TCP implementations ignore > IPv6_USE_MIN_MTU when they send TCP SYNs with MSS options (I have > tested and confirmed it on FreeBSD 10, NetBSD 6.1 and OpenBSD 5.7). > Linux distributions (CentOS/Ubuntu) don't support IPv6_USE_MIN_MTU > at all, even on raw IPv6 sockets. Well, the recommendation is to fix that, and the first step to fix that is for all stacks to support the Advanced Socket API. It is not unknown for the IETF to make implementation recommendations, and sometimes vendors follow them. Brian From nobody Sun Oct 18 23:13:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C931A1A68; Sun, 18 Oct 2015 23:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naxUXGY3j2YY; Sun, 18 Oct 2015 23:13:42 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A7B1A1A15; Sun, 18 Oct 2015 23:13:42 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=43440 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zo3hS-0002PJ-Vp; Mon, 19 Oct 2015 08:13:38 +0200 Date: Mon, 19 Oct 2015 08:13:38 +0200 From: Tore Anderson To: "Stephen Farrell" Message-ID: <20151019081338.20f33b8c@echo.ms.redpill-linpro.com> In-Reply-To: <20151015133232.9056.27955.idtracker@ietfa.amsl.com> References: <20151015133232.9056.27955.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-dc@ietf.org, v6ops-chairs@ietf.org, The IESG , fred.baker@cisco.com Subject: Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-siit-dc-03: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 06:13:43 -0000 * "Stephen Farrell" > Stephen Farrell has entered the following ballot position for > draft-ietf-v6ops-siit-dc-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I would have thought that the BR and ER would be new targets > for DoS attack, however, I'm not sure those are really > different in this respect compared to other existing routers > in a data centre - did the wg consider if there are any such > differences that are worth noting? (I thought about it for 2 > minutes, without finding any;-) Hello Stephen, The scalability characteristics of an BR/ER is indeed more similar to that of a traditional IP router. This is due to them operating in a completely stateless mode, handling one packet at a time, and forgetting everything about it immediately after. A stateless translator does not contain any flow tracking table, so the number of concurrent flows (and the flow initiation rate) is irrelevant. This is mentioned briefly in section 1.2. I hope that answers your comment. Tore From nobody Mon Oct 19 03:21:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069D91A88C1 for ; Mon, 19 Oct 2015 03:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYZg0hXMNIdG for ; Mon, 19 Oct 2015 03:21:53 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BAF1A88C0 for ; Mon, 19 Oct 2015 03:21:53 -0700 (PDT) Received: by vkgy127 with SMTP id y127so4520602vkg.0 for ; Mon, 19 Oct 2015 03:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ItDqNVElJ3G4ezJb72ywqQJo5HUfOkrI8DRUAQe3mB4=; b=lTnDkbAqGQbraMtfbh0H7VAFGlrbzYjKrTXOsLhDIv9ahnrsrIGI2fFCG8SHg/LW6T 78RTYXSULN4g5SOVrVudwm6mFPmR8eTbMCWaN+MTdP8MPD/NLp0o0I2UAxQj4kUy0IL1 FzvIYe+eo9OW9OfwFesiRadA1aLBhX8XcSbtnk0YIxmxYehxw7/Dj65XjpPnUF/W1Yfm O452zGSBs6LqpND6be5lPE5ZBSn7TUIlbFOCR5tcqXAONlw6FM/MqQP35oHAiVa23isq MZ54U1o8wNATfHXw+lNr+7kzAQmXH1tcMvZNJtKUODkwXfhuV1zx4LdyVnYpfHr3Oq3r OnrQ== X-Received: by 10.31.33.75 with SMTP id h72mr19230921vkh.144.1445250112630; Mon, 19 Oct 2015 03:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.98.132 with HTTP; Mon, 19 Oct 2015 03:21:23 -0700 (PDT) From: Mark Smith Date: Mon, 19 Oct 2015 21:21:23 +1100 Message-ID: To: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] ID: "How to use IPv6 Link-Local Addresses in Applications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 10:21:55 -0000 Hi, I've written up the following draft on how to use Link-Local addresses in applications for a few reasons: - I think there are robustness and security benefits to applications if LL addresses can be and are used. - A few years back I wrote a program that supported the use of unicast and multicast link-local addresses (https://github.com/markzzzsmith/replicast), using Steven's Unix Network Programming, Vol 1, 3rd edition. The topic of how to use link-local unicast/mutlicast addresses wasn't specifically covered. Although using them is pretty simple, it took a little bit of trial and error to work out which could be saved for somebody else. - The Multicast DNS implementation widely used under Linux doesn't announce IPv6 Link-Local addresses, contrary to the MUST in the MDNS RFC. The main author of it is pretty smart, so I suspect it is was because it wasn't obvious how to use LLs and how to deal with their ambiguity. So mostly this is trying to make it clear and obvious what the benefits and limitations are of Link-Local addresses in applications are, and how to use them. I'm posting it here for review in part because there are probably application developers here who can provide comments, and also because I wasn't able to find an Applications area working group that seemed suitable. If there is a more suitable WG I'll move it there after any comments from here. I do make one or two suggestions that are debatable. I'm interested in any comments, including suggestions for other content that should be covered. Co-authors with more LL programming experience than I have are welcome. Thanks, Mark. ---------- Forwarded message ---------- From: Date: 19 October 2015 at 21:04 Subject: New Version Notification for draft-smith-ipv6-link-locals-apps-00.txt To: "markzzzsmith+ietf-dt@gmail.com" A new version of I-D, draft-smith-ipv6-link-locals-apps-00.txt has been successfully submitted by Mark Smith and posted to the IETF repository. Name: draft-smith-ipv6-link-locals-apps Revision: 00 Title: How to use IPv6 Link-Local Addresses in Applications Document date: 2015-10-19 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-smith-ipv6-link-locals-apps-00.txt Status: https://datatracker.ietf.org/doc/draft-smith-ipv6-link-locals-apps/ Htmlized: https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 Abstract: IPv6 Link-Local addresses can be used by applications. Doing so when possible will provide robustness and security benefits to the application. This memo describes the properties of Link-Local addresses and the benefits and limitations of using them in applications. It then describes how to use them in applications that use the Sockets API. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 19 08:00:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7481A930A for ; Mon, 19 Oct 2015 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBLd6e4ozNHP for ; Mon, 19 Oct 2015 08:00:22 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414471A92F1 for ; Mon, 19 Oct 2015 08:00:22 -0700 (PDT) Received: by qkfm62 with SMTP id m62so83353866qkf.1 for ; Mon, 19 Oct 2015 08:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=rrqB7S73va3615yKfUepZ2vkLKWQ01v2sPukEerjRbU=; b=u+BSoUx6HBXKAupw3MsaFadJ1qz6dWS1xWX00NF8QPqmUUwzi/FrJlw+6RYmtv6ugB /5882sWawNKfPVA/tsEnM32F9jwxRxkTIDF0XW9/5fPOQyJbhuND1bxT5/+07TieGxfV eJId4ITM8hLz2BburibPws5p9JRVb59Tc+0zUKeZZnamcWJS+w6B4iCxDoXjWktOLRbe yDYsj/mrIl5E2z/W5+qiN5HunzHfhd7hGgU3sdQTCcMesyOZKn0gIasBWKKC+N4bKZTR 0vsO514sdler1j3ILr++DthhKmA8ANP3heqm8L/u/0cbYG+9W2K1QKsV1HWAvwxfAH5f qOTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=rrqB7S73va3615yKfUepZ2vkLKWQ01v2sPukEerjRbU=; b=VODPYkvgZ5/mNqXi1RaDygRbv2Nf9Uk8V48THCptfY6qaH+dJAuTeJLTPfpytxGHzG ysUCJG2JlFi3sGuXBmrFS8lL2lN6iIWBJ9YMfYJvm+V/XVNGIkn1EVxo+UGbMO4ALTMW /fWs+jDjN5TKSUJPORUSmGvwLYUVzQsnw/eHoUMe+HgawndxKJBljj9ENnBOP08TClqf hudSGbmpYw2ZQmgv4tn3l0tByj48vAl+Vw+frR9Up3KO20iXRw6CQxzqNKKUBxyhEcvW yJbOWmUKVuNmsiiRH9z/Q8YQ4CPsjD4GulTIcFJ4BXRR8GwpeLz0SgxOYyZbco0CXgSW aWdw== X-Gm-Message-State: ALoCoQn8XrROgpwq0E0uSrwKCcCaUCxwK13mq5HndlZk0hMr9RcCadP0dpgB8fab8c8xMmVxtBcb X-Received: by 10.55.198.212 with SMTP id s81mr36272369qkl.108.1445266820130; Mon, 19 Oct 2015 08:00:20 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local ([173.38.117.84]) by smtp.googlemail.com with ESMTPSA id r38sm14516946qkr.29.2015.10.19.08.00.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 08:00:19 -0700 (PDT) From: Victor Kuarsingh To: v6ops@ietf.org Message-ID: <56250584.8080309@jvknet.com> Date: Mon, 19 Oct 2015 11:00:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - Enterprise and Service Provider Applicability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:00:25 -0000 V6ops, We apologize for the delay from IETF93/Prague on getting discussions out for key topics on the draft-ietf-v6ops-design-choices document. We are sending out three separate emails to keep the discussion trains split for the three topics. The first discussion is applicability for Service Provider (SP) and Enterprise. The original work was focused on SP environments, but the scope was expanded in early 2015 to address input from operators who found that addressing Enterprise use cases was important. Since that group - Large Enterprise - is seen a significant part of the readership, and that group would benefit form this type of document, it was considered sound to include Enterprise network environments. Following the addition of Enterprise (and such items as EIGRP as an IGP to consider), there was additional conversation at IETF93/Prague to break-out the Enterprise conversation into a separate document. The current posture of the document (and text which will be seen in version -09 of draft) is to consider both SP and (Large) Enterprise. The design choices are in many regards common to these types of environments. We understand there are differences once you dig into details within each general use case, but the document is designed to provide the general options set and allow a smart/well versed designer to then apply the guidance to their network. If the group feels strongly that this approach is no longer valid (include Enterprise), that input would be appreciated. regards, Victor K From nobody Mon Oct 19 08:01:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB71ABD38 for ; Mon, 19 Oct 2015 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxNj39rKvNSg for ; Mon, 19 Oct 2015 08:01:25 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD851ABD3B for ; Mon, 19 Oct 2015 08:01:25 -0700 (PDT) Received: by qgem9 with SMTP id m9so10814268qge.1 for ; Mon, 19 Oct 2015 08:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=sFISCIzWVFsd6SvHNCyvVNYlizLfdgn+puitTrH1IVw=; b=SPLLWps3mwBFoHfZSiYwtOAe7J1lMg3AbVgcl2yjSl64bWzo/vFOAwBk+lumbhGll/ WFwCv3UHQw5o3tCwivZUchMpcLR07QYgOc8MIz4nUXelVWObyGah5JK+GUa5BlaVQgp8 sMt0K4nySmVyvLe+TZjsur1hTeQrpmDE8yPFx7MY1zo4i9/XglKP1Rt4oOznYe+09aWI N+TN+kryIlhJyJ+tgF/ZQTE6il8pYsKi8vcJn+0ksrXrlezYrT5b48nE9NdoUttKjTnr 9Vxm/m+9jl7E06NqrStOx7Ju/sNQ9zm/cxLZtOzdUk5JwRBABvQn4s4OnaHP3ZvP2cOl vzmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=sFISCIzWVFsd6SvHNCyvVNYlizLfdgn+puitTrH1IVw=; b=Wei+wACRoRl2IIx8/IZ9LNEY5Ny9ftUqawehkV8UzZgGMXZnYfT34fHxicp9miu6dJ 8owP1dOHCw7HBQDaBtkqRBV+2GXMUDG0zSMgAzZ3/wigEshDKaxAKGL4BGHC3u7otnKH YQi1Ms4BInUwCNP76/84Ue2XnAU1bsbXhamqxz41n9099Cjzwov0nSRIbgQvyE61Rjy5 TdRpnqeLi0jJrnKn1DaygOt00EkXgLug1wODfUl2l/JWH0A2VzQ5fdmnobtgmrzl00UQ Ru1vVt6H3Yqk+YVBolJCTUagc3B5vTJHebGkNT2lnONwCpo80xrOonlBJYHVe0KTvVNg sYHw== X-Gm-Message-State: ALoCoQl4ISlEF0syWJA5xliAMXW2SxWDPPDF9ORNW07mDNrFE1yhOXdvf0VLBy9q2AWmtSiVrXzW X-Received: by 10.140.194.8 with SMTP id p8mr39517474qha.63.1445266884469; Mon, 19 Oct 2015 08:01:24 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local ([173.38.117.84]) by smtp.googlemail.com with ESMTPSA id n17sm14507874qki.45.2015.10.19.08.01.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 08:01:24 -0700 (PDT) From: Victor Kuarsingh To: v6ops@ietf.org Message-ID: <562505C5.9000801@jvknet.com> Date: Mon, 19 Oct 2015 11:01:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:01:30 -0000 V6ops, We apologize for the delay from IETF93/Prague on getting discussions out for key topics on the draft-ietf-v6ops-design-choices document. We are sending out three separate emails to keep the discussion trains split for the three topics. The second discussion point was that of ULA text and how that was integrated into the document. The text will be updated to align well with other documents such as RFC7381 (Enterprise Incremental) and still points to documents such as draft-ietf-v6ops-ula-usage-recommendations. There was some objection to the association of RFC1918 and ULAs, which were both referred to as 'private' inside the design choices document. The author team recognizes that the RFC1918 addresses and ULAs are architecturally different. However the selection criteria and use cases by which an operator may use ULAs are common to how RFC1918 addresses would be selected / used. Also, many of the operational considerations are common when using ULAs vs. RFC1918. The document text will be updated (version -09) to ensure this is understood by the reader and that the ULA text is not seen as a directly replacement for RFC1918s. regards, Victor K From nobody Mon Oct 19 08:04:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A361AC3EE for ; Mon, 19 Oct 2015 08:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_WbeRZ11eqx for ; Mon, 19 Oct 2015 08:03:58 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11F31AC3F7 for ; Mon, 19 Oct 2015 08:03:48 -0700 (PDT) Received: by qkcy65 with SMTP id y65so17269076qkc.0 for ; Mon, 19 Oct 2015 08:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=A4EJhxrooeTiALa3a+FfqF/Ug9iteZyCVhkOYG6NdWU=; b=GNLiO/w0dG+oRZWOdMA5gEK6TA9trNDu3WZJEiQXh3Rpwd39e3EBrIHdpzL8yajWUk JK2hRkCe4k3166yGYpMrXKxAI96Yn31SWt1ckh7li5bKxyIc2LHSq9j4WzNv3ulfeNci mjI9UoVgPCE53VevTcWw/ZrreMtJ1UbPFrHIJVa6MytM31zwKEFZPymf6uXGdyaCOPSe CbxRFuL6yWQIQgUCo5njXVQm10K/mpGgLu2QK65A8eQ1NBnSsc3D2YclLXjrRwUElYTB FfNbamZ1v6PnzkwzglBKq1jO++JneLdEAS1DkZqZhigJWvvvWYdm0JXgLzIFfDbEvWJv 2Rzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=A4EJhxrooeTiALa3a+FfqF/Ug9iteZyCVhkOYG6NdWU=; b=HUW2/VyKIEmmLorAGP4F9v4f6TJVDo0RWOtWJlrpaHOM4Uioa9D6BGFpWhg6WbJIHo 9eahfOoAY02qNLGbjMi1MVjfEbJQQ0Cn356lPpy9EuLCK/7ABXcaBJuhGLJMYlEIBALU 893stLZssXrR8mEyGuzTOpV6H0gGjkl0LLQKI+pGgX4SdHqMRmnZ6Zg05+j2NZVx0JDx 3wyNRCLaA0vGVfqFL5Gl1awepnytd5umYPzkxMZv6i70c+eEVhFYcCJqF0kDMBsCmxJS 137OOXFlGu7I1ASpCcvV4IrIu+VgKgYg1W5yQrFIRM8yYcFxQt2Pilr2hBX4bDjgayhe 2DKA== X-Gm-Message-State: ALoCoQn004xa0/kVoTp8P5i91yYB7+1YdNZRcmFxkJCzbLd8Yr0QJCtbEJYe7l7xVUmIPeDfrUg/ X-Received: by 10.55.16.221 with SMTP id 90mr28839449qkq.81.1445267028117; Mon, 19 Oct 2015 08:03:48 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local ([173.38.117.84]) by smtp.googlemail.com with ESMTPSA id i34sm14517548qgd.8.2015.10.19.08.03.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 08:03:47 -0700 (PDT) From: Victor Kuarsingh To: v6ops@ietf.org Message-ID: <56250655.2040701@jvknet.com> Date: Mon, 19 Oct 2015 11:03:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:04:00 -0000 V6ops, We apologize for the delay from IETF93/Prague on getting discussions out for key topics on the draft-ietf-v6ops-design-choices document. We are sending out three separate emails to keep the discussion trains split for the three topics. The third item is related to NAT inclusion and related text. The text is begin updated to ensure that NAT is not recommended per se, but will continue to be in document given that is represents a valid choice under some real world circumstances which face the readers (looking at the full spectrum of readers). Comments were made at the WG meeting at IETF93/Prague which noted that NAT can be avoided, which is true, but those comments may not represent the vast number of Enterprises which have different capabilities and/or constraints. Very large Enterprises and the Enterprise Networks for a Service Provider are special uses cases where PI space is either easy to get, or the network is inherently behind a single SP so PA is not an issue. Many Enterprise networks have different constraints but still require flexibility to support more then one upstream provider, and use of PA space may be very limiting and add complexities in the future for the Enterprise. A specific use case is an Enterprise that cannot get PI space, but wishes the flexibility to easily change providers or multi-home; for these Enterprises NTP66 seems to be a reasonable choice. Does anyone have a reasonable alternative which is operationally sound. Its important for the document to consider this as a potential common use case for the wider audience which may not be reflected at the WG meetings. regards, Victor K From nobody Mon Oct 19 08:31:36 2015 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 5AA4C1ACD94; Mon, 19 Oct 2015 08:31:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019153135.12110.73858.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:31:35 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:31:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-09.txt Pages : 24 Date : 2015-10-19 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 08:36:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE791ACDD8 for ; Mon, 19 Oct 2015 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_Kfdcv_5Yt5 for ; Mon, 19 Oct 2015 08:36:33 -0700 (PDT) Received: from tor-smtp-03.primus.ca (smtp-auth2-111.primus.ca [209.183.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EC1ACDD7 for ; Mon, 19 Oct 2015 08:36:33 -0700 (PDT) Received: from [24.114.106.244] (helo=[172.20.10.4]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZoCUC-0002xy-IV; Mon, 19 Oct 2015 11:36:32 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20151019153135.12110.73858.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:36:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151019153135.12110.73858.idtracker@ietfa.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.106.244] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:36:34 -0000 This new version addresses the comments raised at the mic during the = Prague meeting and also includes the results of the informal poll of = operations taken in the early summer. Victor has already send some emails describing our responses to the = comments at the mic. - Philip and Victor On 2015-10-19, at 11:31 , Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-09.txt > Pages : 24 > Date : 2015-10-19 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Oct 19 08:38:36 2015 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 170A21AC3FC; Mon, 19 Oct 2015 08:38:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019153835.17533.82114.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:38:35 -0700 Archived-At: Cc: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-pmtud-ecmp-problem.all@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] Document Action: 'Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)' to Informational RFC (draft-ietf-v6ops-pmtud-ecmp-problem-06.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:38:35 -0000 The IESG has approved the following document: - 'Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)' (draft-ietf-v6ops-pmtud-ecmp-problem-06.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ Technical Summary This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. Working Group Summary The draft has been accepted with enthusiasm. Document Quality This is not a protocol. The operational mitigations proposed have been implemented in various places, but are not uniformly implemented. Personnel The Document Shepherd is Fred Baker. The Responsible Area Director is Benoit Claise. From nobody Mon Oct 19 10:35:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E161F1AD0C4; Mon, 19 Oct 2015 10:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBW493wCWIDh; Mon, 19 Oct 2015 10:35:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B5B1AD0B2; Mon, 19 Oct 2015 10:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sk+RWuPezHkNy1FZ8siaWDYHQ74PWn0538zQWdmzR8M=; b=SzlYwaqkxItmeuC6y9vIuPxih224yJfvVByDOcAw1UozwnTWl9U/zP64OFx2QCLQ5FT/n4xzdAOUKg6ePZW0ArInn8PkNMugndZwiiX69oeFb8oAsXxdx0UsroaZV7S3C1EuyR/aFIJBWB6sTkX+kBBl786K9s7O6X++FHwgOJo= Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 17:35:07 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 17:35:07 +0000 From: Dave Thaler To: Brian E Carpenter , Tomoyuki Sahara , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] TCP and IPV6_USE_MINMTU Thread-Index: AQHRB8SKeyUVtVFJGUedom5zWEgBop5ukkwAgAABuiiAACJUgIAABiiPgAGFmQCAAZ+H9YAABW+AgAAtSICAAA9wAIAA6tYg Date: Mon, 19 Oct 2015 17:35:06 +0000 Message-ID: References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> <655154DA-E515-4FDE-AAA2-975D4575B70B@iij.ad.jp> <56245BB6.8000200@gmail.com> In-Reply-To: <56245BB6.8000200@gmail.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=dthaler@microsoft.com; x-originating-ip: [166.176.185.19] x-microsoft-exchange-diagnostics: 1; BY2PR03MB410; 5:Cv8stUd4KbcRtphmVI36R2xEh5jjglVh4ktTfbiDsB7n9K9Y5RtgrelSQS7ghkEevRE/5+ZpJTe2ZT4anChzR4HTZYUnLmC0BDWmIVyXCGYmrTrnmaffY1HC1kaLz/sYRQvDg0mHypk1OVDmkN5ivA==; 24:qxs+xwFfYcIkosHt3sNly5N+69vWqwnMSSDe+JBzAjt8PaOfwAQtaQ90wBIfP6ntbc5HdUYzWPSTMlqqxf/v+v/mFI1K3LvN5nhxj3sGqfg=; 20:9FFBONxWfcvyVzPhnNJlB27974sOD20VehD/MP+lsM83H7zW2jpJSLwFhKtzRJBds+ScyRcUFb9RKYgiFCrsuA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB410; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB410; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(189002)(24454002)(13464003)(199003)(51444003)(86612001)(76176999)(54356999)(81156007)(5008740100001)(50986999)(97736004)(5003600100002)(5001770100001)(106116001)(93886004)(101416001)(46102003)(74316001)(11100500001)(92566002)(33656002)(2501003)(76576001)(87936001)(106356001)(40100003)(10400500002)(5002640100001)(8990500004)(10290500002)(5005710100001)(5001960100002)(5007970100001)(86362001)(189998001)(64706001)(19580395003)(19580405001)(66066001)(5004730100002)(10090500001)(122556002)(105586002)(2950100001)(2900100001)(77096005)(102836002)(15975445007)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 17:35:06.9278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB410 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 17:35:28 -0000 The IETF isn't the right standards org for APIs per se (hence API RFCs are usually informational). The Austin Group (ISO+IEEE+OpenGroup) standardizes POSIX APIs, W3C standardizes JavaScript APIs, etc. If the IETF wants APIs to become standards, then the IETF should be sending liaison statements to those organizations. Dave -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Sunday, October 18, 2015 7:56 PM To: Tomoyuki Sahara ; 6man@ietf.org Cc: v6ops@ietf.org Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU On 19/10/2015 15:00, Tomoyuki Sahara wrote: >>>> I think that >>>> (a) This draft should not be Informational, it should become a BCP. >>>> (b) I suspect it belongs in v6ops rather than 6man, since it=20 >>>> doesn't change anything in the standards. >>> >>> Isn't this similar to RFC6691 which was only informational? >>> >> >> I think Bob is saying this is an important enough issue that it should b= e given BCP status. >=20 > I agree that this is an important issue, but what practice can we=20 > recommend? >=20 > As is written in the draft, current TCP implementations ignore=20 > IPv6_USE_MIN_MTU when they send TCP SYNs with MSS options (I have=20 > tested and confirmed it on FreeBSD 10, NetBSD 6.1 and OpenBSD 5.7). > Linux distributions (CentOS/Ubuntu) don't support IPv6_USE_MIN_MTU at=20 > all, even on raw IPv6 sockets. Well, the recommendation is to fix that, and the first step to fix that is = for all stacks to support the Advanced Socket API. It is not unknown for the IETF to make implementation recommendations, and = sometimes vendors follow them. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://na01.safelinks.protection.outlook.com/?url= =3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fipv6&data=3D01%7c01%7c= dthaler%40microsoft.com%7cd1a4470b3e7f45aef61908d2d830e662%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3DqRHvroxLaBWeVvrzeq5eEseKirZYYmH9tQPQvs78vpk%= 3d -------------------------------------------------------------------- From nobody Mon Oct 19 11:59:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2441B2BF9; Mon, 19 Oct 2015 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbGPzagNBQsu; Mon, 19 Oct 2015 11:59:02 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391851B2B46; Mon, 19 Oct 2015 11:59:01 -0700 (PDT) Received: by pasz6 with SMTP id z6so37875201pas.2; Mon, 19 Oct 2015 11:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Qk+YfC305A7IODA/8DjFVaGfGh4yRP3TkUDZkcuzevQ=; b=FdP+JIrO5tVkC8BVlKDCH6+sX29MfRglxZX4u/BEp+NrkFDbOO1UTYbPFF/URoDpL0 l54ivrMItHAT65eb566dk+3rb+nbYl6nnLVVueG3WKFzjiS0c34PnFqYMyxUODi3hLIj zAwjDlX+azXfrb6O/+qDmDT7b+lm0Ya6cs6CWGxUm816WPdwGhV6G1DRucuLTJVH81DS Vr39yLo5jhhisf8yIFQLKZM4ZbstvytFIYZ/swBapHyQLNMux/OvvfJYQglt2yrcBkNC 6h5zkGq2sapIf9NWt3EDGscxjxacyNOozMdLxTVRbA5WutWFM7ycG9awOEwwgYrvJqQJ FBOw== X-Received: by 10.67.4.9 with SMTP id ca9mr36278788pad.90.1445281140834; Mon, 19 Oct 2015 11:59:00 -0700 (PDT) Received: from [192.168.178.25] (50.23.255.123.dynamic.snap.net.nz. [123.255.23.50]) by smtp.gmail.com with ESMTPSA id fa14sm37982200pac.8.2015.10.19.11.58.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 11:58:59 -0700 (PDT) To: Dave Thaler , Tomoyuki Sahara , "6man@ietf.org" <6man@ietf.org> References: <20151016034110.306563A939AB@rock.dv.isc.org> <20151016202620.GI1442@verdi> <20151016203155.3D2473AA8817@rock.dv.isc.org> <56217BAB.2040608@gmail.com> <20151016225655.CC0653AA9E81@rock.dv.isc.org> <5622C7A6.6000200@gmail.com> <20151018225806.A33903AB089A@rock.dv.isc.org> <655154DA-E515-4FDE-AAA2-975D4575B70B@iij.ad.jp> <56245BB6.8000200@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56253D6B.1010802@gmail.com> Date: Tue, 20 Oct 2015 07:58:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:59:06 -0000 On 20/10/2015 06:35, Dave Thaler wrote: > The IETF isn't the right standards org for APIs per se (hence API RFCs are > usually informational). The Austin Group (ISO+IEEE+OpenGroup) > standardizes POSIX APIs, W3C standardizes JavaScript APIs, etc. > > If the IETF wants APIs to become standards, then the IETF should be > sending liaison statements to those organizations. Indeed, and I believe we should do that. I hadn't realised until recently how big a hole this is in terms of IPv6 deployment glitches. It's a more general problem than just the current draft. Brian > > Dave > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Sunday, October 18, 2015 7:56 PM > To: Tomoyuki Sahara ; 6man@ietf.org > Cc: v6ops@ietf.org > Subject: Re: [v6ops] TCP and IPV6_USE_MINMTU > > On 19/10/2015 15:00, Tomoyuki Sahara wrote: >>>>> I think that >>>>> (a) This draft should not be Informational, it should become a BCP. >>>>> (b) I suspect it belongs in v6ops rather than 6man, since it >>>>> doesn't change anything in the standards. >>>> >>>> Isn't this similar to RFC6691 which was only informational? >>>> >>> >>> I think Bob is saying this is an important enough issue that it should be given BCP status. >> >> I agree that this is an important issue, but what practice can we >> recommend? >> >> As is written in the draft, current TCP implementations ignore >> IPv6_USE_MIN_MTU when they send TCP SYNs with MSS options (I have >> tested and confirmed it on FreeBSD 10, NetBSD 6.1 and OpenBSD 5.7). >> Linux distributions (CentOS/Ubuntu) don't support IPv6_USE_MIN_MTU at >> all, even on raw IPv6 sockets. > > Well, the recommendation is to fix that, and the first step to fix that is for all stacks to support the Advanced Socket API. > It is not unknown for the IETF to make implementation recommendations, and sometimes vendors follow them. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fipv6&data=01%7c01%7cdthaler%40microsoft.com%7cd1a4470b3e7f45aef61908d2d830e662%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qRHvroxLaBWeVvrzeq5eEseKirZYYmH9tQPQvs78vpk%3d > -------------------------------------------------------------------- > From nobody Mon Oct 19 13:04:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F71A905D for ; Mon, 19 Oct 2015 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHZ3o-LBtO0y for ; Mon, 19 Oct 2015 13:03:38 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613491A9060 for ; Mon, 19 Oct 2015 13:03:38 -0700 (PDT) Received: by pasz6 with SMTP id z6so39232747pas.2 for ; Mon, 19 Oct 2015 13:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=VpvykgsHW2uglmJpioemRnF+WmIYLb5J/tA6hdiYjTk=; b=j5fX+TyL6tUYkrXyMdgdYtf3DKOH27U4UEh9UZ1Y2FjSZrqNilXeoh6thPYiyGYy6b g1QekUS/oosax7tbSM5jYKuP/HlzwESNaKz4KNDMT/wImk2ZEaUEGWJJeEUWZveBDjXd 4mLUixC6GTf/BuUYW65S7B+i1kNeRRBetaPOvDvk/PUnY62GwBTOSIBipD9io6HjRpIS E7itsLOYlhH2NSjzoSnK+AgG1jgGwybZs/w1oCOn0l8dA/G42Aj6/b5CmMPgjhhhKP2R v9SJ1ywcEQia5byNNKH5gIRUierx0SIcfHFS5yCSCjYHuwsrMHVxtQ7+YPZTvXE/SXiI vHBw== X-Received: by 10.66.219.74 with SMTP id pm10mr36301797pac.93.1445285018049; Mon, 19 Oct 2015 13:03:38 -0700 (PDT) Received: from [192.168.178.25] (50.23.255.123.dynamic.snap.net.nz. [123.255.23.50]) by smtp.gmail.com with ESMTPSA id cx5sm15263716pbc.50.2015.10.19.13.03.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 13:03:37 -0700 (PDT) To: Victor Kuarsingh , v6ops@ietf.org References: <56250655.2040701@jvknet.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56254C98.2010501@gmail.com> Date: Tue, 20 Oct 2015 09:03:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56250655.2040701@jvknet.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:03:39 -0000 > If ULAs are the only non-Link-Local address available the > hosts, the enterprise will need to use translation technologies such > as NPT[RFC6296] or NAT66 to reach the Internet. I think this is still the wrong message. Here's my suggestion: The best approach is to use ULAs for internal communications and normal IPv6 addresses for external communications. Running multiple addresses in this way is a standard feature of IPv6. If for some reason an enterprise decides to use ULAs as the only non-Link-Local address available to its hosts, the enterprise will also need to use the experimental address prefix technology translation known as NPTv6 [RFC6296] to reach the Internet. Full address translation (known as NAT66) is never needed for IPv6 since there is no address shortage. Regards Brian Carpenter From nobody Mon Oct 19 14:02:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF011ACE87 for ; Mon, 19 Oct 2015 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmqNuxCvcDgN for ; Mon, 19 Oct 2015 14:02:23 -0700 (PDT) Received: from tor-smtp-03.primus.ca (smtp-auth2-149.primus.ca [216.254.140.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA831ACE88 for ; Mon, 19 Oct 2015 14:02:16 -0700 (PDT) Received: from [24.114.96.27] (helo=[172.20.10.4]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZoHZP-0006ww-Oe; Mon, 19 Oct 2015 17:02:16 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <56254C98.2010501@gmail.com> Date: Mon, 19 Oct 2015 17:02:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.96.27] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:02:25 -0000 Brian: What solution would you recommend today to a small-to-medium-sized = enterprise that cannot get PI space and wants the flexibility to easily = change providers and possibly multi-home? If the enterprise numbers their network internally with PA space, then = they need to renumber to change providers. Though this is definitely = easier in IPv6 than IPv4, it is still not "easy". And what about = multi-homing? - Philip On 2015-10-19, at 16:03 , Brian E Carpenter wrote: >> If ULAs are the only non-Link-Local address available the=09 >> hosts, the enterprise will need to use translation technologies such=09= >> as NPT[RFC6296] or NAT66 to reach the Internet.=20 >=20 > I think this is still the wrong message. Here's my suggestion: >=20 > The best approach is to use ULAs for internal communications and > normal IPv6 addresses for external communications. Running multiple > addresses in this way is a standard feature of IPv6. If for some = reason > an enterprise decides to use ULAs as the only non-Link-Local address > available to its hosts, the enterprise will also need to use the > experimental address prefix technology translation known as NPTv6 > [RFC6296] to reach the Internet. Full address translation (known > as NAT66) is never needed for IPv6 since there is no address shortage. >=20 > Regards > Brian Carpenter >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Oct 19 15:36:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965F1B2DD8 for ; Mon, 19 Oct 2015 15:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Berq187IwEhB for ; Mon, 19 Oct 2015 15:36:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EFB1B2DEB for ; Mon, 19 Oct 2015 15:36:49 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id AE44D3493BF; Mon, 19 Oct 2015 22:36:46 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 28A6B16003F; Mon, 19 Oct 2015 22:36:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D62A16008B; Mon, 19 Oct 2015 22:36:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iR0eYUOZmYOy; Mon, 19 Oct 2015 22:36:51 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B192116003F; Mon, 19 Oct 2015 22:36:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 09A293AC78F3; Tue, 20 Oct 2015 09:36:44 +1100 (EST) To: Philip Matthews From: Mark Andrews References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> In-reply-to: Your message of "Mon, 19 Oct 2015 17:02:13 -0400." <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> Date: Tue, 20 Oct 2015 09:36:43 +1100 Message-Id: <20151019223644.09A293AC78F3@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:36:52 -0000 In message <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca>, Philip Matthews wri tes: > Brian: > > What solution would you recommend today to a small-to-medium-sized enterprise > that cannot get PI space and wants the flexibility to easily change provider > s and possibly multi-home? > > If the enterprise numbers their network internally with PA space, then they n > eed to renumber to change providers. Though this is definitely easier in IPv6 > than IPv4, it is still not "easy". And what about multi-homing? > > - Philip ULA + GUA(s). They are going to have to update the DNS when they changes providers anyway. The ULA's provide local connection stability. The GUA's are for external connectivity. Use src address routing to send the traffic out the correct exit route. This is what homenet is doing for multi-homed home networks all without administrator intervention. Mac's can already use _dns-update._udp SRV records in the DNS to tell them where to send the TSIG signed updates for their address records (A and AAAA) in the DNS when they renumber so you don't even need to be running DHCP{v6} to update the DNS. There is no reason other OS vendors can't do the same thing. Mark > On 2015-10-19, at 16:03 , Brian E Carpenter wrote: > > >> If ULAs are the only non-Link-Local address available the > >> hosts, the enterprise will need to use translation technologies such > > >> as NPT[RFC6296] or NAT66 to reach the Internet. > > > > I think this is still the wrong message. Here's my suggestion: > > > > The best approach is to use ULAs for internal communications and > > normal IPv6 addresses for external communications. Running multiple > > addresses in this way is a standard feature of IPv6. If for some reason > > an enterprise decides to use ULAs as the only non-Link-Local address > > available to its hosts, the enterprise will also need to use the > > experimental address prefix technology translation known as NPTv6 > > [RFC6296] to reach the Internet. Full address translation (known > > as NAT66) is never needed for IPv6 since there is no address shortage. > > > > Regards > > Brian Carpenter > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Oct 19 16:45:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48D41B2EEE; Mon, 19 Oct 2015 16:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLdefof-KQK2; Mon, 19 Oct 2015 16:45:17 -0700 (PDT) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871621B2EED; Mon, 19 Oct 2015 16:45:12 -0700 (PDT) X-AuditID: 44571fa7-f79776d000005d5f-b4-56258086c783 Received: from pacdcexhub05.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id E8.C2.23903.78085265; Mon, 19 Oct 2015 19:45:11 -0400 (EDT) Received: from PACDCEX47.cable.comcast.com (24.40.2.146) by pacdcexhub05.cable.comcast.com (24.40.56.122) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 19 Oct 2015 19:45:07 -0400 Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by pacdcex47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 19 Oct 2015 19:45:06 -0400 Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Mon, 19 Oct 2015 19:45:06 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Thread-Index: AQHRCsgu8BDi3l57kUK5f73Z6TFrzg== Date: Mon, 19 Oct 2015 23:45:06 +0000 Message-ID: References: <20151019195001.22760.70127.idtracker@ietfa.amsl.com> In-Reply-To: <20151019195001.22760.70127.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsXiEq4ko9veoBpm0PlT0eLu95csFqeP7WV2 YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGr92vmAsOKFT0nTjN2MB4Rb6LkYNDQsBEYmGDWxcj J5ApJnHh3nq2LkYuDiGBXUwSByb+YYRw9jJKLDh9kQmkSkhgN6PEpj5PCPsko8SZOcYgNpuA jcTrDz8ZQWwRASmJxZ/3gtnMAqUSza9eMYPYwgLREl+n3WaHqEmQ6Hq3hxXC1pM4sPQcC4jN IqAqcXX5YbAaXgF7icfXP7BD7HKUWHOnD+wGTgEnia3Lp4PNZwS6+vupNUwQu8Qlbj2ZzwTx jYDEkj3nmSFsUYmXj/+B7RIF2tV+6j8bRNxAYuvSfSyQgJCX+DiXCcRkFtCUWL9LH8J0kJg7 NxhiuKLElO6HUIcJSpyc+QSsUQho4LwH0hDzxCUOH9nBOoFRdhaSc2YhzJyFMHMWkpmzkMxc wMi6ilGuIDE5JTk3I7+0xMBQLzkxKSdVLzk/NzmxuAREb2IEx7788h2M9144HWIU4GBU4uHd nqcaJsSaWFZcmXuIUYKDWUmEV7wWKMSbklhZlVqUH19UmpNafIhRmoNFSZx3871foUIC6Ykl qdmpqQWpRTBZJg5OqQbGFJ7Jz7tdM9+2uO/Y9/5DxYwND+P3d5g7Ft7M+54akWL2wd7CK62u +2PHxNMvDyi5XNCz2bXaecuWuMyVrz+z+0wM27zIUVY+ovOYvN/js8/jvH0d9szP/LCuY+qp jVNeuzxZ73K5YNVLq399gfm+yzv9Q6pt9+ZtXqghIpT4qedTr6c3V9osJZbijERDLeai4kQA Oj7wyfkCAAA= Archived-At: Cc: "draft-jjmb-v6ops-unique-ipv6-prefix-per-host@ietf.org" Subject: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 23:45:19 -0000 djZvcHMsDQoNCk92ZXIgdGhlIHBhc3Qgc2V2ZXJhbCB5ZWFycyB0aGVyZSBoYXMgYmVlbiBzb21l IHBsYW5uaW5nIGZvciBJUHY2IHN1cHBvcnQNCmZvciBhIGxhcmdlIHNjYWxlIFdpLUZpIGRlcGxv eW1lbnQuICBUdXJucyBhZnRlciBzaGFyaW5nIHNvbWUgb2YgdGhlc2UNCmRldGFpbHMgd2l0aCBt YW55IG9mIHlvdXIgb3ZlciB0aGUgcGFzdCBzZXZlcmFsIElFVEYgbWVldGluZ3MgdGhlcmUgaXMN CmludGVyZXN0IGJleW9uZCBXaS1GaSBmb3IgdGhpcyB3b3JrLiAgVGhlIEktRCBoYXMgZmluYWxs eSBiZWVuIHdyaXR0ZW4gc28NCnBsZWFzZSBzZW5kIHVzIHNvbWUgZmVlZGJhY2sgb24gdGhlIGxp c3QuICBBc3N1bWluZyB3ZSBnZXQgYWRlcXVhdGUNCmRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2Ug d2lsbCByZXF1ZXN0IGEgc2xvdCBpbiBZb2tvaGFtYSB0byBkaXNjdXNzIHRoaXMNCkktRC4NCg0K Sm9obiAmIEd1bnRlcg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog ImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkRh dGU6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAxNSBhdCAxNTo1MA0KVG86IEd1bnRlciBWYW4gZGUg VmVsZGUgPGd1bnRlci52YW5fZGVfdmVsZGVAYWxjYXRlbC1sdWNlbnQuY29tPiwgSm9obg0KSmFz b24gQnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPiwgR3VudGVy IFZhbiBkZSBWZWxkZQ0KPGd1bnRlci52YW5fZGVfdmVsZGVAYWxjYXRlbC1sdWNlbnQuY29tPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtamptYi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0 DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIEphc29uIEJyem96b3dz a2kgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0 LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+UmV2aXNpb246CTAwDQo+ VGl0bGU6CQlVbmlxdWUgSVB2NiBQcmVmaXggUGVyIEhvc3QNCj5Eb2N1bWVudCBkYXRlOgkyMDE1 LTEwLTE5DQo+R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTE0DQo+VVJM OiAgICAgICAgICAgIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wDQo+ZXItaG9zdC0wMC50eHQNCj5TdGF0 dXM6ICAgICAgICAgDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtampt Yi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWgNCj5vc3QvDQo+SHRtbGl6ZWQ6ICAgICAg IA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdC0wDQo+MA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIEluIHNvbWUg SVB2NiBlbnZpcm9ubWVudHMgdGhlIG5lZWQgaGFzIGFyaXNlbiBmb3IgaG9zdHMgdG8gYmUgYWJs ZSB0bw0KPiAgIHV0aWxpc2UgYSB1bmlxdWUgSVB2NiBwcmVmaXggZXZlbiB0aG91Z2ggdGhlIGxp bmsgb3IgbWVkaWEgbWF5IGJlDQo+ICAgc2hhcmVkLiAgVHlwaWNhbGx5IGhvc3RzIChzdWJzY3Jp YmVycykgb24gYSBzaGFyZWQgbmV0d29yaywgbGlrZSBXaS0NCj4gICBGaSBvciBFdGhlcm5ldCwg d2lsbCBhY3F1aXJlIHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBmcm9tIGEgY29tbW9uIElQdjYNCj4g ICBwcmVmaXggdGhhdCBpcyBhbGxvY2F0ZWQgb3IgYXNzaWduZWQgZm9yIHVzZSBvbiBhIHNwZWNp ZmljIGxpbmsuDQo+ICAgQmVuZWZpdHMgb2YgYSB1bmlxdWUgSVB2NiBwcmVmaXggY29tcGFyZWQg dG8gYSB1bmlxdWUgSVB2NiBhZGRyZXNzDQo+ICAgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBh cmUgZ29pbmcgZnJvbSBlbmhhbmNlZCBzdWJzY3JpYmVyDQo+ICAgbWFuYWdlbWVudCB0byBpbXBy b3ZlZCBpc29sYXRpb24gYmV0d2VlbiBzdWJzY3JpYmVycy4NCj4NCj4gICBJbiBtb3N0IGRlcGxv eW1lbnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBzaW5nbGUgSVB2Ng0K PiAgIHByZWZpeCBvbiBhIHNoYXJlZCBuZXR3b3JrIGlzIGRvbmUgYnkgZWl0aGVyIHVzaW5nIElQ djYgc3RhdGVsZXNzDQo+ICAgYWRkcmVzcyBhdXRvLWNvbmZpZ3VyYXRpb24gKFNMQUFDKSBhbmQv b3Igc3RhdGVmdWwgREhDUHY2LiAgV2hpbGUNCj4gICB0aGlzIGlzIHN0aWxsIHZpYWJsZSBhbmQg b3BlcmF0ZXMgYXMgZGVzaWduZWQgdGhlcmUgYXJlIHNvbWUgbGFyZ2UNCj4gICBzY2FsZSBlbnZp cm9ubWVudHMgd2hlcmUgdGhpcyBjb25jZXB0IGludHJvZHVjZXMgc2lnbmlmaWNhbnQNCj4gICBw ZXJmb3JtYW5jZSBjaGFsbGVuZ2VzIGFuZCBpbXBsaWNhdGlvbnMsIHNwZWNpZmljYWxseSByZWxh dGVkIHRvIElQdjYNCj4gICByb3V0ZXIgYW5kIG5laWdoYm9yIGRpc2NvdmVyeS4gIFRoaXMgZG9j dW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2gNCj4gICB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBw cm90b2NvbHMgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYQ0KPiAgIHVuaXF1ZSBJUHY2 IHByZWZpeCAoaW5zdGVhZCBvZiBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZA0K PiAgIElQdjYgcHJlZml4KS4NCj4NCj4gICAgICAgICAgICAgICAgICANCj4gICAgICAgIA0KPg0K Pg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4NCj4NCg0K From nobody Mon Oct 19 17:07:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21051B2F32 for ; Mon, 19 Oct 2015 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGoh-dU4CN71 for ; Mon, 19 Oct 2015 17:07:44 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7557E1B2F30 for ; Mon, 19 Oct 2015 17:07:44 -0700 (PDT) Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id t9K06hOA005093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2015 17:06:43 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151019223644.09A293AC78F3@rock.dv.isc.org> Date: Mon, 19 Oct 2015 17:06:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76AC18D7-12E9-4422-A31B-DB486BCBEFB1@delong.com> References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <20151019223644.09A293AC78F3@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org, Philip Matthews Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 00:07:45 -0000 > On Oct 19, 2015, at 15:36 , Mark Andrews wrote: >=20 >=20 > In message <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca>, Philip = Matthews wri > tes: >> Brian: >>=20 >> What solution would you recommend today to a small-to-medium-sized = enterprise >> that cannot get PI space and wants the flexibility to easily change = provider >> s and possibly multi-home? >>=20 >> If the enterprise numbers their network internally with PA space, = then they n >> eed to renumber to change providers. Though this is definitely easier = in IPv6 >> than IPv4, it is still not "easy". And what about multi-homing? >>=20 >> - Philip >=20 > ULA + GUA(s). They are going to have to update the DNS when they > changes providers anyway. The ULA's provide local connection > stability. The GUA's are for external connectivity. Use src address > routing to send the traffic out the correct exit route. This is > what homenet is doing for multi-homed home networks all without > administrator intervention. Wow=E2=80=A6 That=E2=80=99s icky. I=E2=80=99m glad my home is multihomed = with BGP. Owen From nobody Mon Oct 19 17:40:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1D1B2B37 for ; Mon, 19 Oct 2015 17:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv2DJf7rrAPg for ; Mon, 19 Oct 2015 17:40:50 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62EC1B2F7A for ; Mon, 19 Oct 2015 17:40:47 -0700 (PDT) Received: by padhk11 with SMTP id hk11so2417781pad.1 for ; Mon, 19 Oct 2015 17:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qZECBs+dbcqURE3cCZsIY9kfWx74jr+SbKk/2S9q3jI=; b=EHrPHVCPsz/qlxnCXgULMVkLYYW5dEDgDeGMelgn8CGk9KsCQCvSLTWbitcf7hW6YE zn62qbqW2PP7tpdgO2RVqrsgVeS0U1SMA/VN3xGg5qnm04oFYBCy4ClGjOWXfSBFNKs/ 6eR2fcNi01NFUZcjCHbcyuco1aHKFx6Tc6zzxJmV0mwQ4/3UqmjltetDKVLhyTBdaYb5 aIjjZ0LEmL/D510gBm01VN9u2N3OBwEwQEkK1C07nmkOLMdS9AC2J6z5/K0I7zQDr1VR I2o820uvf4+6QcyLdhhXxv193sRau8qlUXT0xTjDZp+BbkmwNX83GaA207zEwT93kCI2 REOQ== X-Received: by 10.68.253.66 with SMTP id zy2mr450676pbc.50.1445301647594; Mon, 19 Oct 2015 17:40:47 -0700 (PDT) Received: from [192.168.178.25] (50.23.255.123.dynamic.snap.net.nz. [123.255.23.50]) by smtp.gmail.com with ESMTPSA id cx5sm253868pbc.50.2015.10.19.17.40.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 17:40:46 -0700 (PDT) To: Philip Matthews References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56258D8D.2010702@gmail.com> Date: Tue, 20 Oct 2015 13:40:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 00:40:52 -0000 On 20/10/2015 10:02, Philip Matthews wrote: > Brian: > > What solution would you recommend today to a small-to-medium-sized enterprise that cannot get PI space and wants the flexibility to easily change providers and possibly multi-home? > > If the enterprise numbers their network internally with PA space, then they need to renumber to change providers. Though this is definitely easier in IPv6 than IPv4, it is still not "easy". And what about multi-homing? Run multiple prefixes. RFC 7157 (and draft-ietf-6man-multi-homed-host). Once you get your mind round that, renumbering seems easier too. I'm not trying to say this is completely straightforward. I'm left a bit frustrated by RFC 6879 and RFC 7010. Brian > > - Philip > > > On 2015-10-19, at 16:03 , Brian E Carpenter wrote: > >>> If ULAs are the only non-Link-Local address available the >>> hosts, the enterprise will need to use translation technologies such >>> as NPT[RFC6296] or NAT66 to reach the Internet. >> >> I think this is still the wrong message. Here's my suggestion: >> >> The best approach is to use ULAs for internal communications and >> normal IPv6 addresses for external communications. Running multiple >> addresses in this way is a standard feature of IPv6. If for some reason >> an enterprise decides to use ULAs as the only non-Link-Local address >> available to its hosts, the enterprise will also need to use the >> experimental address prefix technology translation known as NPTv6 >> [RFC6296] to reach the Internet. Full address translation (known >> as NAT66) is never needed for IPv6 since there is no address shortage. >> >> Regards >> Brian Carpenter >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > . > From nobody Mon Oct 19 18:04:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7B1B2F8C; Mon, 19 Oct 2015 18:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4hLJ9LjJVNA; Mon, 19 Oct 2015 18:04:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 2AFED1B2F8B; Mon, 19 Oct 2015 18:04:55 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.17.13]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZoLMA-0000iy-0D; Tue, 20 Oct 2015 03:04:50 +0200 To: Rick Casarez References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> <562155BC.6030701@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <562590A5.90802@si6networks.com> Date: Mon, 19 Oct 2015 21:53:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 01:04:57 -0000 Hi, Rick, On 10/18/2015 09:35 AM, Rick Casarez wrote: > Just trying to help. Answers in line. Indeed -- and that's really appreciated! > > In Section 2: > > > > Firewall - I am wondering if a better definition can be made. From > what > > you wrote I cannot distinguish between a Firewall and an ACL. > > An ACL is a policy. A firewall is a device that enforces filtering > policies. > > [Rick] Your definition would encompass routers and switches who have > ACL/Filters on interfaces/SVIs. I would not consider these firewalls. Well, that's a firewalling functionality. From a strict point of view, a router does not really drop offending packets, but just forwards them. > > No mention > > of state tracking for instance etc. > > Ok, will try to add somethin in this respect. > > [Rick] Please do, as Ca mentions this is how the vast majority of the > world define it as. This even includes common compliance audits like > PCI/SOC etc. Question: WOuld you include this as part of the fw definition, or rather e.g. simply define "state-tracking"? > > Section 5.1: > > > > "The drawback of this approach is that the security goal of "block > > traffic unless it is explicitly allowed" prevents useful new > applications." > > > > I am not sure I understand this line. It blocks new applications from > > immediately traversing the firewall. I know from experience though > that > > when a discussion is had with the NetSec team the application can be > > added to the allow list. So not sure a "default deny" means new stuff > > never gets allowed as the text insinuates. > > Well, that depends on where the firewall is being deployed, and if it is > actively managed. > > [Rick] I am unaware of any firewall deployed that is no longer managed. I'm told that comcast does currently deploys this sort of boxes for their IPv6 residential customers. And I'd argue that anything that is deployed at the home mostly follows into this category... > > Section 6: > > > > There are temporary IPv4 addresses too. > > Not by definition I'd say. Or... would you mind elaborating a bit more > in this respect? > > [Rick] My apologies on this one got some wires crossed. This is good to go. Thanks for double-checking! > > As for application being tunneled over well-known ports that > sounds like > > a breakdown of communication between the Service Owners and NetSec. > > Simple communication *should* lead to the creation of a profile > for that > > new application and its individual port. By doing what you describe it > > sounds like a Service Owner trying to get out of doing due diligence > > with NetSec or not knowing what port their application needs for > access > > (More common than you might think). > > Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls. > -- Ironically, at times these protocols are referred to as "firewall > friendly". > > [Rick] The scenario makes no sense other than a mismanaged company > frankly. You are essentially encouraging something against BCP. Even > beyond security you will make it difficult to troubleshoot if everything > is using the same port to traverse the firewall. We¿re not talking about companies, but about e.g. about firewalls deployed at homes, and applications meant to be employed by such users. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Oct 19 18:54:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D318E1AD09B for ; Mon, 19 Oct 2015 18:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMUDTSI9DxzQ for ; Mon, 19 Oct 2015 18:54:03 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5FE1AD09A for ; Mon, 19 Oct 2015 18:54:01 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMEykniVW677KBA--.10453S3; Tue, 20 Oct 2015 09:53:40 +0800 (CST) From: "Yu Fu" To: Date: Tue, 20 Oct 2015 09:53:43 +0800 Message-ID: <005101d10ada$26db2760$74917620$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEKe6JCP7xG2d2xQnGKIa3JAnYHywAWHhZQ Content-Language: zh-cn X-CM-TRANSID: AQAAf0ApMEykniVW677KBA--.10453S3 X-Coremail-Antispam: 1UD129KBjvJXoW7CrWxCry7ZF43Xr18Wr1rJFb_yoW8Zw1Dpa yqyws3K34rtwn5Kr4kAw15WFZ5Zan3KrW3CF97tr1UAan8GF1jyrnrK3yavFWDAa4UCrnF qF4xArn8uw1YvFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6w4l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8qjg7UUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [v6ops] FW: New Version Notification for draft-xu-v6ops-dslite-redundancy-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 01:54:05 -0000 Hi All, As the exhaustion of the public IPv4 address, service providers have = deployed DS-Lite in their network widely in nowadays, where a large = number of customers are located. These customers within a network which = is served by a single CGN function embedded in AFTR element may = experience service degradation due to the presence of the single point = of failure or loss of state information. Therefore, redundancy = capabilities of the AFTR devices are strongly desired in order to = deliver highly available services to customers. Failure detection and = repair time should be therefore shortened. Therefore, we have submitted a new draft to describe a redundancy = mechanism for DS-Lite. Comments are very appreciated.=20 Thanks. Cheers Yu -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 19, 2015 10:37 PM To: Honglei Xu; Xiaodong Lee; Qiong Sun; Qiong Sun; Yu Fu; XiaoDong Lee; = Yu Fu; Honglei Xu Subject: New Version Notification for = draft-xu-v6ops-dslite-redundancy-00.txt A new version of I-D, draft-xu-v6ops-dslite-redundancy-00.txt has been successfully submitted by Yu Fu and posted to the IETF = repository. Name: draft-xu-v6ops-dslite-redundancy Revision: 00 Title: A Redundancy Mechanism for Dual-Stack Lite Document date: 2015-10-19 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-xu-v6ops-dslite-redundancy-00.= txt Status: = https://datatracker.ietf.org/doc/draft-xu-v6ops-dslite-redundancy/ Htmlized: = https://tools.ietf.org/html/draft-xu-v6ops-dslite-redundancy-00 Abstract: Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. This document provide a redundancy mechanism for Dual-Stack Lite. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Mon Oct 19 19:39:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA651B29AE for ; Mon, 19 Oct 2015 19:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m50p5tPTObmG for ; Mon, 19 Oct 2015 19:39:25 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FC41B2850 for ; Mon, 19 Oct 2015 19:39:25 -0700 (PDT) Received: by vkfw189 with SMTP id w189so2289530vkf.2 for ; Mon, 19 Oct 2015 19:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8sTyo9pl0qWYMZnZWN8Tb+nePeS3DzEpMrkJDRf/eS0=; b=yFPfxQx480DBr4SuaEKbPduAqVl0KZ9AYtd9uwPnUCglKXOAH4JG2i1SxVSUShhU4A 9+LEr02YfGRPvxWlZvAyO9f/SRbwIFeTZvaWWZRrqBVv91hIV97qYQGKxOS7X2yfABLY K3xsmT+LQciilcEYVV7R0xcEx/JaFcOAK/Z7DqCjN+RNYu7VzVf8FncyIr2Rfj6efQ3u cVhf/LuL8Zh+7VmIWEkoZp0rKvIjV2svIIkkVPkyXXEnTjt9wrIo7WhenKCLtHWXqP1B q0L0RZQFJDBUxMXkFglEQ1p1R+V/rnq0CFyXiaZ0DcV+7ojcGTxv20lBJwOhcbGw5t2f hxHQ== X-Received: by 10.31.33.75 with SMTP id h72mr425187vkh.144.1445308764682; Mon, 19 Oct 2015 19:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.98.132 with HTTP; Mon, 19 Oct 2015 19:38:55 -0700 (PDT) In-Reply-To: <56254C98.2010501@gmail.com> References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> From: Mark Smith Date: Tue, 20 Oct 2015 13:38:55 +1100 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 02:39:27 -0000 On 20 October 2015 at 07:03, Brian E Carpenter wrote: >> If ULAs are the only non-Link-Local address available the >> hosts, the enterprise will need to use translation technologies such >> as NPT[RFC6296] or NAT66 to reach the Internet. > > I think this is still the wrong message. Here's my suggestion: > > The best approach is to use ULAs for internal communications and > normal IPv6 addresses for external communications. Running multiple > addresses in this way is a standard feature of IPv6. If for some reason > an enterprise decides to use ULAs as the only non-Link-Local address > available to its hosts, the enterprise will also need to use the > experimental address prefix technology translation known as NPTv6 > [RFC6296] to reach the Internet. If this is mentioned (and I would prefer it wasn't, because IPv4 NAT has caused me and the Internet enough trouble), then the limitations that even stateless NPT imposes on applications must be referenced: https://tools.ietf.org/html/rfc6296#section-5 > Full address translation (known > as NAT66) is never needed for IPv6 since there is no address shortage. > > Regards > Brian Carpenter > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 20 00:36:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2B1AD01E for ; Tue, 20 Oct 2015 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lznoljE6Oiii for ; Tue, 20 Oct 2015 00:36:02 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340021AD060 for ; Tue, 20 Oct 2015 00:36:02 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 74020D789F; Tue, 20 Oct 2015 00:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=2Ob9xFLUYvJ1/UsfkPHMp2Rwk70=; b= jZbkS8vjK6uH/IwlO8qnHGleOK7F1snE1a4eObVEdSmix3aNfTr3vjfKaVij15ld 27ceHetXRBzXsJitpD4XhOenPQNbGfgmc8YFXDo/Y3Khp0/am2Lpl2u/+uisWSJ5 7RfFXA+1XND2w3ievTAmJR8RCOhbIxGzoMSmCTNjQiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=TBe3/pJw0EO4p2BGnfP7iCNb7t Kn8dePLKlcsSIUhri+XPf6O90BpsJhF9cTGeDiOcjkSvzhj4MuSgP9z0Xmlci6L0 8pWoUUP1ytouGyDUQ6CsbVXpnVK+KCitE8WPRkl8vpSAmGcaZUGtRgeJkHToLURb gnw/tNRQ1tDUbVEss= Received: from h.hanazo.no (unknown [173.38.220.35]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 36E6CD789D; Tue, 20 Oct 2015 00:36:01 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C1A536CF716; Tue, 20 Oct 2015 09:36:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8E0EAB87-5CEC-4053-BEE4-4F2B7BBDDF27"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56258D8D.2010702@gmail.com> Date: Tue, 20 Oct 2015 09:36:00 +0200 Message-Id: <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3094) Archived-At: Cc: v6ops@ietf.org, Philip Matthews Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 07:36:04 -0000 --Apple-Mail=_8E0EAB87-5CEC-4053-BEE4-4F2B7BBDDF27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> What solution would you recommend today to a small-to-medium-sized = enterprise that cannot get PI space and wants the flexibility to easily = change providers and possibly multi-home? >>=20 >> If the enterprise numbers their network internally with PA space, = then they need to renumber to change providers. Though this is = definitely easier in IPv6 than IPv4, it is still not "easy". And what = about multi-homing? >=20 > Run multiple prefixes. RFC 7157 (and = draft-ietf-6man-multi-homed-host). > Once you get your mind round that, renumbering seems easier too. > I'm not trying to say this is completely straightforward. I'm left a = bit > frustrated by RFC 6879 and RFC 7010. it most definitely isn't straight forward. we've essentially put the responsibility of multi-homing to the host, = and you'd need something like MP-TCP or a very smart application (e.g. = MOSH). session layer anyone? I'm running MHMP at home, and I have not found any implementation I'm = very impressed with. operationally multi-homing when both links are up = works slightly worse than single-homing, and significantly worse when = one link is down. not quite the intended outcome. ;-) cheers, Ole --Apple-Mail=_8E0EAB87-5CEC-4053-BEE4-4F2B7BBDDF27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWJe7gAAoJEL7aWKiYQt92zZkQALFpcM9BbPTs7HesYcIcyQb9 y9smq8xDgO1pUo3BfvWXq/inn2xV+/b82B4DDnuBy7Hwc1XeWrmZQq1M4yoF9tzz d8N54V3ue8Ej/CuV7FlvQSuUWo8e03bNRLVVtAWloZ6t2F6h8azZDUDa8W7zULi4 nAOTo3yXT/6fk7f4uDvagpYFrk0iPV2gNTyinSa5+ld1L+8kyUVFNFJE2P8NEIip cSUh7Kos1CoqgPJi+aOpGs3+iAUGlvqsh/4gxA+d+WRUZoLNe5CGH29ld+EICfBG H0LQ9Wh4OVavDoboBa0JYxbfla/YP7WAOw7xVJK99aHYOTkYRGdYj9JUMICfIcUU k9DxUu3/LKkOTZGjn6B/3V1mObDfv7NWhD12SfqIlgF/FGVbMopURuy8pg+/73gV rT6dMpbl/KBCTTfbWGJogDiwBTLZ1UyKEPsptKRYrf7Quo6ArYZnmzhCyCUeCAIm OZOzUzRNVuAjZWUp9NRcEWmtwwE754G0iPXtGnCOl75R/3N0/BbLMq1qrDIyAsTC GiD+GhApUrANLMBEnTKHgaGQOJXu7VK71xYToiaXZsN4RWYbrljV+DvvM2tJSyP/ C9sYLGw8RIhccEzC1GV5az4bCbFUc7L7+kvRErSXTDgHpQkTUxS6eUmoHU83tRMJ HmxWMn+4TFTIH8ZPysRR =d5mR -----END PGP SIGNATURE----- --Apple-Mail=_8E0EAB87-5CEC-4053-BEE4-4F2B7BBDDF27-- From nobody Tue Oct 20 03:22:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498CB1B323F for ; Tue, 20 Oct 2015 03:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdxAYTARYS4u for ; Tue, 20 Oct 2015 03:22:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 21D601B323D for ; Tue, 20 Oct 2015 03:22:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZoU43-0000FdC; Tue, 20 Oct 2015 12:22:43 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> In-reply-to: Your message of "Tue, 20 Oct 2015 09:36:00 +0200 ." <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> Date: Tue, 20 Oct 2015 12:22:37 +0200 Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 10:22:47 -0000 In your letter dated Tue, 20 Oct 2015 09:36:00 +0200 you wrote: >it most definitely isn't straight forward. >we've essentially put the responsibility of multi-homing to the host, >and you'd need something like MP-TCP or a very smart application (e.g. >MOSH). session layer anyone? In my experience, when using SLAAC you can do a poor man's multi-homing by controlling which prefixes are preferred or not. When a link goes down, make that prefix deprecated. Obviously, existing connections will suffer, but if the loss of a link is relatively rare it works well enough. From nobody Tue Oct 20 05:17:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF311B3394; Tue, 20 Oct 2015 05:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLuXGdkCwHMx; Tue, 20 Oct 2015 05:17:24 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E0D1B33A3; Tue, 20 Oct 2015 05:17:24 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so42615602wic.1; Tue, 20 Oct 2015 05:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Mp4dMTWstIIjiRNPke2GkKSAKjrk+dV9yG9et6NeAQ=; b=P9bWEaSluWj6LwNoNZGu//96oPoLa1DsVMRD5SqO+gTk8eeGXymyf1+Bo52eVrDMUA IaIWcGJVkwqv/BUnBL859EBj3DH7JD49OmWQh2fdwy070a9N3CnNTFEuqEOSfS5N4Wyi z47nnIDfVFQZYPGdHz0glOXI8LkKs9g457z4Vf7Y/v1nekQWwxDsvLsjyoQm56ZYjTlz 7rCRNIAFKS27MgOn12FEluLZHCQOLq/XDtO/wh9Z+SQzwpwW03j302bvsZQ1LvbCFJG5 i6/3tEoPQ711Ayg6lPrMk4294a/Kl74cJdAdwIfFRkG4S2Fyri+fpneDdd5sz2nW7k9r oW/w== MIME-Version: 1.0 X-Received: by 10.180.211.8 with SMTP id my8mr25676649wic.21.1445343442559; Tue, 20 Oct 2015 05:17:22 -0700 (PDT) Received: by 10.27.108.76 with HTTP; Tue, 20 Oct 2015 05:17:22 -0700 (PDT) In-Reply-To: <562590A5.90802@si6networks.com> References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> <562155BC.6030701@si6networks.com> <562590A5.90802@si6networks.com> Date: Tue, 20 Oct 2015 08:17:22 -0400 Message-ID: From: Rick Casarez To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c38e0e78eea50522883ee9 Archived-At: Cc: "opsawg@ietf.org" , Internet Area , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 12:17:27 -0000 --001a11c38e0e78eea50522883ee9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm so maybe the problem is the scope of the draft. You seem to want to cover home-based unmanaged CPE devices that have firewall functionality built into them (Not dedicated firewalls as I recognize them). This is a very specific definition of firewall and a specific type of deployment. If you changed the introduction and scope to say you are only discussing this specific type of hardware and deployment then a lot of the problems I have with the text disappear. If you however want this draft to cover firewalls in general then you have to be aware of all the different ways they are deployed and maintained. You also need to distinguish what separates a firewall from general L3/L4 access-control. I can tell you the industry does differentiate between the two. As for your statement that routers just route packets, that has not been true for well over 18 years if not longer. ACLs/Filters on routing and switching devices is not a new phenomenon. Finally, to truly cover the subject you also have to at least mention the things that have replaced dedicated firewalls for security at the Edge (Load-balancers with built in Firewall functionality as an example) that even PCI and SOC have accepted. ------------------- Cheers, Rick Experiences not things. On Mon, Oct 19, 2015 at 8:53 PM, Fernando Gont wrote: > Hi, Rick, > > On 10/18/2015 09:35 AM, Rick Casarez wrote: > > Just trying to help. Answers in line. > > Indeed -- and that's really appreciated! > > > > > > In Section 2: > > > > > > Firewall - I am wondering if a better definition can be made. Fro= m > > what > > > you wrote I cannot distinguish between a Firewall and an ACL. > > > > An ACL is a policy. A firewall is a device that enforces filtering > > policies. > > > > [Rick] Your definition would encompass routers and switches who have > > ACL/Filters on interfaces/SVIs. I would not consider these firewalls. > > Well, that's a firewalling functionality. From a strict point of view, a > router does not really drop offending packets, but just forwards them. > > > > > > No mention > > > of state tracking for instance etc. > > > > Ok, will try to add somethin in this respect. > > > > [Rick] Please do, as Ca mentions this is how the vast majority of the > > world define it as. This even includes common compliance audits like > > PCI/SOC etc. > > Question: WOuld you include this as part of the fw definition, or rather > e.g. simply define "state-tracking"? > > > > > > Section 5.1: > > > > > > "The drawback of this approach is that the security goal of "bloc= k > > > traffic unless it is explicitly allowed" prevents useful new > > applications." > > > > > > I am not sure I understand this line. It blocks new applications > from > > > immediately traversing the firewall. I know from experience thoug= h > > that > > > when a discussion is had with the NetSec team the application can > be > > > added to the allow list. So not sure a "default deny" means new > stuff > > > never gets allowed as the text insinuates. > > > > Well, that depends on where the firewall is being deployed, and if > it is > > actively managed. > > > > [Rick] I am unaware of any firewall deployed that is no longer managed. > > I'm told that comcast does currently deploys this sort of boxes for > their IPv6 residential customers. > > And I'd argue that anything that is deployed at the home mostly follows > into this category... > > > > > > Section 6: > > > > > > There are temporary IPv4 addresses too. > > > > Not by definition I'd say. Or... would you mind elaborating a bit > more > > in this respect? > > > > [Rick] My apologies on this one got some wires crossed. This is good t= o > go. > > Thanks for double-checking! > > > > > > As for application being tunneled over well-known ports that > > sounds like > > > a breakdown of communication between the Service Owners and NetSe= c. > > > Simple communication *should* lead to the creation of a profile > > for that > > > new application and its individual port. By doing what you > describe it > > > sounds like a Service Owner trying to get out of doing due > diligence > > > with NetSec or not knowing what port their application needs for > > access > > > (More common than you might think). > > > > Yes. Or, at times, a user/app trying to circumvent unmanaged > firewalls. > > -- Ironically, at times these protocols are referred to as "firewal= l > > friendly". > > > > [Rick] The scenario makes no sense other than a mismanaged company > > frankly. You are essentially encouraging something against BCP. Even > > beyond security you will make it difficult to troubleshoot if everythin= g > > is using the same port to traverse the firewall. > > We=C2=BFre not talking about companies, but about e.g. about firewalls > deployed at homes, and applications meant to be employed by such users. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a11c38e0e78eea50522883ee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm so maybe the problem is the scope of the draft. Y= ou seem to want to cover home-based unmanaged CPE devices that have firewal= l functionality built into them (Not dedicated firewalls as I recognize the= m). This is a very specific definition of firewall and a specific type of d= eployment. If you changed the introduction and scope to say you are only di= scussing this specific type of hardware and deployment then a lot of the pr= oblems I have with the text disappear.

If you however want thi= s draft to cover firewalls in general then you have to be aware of all the = different ways they are deployed and maintained. You also need to distingui= sh what separates a firewall from general L3/L4 access-control. I can tell = you the industry does differentiate between the two.

As for your statement that routers just route packets, that h= as not been true for well over 18 years if not longer. ACLs/Filters on rout= ing and switching devices is not a new phenomenon.=C2=A0

Finally, to truly cover the subject you also have to= at least mention the things that have replaced dedicated firewalls for sec= urity at the Edge (Load-balancers with built in Firewall functionality as a= n example) that even PCI and SOC have accepted.
-------------------
Cheers, Rick

Experiences not things.
<= /div>

On Mon, Oct 19, 2015 at 8:53 PM, Fernando Go= nt <fgont@si6networks.com> wrote:
Hi, Rick,

On 10/18/2015 09:35 AM, Rick Casarez wrote:
> Just trying to help. Answers in line.

Indeed -- and that's really appreciated!



>=C2=A0 =C2=A0 =C2=A0> In Section 2:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Firewall - I am wondering if a better definiti= on can be made. From
>=C2=A0 =C2=A0 =C2=A0what
>=C2=A0 =C2=A0 =C2=A0> you wrote I cannot distinguish between a Firew= all and an ACL.
>
>=C2=A0 =C2=A0 =C2=A0An ACL is a policy. A firewall is a device that enf= orces filtering
>=C2=A0 =C2=A0 =C2=A0policies.
>
> [Rick] Your definition would encompass routers and switches who have > ACL/Filters on interfaces/SVIs. I would not consider these firewalls.<= br>
Well, that's a firewalling functionality. From a strict point of view, = a
router does not really drop offending packets, but just forwards them.



>=C2=A0 =C2=A0 =C2=A0> No mention
>=C2=A0 =C2=A0 =C2=A0> of state tracking for instance etc.
>
>=C2=A0 =C2=A0 =C2=A0Ok, will try to add somethin in this respect.
>
> [Rick] Please do, as Ca mentions this is how the vast majority of the<= br> > world define it as. This even includes common compliance audits like > PCI/SOC etc.

Question: WOuld you include this as part of the fw definition, or rather e.g. simply define "state-tracking"?



>=C2=A0 =C2=A0 =C2=A0> Section 5.1:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> "The drawback of this approach is that th= e security goal of "block
>=C2=A0 =C2=A0 =C2=A0> traffic unless it is explicitly allowed" = prevents useful new
>=C2=A0 =C2=A0 =C2=A0applications."
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I am not sure I understand this line. It block= s new applications from
>=C2=A0 =C2=A0 =C2=A0> immediately traversing the firewall. I know fr= om experience though
>=C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0> when a discussion is had with the NetSec team = the application can be
>=C2=A0 =C2=A0 =C2=A0> added to the allow list. So not sure a "d= efault deny" means new stuff
>=C2=A0 =C2=A0 =C2=A0> never gets allowed as the text insinuates.
>
>=C2=A0 =C2=A0 =C2=A0Well, that depends on where the firewall is being d= eployed, and if it is
>=C2=A0 =C2=A0 =C2=A0actively managed.
>
> [Rick] I am unaware of any firewall deployed that is no longer managed= .

I'm told that comcast does currently deploys this sort of boxes for
their IPv6 residential customers.

And I'd argue that anything that is deployed at the home mostly follows=
into this category...



>=C2=A0 =C2=A0 =C2=A0> Section 6:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> There are temporary IPv4 addresses too.
>
>=C2=A0 =C2=A0 =C2=A0Not by definition I'd say. Or... would you mind= elaborating a bit more
>=C2=A0 =C2=A0 =C2=A0in this respect?
>
>=C2=A0 [Rick] My apologies on this one got some wires crossed. This is = good to go.

Thanks for double-checking!



>=C2=A0 =C2=A0 =C2=A0> As for application being tunneled over well-kn= own ports that
>=C2=A0 =C2=A0 =C2=A0sounds like
>=C2=A0 =C2=A0 =C2=A0> a breakdown of communication between the Servi= ce Owners and NetSec.
>=C2=A0 =C2=A0 =C2=A0> Simple communication *should* lead to the crea= tion of a profile
>=C2=A0 =C2=A0 =C2=A0for that
>=C2=A0 =C2=A0 =C2=A0> new application and its individual port. By do= ing what you describe it
>=C2=A0 =C2=A0 =C2=A0> sounds like a Service Owner trying to get out = of doing due diligence
>=C2=A0 =C2=A0 =C2=A0> with NetSec or not knowing what port their app= lication needs for
>=C2=A0 =C2=A0 =C2=A0access
>=C2=A0 =C2=A0 =C2=A0> (More common than you might think).
>
>=C2=A0 =C2=A0 =C2=A0Yes. Or, at times, a user/app trying to circumvent = unmanaged firewalls.
>=C2=A0 =C2=A0 =C2=A0-- Ironically, at times these protocols are referre= d to as "firewall
>=C2=A0 =C2=A0 =C2=A0friendly".
>
>=C2=A0 [Rick] The scenario makes no sense other than a mismanaged compa= ny
> frankly. You are essentially encouraging something against BCP. Even > beyond security you will make it difficult to troubleshoot if everythi= ng
> is using the same port to traverse the firewall.

We=C2=BFre not talking about companies, but about e.g. about firewalls
deployed at homes, and applications meant to be employed by such users.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a11c38e0e78eea50522883ee9-- From nobody Tue Oct 20 05:47:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B491A1A8D for ; Tue, 20 Oct 2015 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiOHcVMC2iQ9 for ; Tue, 20 Oct 2015 05:47:48 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9912B1B33E6 for ; Tue, 20 Oct 2015 05:47:48 -0700 (PDT) Received: by qgad10 with SMTP id d10so13287099qga.3 for ; Tue, 20 Oct 2015 05:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XpNgrUc1PV19hsejcyUGzXjAVjjO0XqQ8+oNrJOkrbs=; b=v4otsFoEODmyhGa55Hju85lzUINrpa8ij0l5fXYufJFX0xKafATZE04YM6RgCan7Mz iQwfZ8WV1WDa9MYCxAeoFb6ckezhSPa3wF5NyUqK5Kjtgx7wl004uPKJZ+GZ+JO2vuMW d3cIhdcq2bbti4IZ4NoH7aXKMYUsnNggHwsLSm/mdOSwgIRiYeWFRgAllS6Flt0aWe4+ ggDy8fRUX94TRoHuXJkWz6ndRbcefZNX4eXmrCE4lyc/tiTxovaHD1w7b4MShX58Z0NA /zV+PQkJpQ0iCz8F465adoKRmn4Qc/sNRft2C8q4XdUZVA6tvM7GwnoQe8Gj7+aNtoFX txVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XpNgrUc1PV19hsejcyUGzXjAVjjO0XqQ8+oNrJOkrbs=; b=A1pXoD3UbGdMJXGb3HYGsbmdlNxJPPe1Ey+zOhczyrd/WAjnPsJ6oEp2ZjSIyPJL/K ZV2BVHulrKwXtdExKkfmmKYTNUuCUpBieJcTKYehKq/pMingySZAYG4LwhulZ+PArYiG q8tNjZ39alVJTmPJXQCj5WxLB3PKhkgI8OXLt/H3zpJIsXGLkphKbWf0OMdaz9qYQ38U DxrFvHtl/zdYDdAvxK4xWaOhfb10O2Wfg83DFR7mNaMLvxiNrvrReen5lIjINxAyhwOw FJQklJoW4enxyaQKnvK7AME0n3//J+uFd2NO8j53OYhDznpp8xgwr+RM9HXA9nJ1CFzM CuKg== X-Gm-Message-State: ALoCoQnDKeN4TpakZRVNPFaTbAOidwLWXsHz5RQ6HE4B0bTwaWG4GHZ86ki8j+oxsDYk18aqIMyK X-Received: by 10.140.101.73 with SMTP id t67mr3590185qge.71.1445345267761; Tue, 20 Oct 2015 05:47:47 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [173.35.15.124]) by smtp.googlemail.com with ESMTPSA id f23sm1160024qhc.18.2015.10.20.05.47.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 05:47:46 -0700 (PDT) To: Mark Smith , Brian E Carpenter References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> From: Victor Kuarsingh Message-ID: <562637F7.9020006@jvknet.com> Date: Tue, 20 Oct 2015 08:47:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 12:47:51 -0000 Mark, On 2015-10-19 10:38 PM, Mark Smith wrote: > On 20 October 2015 at 07:03, Brian E Carpenter > wrote: >>> If ULAs are the only non-Link-Local address available the >>> hosts, the enterprise will need to use translation technologies such >>> as NPT[RFC6296] or NAT66 to reach the Internet. >> I think this is still the wrong message. Here's my suggestion: >> >> The best approach is to use ULAs for internal communications and >> normal IPv6 addresses for external communications. Running multiple >> addresses in this way is a standard feature of IPv6. If for some reason >> an enterprise decides to use ULAs as the only non-Link-Local address >> available to its hosts, the enterprise will also need to use the >> experimental address prefix technology translation known as NPTv6 >> [RFC6296] to reach the Internet. > > If this is mentioned (and I would prefer it wasn't, So do I, however, that would then not reflect reality in real world choices operators / admins need to make. > because IPv4 NAT > has caused me and the Internet enough trouble), Yes, it's been a pain. > then the limitations > that even stateless NPT imposes on applications must be referenced: > > https://tools.ietf.org/html/rfc6296#section-5 Good reference / point. We should include this in text and refer to that. thanks, Victor K > >> Full address translation (known >> as NAT66) is never needed for IPv6 since there is no address shortage. >> >> Regards >> Brian Carpenter >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 20 05:53:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2AF1A00E9 for ; Tue, 20 Oct 2015 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdGe7z7Y-zfA for ; Tue, 20 Oct 2015 05:53:57 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715F01A00C2 for ; Tue, 20 Oct 2015 05:53:57 -0700 (PDT) Received: by qkfm62 with SMTP id m62so6759883qkf.1 for ; Tue, 20 Oct 2015 05:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=9NG3UEzIjWVtMCoPgJKk2ZBQyqVvRxU7iGq6H5DdF8U=; b=Vni9N7pwlflteqQvtgmMyNtzfjC6mqR/38LIRO8N4HNtzr/ix82OgcsYM2RaXaHPW2 VpN3IIubuNg7oIJ9hSpV+eiT02jfLy1JC7AGaRt0Se6DyDfyhcDp0IYvK75mzbpJt0GY hcwksBZy1nTYurjna9MqsxxZBoDu7lmTLf2KnCNhdbiq58hViJlQ1CgEGB4BvvS6vQjL pmCj2rzdBDp/2VOHAwZ9rf2L5FvOCmb5JW8dkqoNkGkloEaN+rwBzTrUIVtf6PeXyalJ 68/3vgXogDAbVK7c+FXt/DW6uNndv2RcuzpYYle2/CAb7ua0Ib27w4Nbp+y9FbpBhyGV HAeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9NG3UEzIjWVtMCoPgJKk2ZBQyqVvRxU7iGq6H5DdF8U=; b=cR9CWyPzmGmau5/ycV6AkfOkLxwC+e3YKPkg99S02fm/xSzkQ1tz9tNa6p+Rn/ILKM 2ndPawTHJ0iNLIBCBwzyasx/1UhYtiFbhwPzwV+ldeuskRYDyFm2PjjQ07sD2w/FrTDu cbnlIEnrGDfdkKKCul5Yl2ysXdTseTc33W6dmlZJrgx2DGFSd3iuLV7aV5HNpoYt0h86 ZwpxNrL7bCFYP1rvf7a4j1d2IU23RGMvq8a4Zl1VmrajkaX7oQbDduIMucG35602vsv4 j8YmtR4ZWHXFPhbduEA9oV3U49yGyqj8ZP2PmpbZM8fd/7Quum7na0SnXzr0uXg7hOR3 yi0A== X-Gm-Message-State: ALoCoQmcz9nqOczneTOsIEu39uOH+ncVIrzPjYoLqfd9MbpvCUgbVfHMW2AZgMd9OGaNAExzLCQW X-Received: by 10.55.50.149 with SMTP id y143mr3512847qky.86.1445345636591; Tue, 20 Oct 2015 05:53:56 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [173.35.15.124]) by smtp.googlemail.com with ESMTPSA id e65sm1169145qka.32.2015.10.20.05.53.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 05:53:56 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> From: Victor Kuarsingh Message-ID: <56263969.6030409@jvknet.com> Date: Tue, 20 Oct 2015 08:54:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 12:53:59 -0000 Philip, Interesting. Do you know if this poor man's approach is documented anywhere? In cases like this draft, it would be nice to point to a reference if possible. Trying to describe something like this - in-line with text - can be challenging. Beyond that, the challenge we would face it so get the mass set of operators / Enterprises to concisely understand such an approach, and on their own, figure out how to operationalize it. regards, Victor K On 2015-10-20 6:22 AM, Philip Homburg wrote: > In your letter dated Tue, 20 Oct 2015 09:36:00 +0200 you wrote: >> it most definitely isn't straight forward. >> we've essentially put the responsibility of multi-homing to the host, >> and you'd need something like MP-TCP or a very smart application (e.g. >> MOSH). session layer anyone? > In my experience, when using SLAAC you can do a poor man's multi-homing > by controlling which prefixes are preferred or not. > > When a link goes down, make that prefix deprecated. Obviously, existing > connections will suffer, but if the loss of a link is relatively rare > it works well enough. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 20 06:17:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1051A1AA8 for ; Tue, 20 Oct 2015 06:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6uFPVKlPxFC for ; Tue, 20 Oct 2015 06:17:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C7A201A1A99 for ; Tue, 20 Oct 2015 06:17:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZoWmj-0000FyC; Tue, 20 Oct 2015 15:17:01 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> <56263969.6030409@jvknet.com> In-reply-to: Your message of "Tue, 20 Oct 2015 08:54:01 -0400 ." <56263969.6030409@jvknet.com> Date: Tue, 20 Oct 2015 15:17:01 +0200 Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 13:17:06 -0000 In your letter dated Tue, 20 Oct 2015 08:54:01 -0400 you wrote: >Interesting. Do you know if this poor man's approach is documented >anywhere? In cases like this draft, it would be nice to point to a >reference if possible. Trying to describe something like this - in-line >with text - can be challenging. > >Beyond that, the challenge we would face it so get the mass set of >operators / Enterprises to concisely understand such an approach, and >on their own, figure out how to operationalize it. I'm not aware of any document that describes this. I wonder if there is a good text on how to do this with IPv4, i.e. two upstreams and a NAT box that decides which link to use. Playing with preferences manually is easy enough on any router that allows you to set the preferred time of a prefix. Document directed at operators could describe how to do it with popular routers. From nobody Tue Oct 20 11:36:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7EE1ACDE9 for ; Tue, 20 Oct 2015 11:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39o5ZDcAFvQw for ; Tue, 20 Oct 2015 11:36:17 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1D81ACDE0 for ; Tue, 20 Oct 2015 11:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4134; q=dns/txt; s=iport; t=1445366176; x=1446575776; h=from:to:subject:date:message-id:references:mime-version; bh=wi1teMSBfr3ebBaNACeGtbLRrDrM8mef+klWFRLd79w=; b=BSe08H6Ca6VXHmwvGFQv8MvQumSmEH4di/nSHFcghvJo1z+cEafstihg F2vwkwXXIHhAa2RTY9iB9V1sFDyZvpPzCdJI5ydSQeYFfwmzSJg9YoKJw NJgOhbmoJWzIO931yNtu94GYz2bAZdN6sgQUsnIRlwNsHWDByUBuDVNt4 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2AgAaiSZW/4cNJK1dgzZUbwa+Gw6BWhcMhXsCgUA4FAEBAQEBAQF/C4QtAQEBAwEBAQFrEAsCARkDAQIvJwsUBwIIAgQTCQWIGggNw3MBAQEBAQEBAQIBAQEBAQEBAQERCYkHgm6EfBMLgihPHYEUBZYkAYJNgWFqiAaBWEiDd45Lg1CDbgEfAUOEA3IBhGCBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,708,1437436800"; d="asc'?scan'208";a="199449267" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2015 18:36:16 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9KIaF5D021594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Oct 2015 18:36:15 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 13:35:57 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 13:35:57 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Thread-Index: AQHRCqeBeTtmQwm+m0SUoabvJiP7Ng== Date: Tue, 20 Oct 2015 18:35:57 +0000 Message-ID: <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.252.168] Content-Type: multipart/signed; boundary="Apple-Mail=_1305A1A2-AF5C-452A-9F8F-C4491DB83C1A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 18:36:18 -0000 --Apple-Mail=_1305A1A2-AF5C-452A-9F8F-C4491DB83C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Posted yesterday. Your comment solicited. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: = draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt > Date: October 19, 2015 at 12:50:01 PM PDT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt > Pages : 14 > Date : 2015-10-19 >=20 > Abstract: > In some IPv6 environments the need has arisen for hosts to be able = to > utilise a unique IPv6 prefix even though the link or media may be > shared. Typically hosts (subscribers) on a shared network, like Wi- > Fi or Ethernet, will acquire unique IPv6 addresses from a common = IPv6 > prefix that is allocated or assigned for use on a specific link. > Benefits of a unique IPv6 prefix compared to a unique IPv6 address > from the service provider are going from enhanced subscriber > management to improved isolation between subscribers. >=20 > In most deployments today IPv6 address assignment from a single IPv6 > prefix on a shared network is done by either using IPv6 stateless > address auto-configuration (SLAAC) and/or stateful DHCPv6. While > this is still viable and operates as designed there are some large > scale environments where this concept introduces significant > performance challenges and implications, specifically related to = IPv6 > router and neighbor discovery. This document outlines an approach > utilising existing IPv6 protocols to allow hosts to be assigned a > unique IPv6 prefix (instead of a unique IPv6 address from a shared > IPv6 prefix). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-0= 0 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_1305A1A2-AF5C-452A-9F8F-C4491DB83C1A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBViaJoUayAOS/EQ8MAQJ4xw//bhDGV7cEZ4WgmFmdiXRHzCWpZRpE3On9 P1uq1SXaXufzS1fUUDtpNRFEZZ9IioG5xoAuYOWHkdzawgmuFxCuunPuVbBews5a bMNtQ0nGzIC0+DFCHiazUVaA6i6GnNyFK53cPHNdtaWOwN7n/9i+nNYWi7+nX2vn 4TsN7skJV3roS3/Jn5UOrLFq+w9du8EijMh4WDeUG75veyBPg7jL8MXw/OoZ9Iir yI3LJYzFO75KWMXINfTxtQNHSzhNhC46rbNZGvxBtFCx3JjotTbTLPTBdiLDSpkX /REE1O/JZ4N7GVII00bZQWUZgrdRdPAEbHNde1jSHC4vIJMmFXqRfamhnm+ojsZf mQirX5YsVdPAJw/HCbEthu/eDR4xWmwPz3vOGYjVqGxIYEaHtxzSpSaNQaBpGMWz SufffEe4FN8RpPViHRdpJYF1f/ohtOAOEfKhUgYibz5AKD+Y9YVYlynThTskf70Z k4pD6fkoJTU+9+vc9QDpxhwkN0Hkq4XMTJmznTnFgKwsriudQB4WLB/Q+Gq1bW3s 1PpumJiy71R1Ptnd1E/NjhKx/cjF9XiUePuACw8jb7LrFYN6WjnI8xZXmzFHav/4 15ro3iTvbkrz/09yqCDjyAAKLciNnY8a39sUf1E2i6iv7SnYnSMNHzfaotMuFFBv ghvErtEM12E= =zsYt -----END PGP SIGNATURE----- --Apple-Mail=_1305A1A2-AF5C-452A-9F8F-C4491DB83C1A-- From nobody Tue Oct 20 12:34:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1164C1B29F6 for ; Tue, 20 Oct 2015 12:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQzNjIC6pMsV for ; Tue, 20 Oct 2015 12:34:08 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115C81AD210 for ; Tue, 20 Oct 2015 12:33:19 -0700 (PDT) Received: by padhk11 with SMTP id hk11so29980926pad.1 for ; Tue, 20 Oct 2015 12:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8A6es1Ps64ughk370LmX50B4g6VdofetXRB6WbWtI+Y=; b=QXSg42g2OHe6LbJRct9kLiswS3EP0kjrC/qePgzeo6VtjqjN6Ne9EA9CwGawnmZTmb vVDYoG1zF0orJSQF0Qbf6OEHGJFVP5FaV7x3+6e/XA4L9dzbTmbxTId//8IZ4/2jawVD VWyqcj5UUMpZeCyuful7Q9wh55pa2z6N9fNDIU0sUPMDPUrJjNUR5iDAB275PIo+Y/h9 Tv+caapzlYgIT3zFTT0f5TBFdcoEC2wvLee89EQ/wUxTM0Y63MnUvnZp5E6aIPUJ0U7C aJu9vq8yk2FX5I7eX2GfYt9JHLYoNMl3eR+B+12ucCMsZEvv9xGPjBx+l1Xdtrg2KRPv Fz9g== X-Received: by 10.66.233.70 with SMTP id tu6mr5819894pac.83.1445369598681; Tue, 20 Oct 2015 12:33:18 -0700 (PDT) Received: from [192.168.178.25] (197.22.255.123.dynamic.snap.net.nz. [123.255.22.197]) by smtp.gmail.com with ESMTPSA id an5sm5161269pbd.45.2015.10.20.12.33.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 12:33:17 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <562696FF.7040501@gmail.com> Date: Wed, 21 Oct 2015 08:33:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 19:34:10 -0000 On 20/10/2015 23:22, Philip Homburg wrote: > In your letter dated Tue, 20 Oct 2015 09:36:00 +0200 you wrote: >> it most definitely isn't straight forward. >> we've essentially put the responsibility of multi-homing to the host, >> and you'd need something like MP-TCP or a very smart application (e.g. >> MOSH). session layer anyone? > > In my experience, when using SLAAC you can do a poor man's multi-homing > by controlling which prefixes are preferred or not. > > When a link goes down, make that prefix deprecated. Obviously, existing > connections will suffer, but if the loss of a link is relatively rare > it works well enough. Yes. I have always regretted that the consensus in the multi6 WG was to include "Transport-Layer Survivability" as a requirement in RFC 3582. Since roaming already requires apps to survive transport layer failures, it's pretty pointless to require it for multihoming failovers. Brian From nobody Tue Oct 20 13:08:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E361A8BB4 for ; Tue, 20 Oct 2015 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARK-u4BUWsZe for ; Tue, 20 Oct 2015 13:08:20 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10DA1B2BBE for ; Tue, 20 Oct 2015 13:04:47 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 35984D789F; Tue, 20 Oct 2015 13:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=yeuDmu4WupJHoTWPmHvVHWPHoMU=; b= SoQ/AaDQUO/8Evh9lcgaD1pt5Zz/8mkMp2hL1cztfNgkhyy1YxYTdr6DFYJygfNc i+73xCAChRGcL3blUPfIzb4TjyXhBvADzDxiU9VXPDs4ECddu7oc2C1ZxNkRxrMI hD/IViTEnb7nmuqd+dzEkrzx3NeMG0gtnZ142RluSKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=g63Sk+bIBonwncqIM5GhDZDVta BPX5rB2Wr4HKQcvPXriwSbtLRecvtjgUVv85wdyPPOCi99hRvliqY4LbA7zfI8aj ZoWyh7TOqNjA9R8ggGhcfUk/ROk3LQ/oQUWUhM+bKevb5nV2feT8xHPEIugdNhFg bB1rEyx1TsscWRY18= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B8B2FD788E; Tue, 20 Oct 2015 13:04:45 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E494C6DE16B; Tue, 20 Oct 2015 22:04:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1AB8A1EA-7E5B-4AB0-AECF-1CF679C64235"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <562696FF.7040501@gmail.com> Date: Tue, 20 Oct 2015 22:04:40 +0200 Message-Id: References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> <562696FF.7040501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3094) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 20:08:22 -0000 --Apple-Mail=_1AB8A1EA-7E5B-4AB0-AECF-1CF679C64235 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> In your letter dated Tue, 20 Oct 2015 09:36:00 +0200 you wrote: >>> it most definitely isn't straight forward. >>> we've essentially put the responsibility of multi-homing to the = host, >>> and you'd need something like MP-TCP or a very smart application = (e.g. >>> MOSH). session layer anyone? >>=20 >> In my experience, when using SLAAC you can do a poor man's = multi-homing >> by controlling which prefixes are preferred or not. >>=20 >> When a link goes down, make that prefix deprecated. Obviously, = existing >> connections will suffer, but if the loss of a link is relatively rare >> it works well enough. >=20 > Yes. I have always regretted that the consensus in the multi6 WG was = to > include "Transport-Layer Survivability" as a requirement in RFC 3582. > Since roaming already requires apps to survive transport layer = failures, > it's pretty pointless to require it for multihoming failovers. indeed. addresses are ephemeral. unfortunately nothing above layer 3 has = come to terms with that. using address lifetimes as a "routing protocol" is a very bad idea = though, in anything but single link networks... cheers, Ole --Apple-Mail=_1AB8A1EA-7E5B-4AB0-AECF-1CF679C64235 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWJp5YAAoJEL7aWKiYQt92UVYP/3D1zLTlxlBaow8MTbDTFH6V /luJZApl2Pkf+/ll6L9ddaIlqAX3UEfJvC72IhnGYsPZ1oQd8zRezZMXXFrypp22 ucCICLy4VDd1BSASRjQrvIsqgly+WottCRU3Fsxc/xPTij2MQImQjW/QtiCMP1MC +Nd+Latqh6zx92JiwuRz/TgZSCezdNRGwNt+IqlH5zK/t75kdL2s4vsAC8KnZVDq mZBQyym9fVmL0MpTxU4DfQ7ob4eYUiMHDRlslXURyx7dUuzG+6fGqHz7udtUk0xW gZXpevAWgS6dS1Eq2MD5a7IYk8HdV2t9FAEvfUrPAvSUfhtSNEfq71sXE8AUKsnQ imdJVQovcHzdc64Zc78n54z9VKRE2nYpJHPYjVMtfL1FnBHRCOwfIMNnO3p2n2fu 8cXGL4StVwkT9LfGoUl2c0Vym1GMC33iVsGa8aiD9bCXUnun1agqPdGIlCuRKT3f wv+tifDY6/0ez1XFJumEXRaNy2TRbns6sQ/Na33cEx2U8SMXCV4k3RqPSu4WLS3u 84cy5jI2MNPsMYsI+x4liyYPNx41wV3iByU0eaHXRtyW/S5Gi9QtjAcFt2sAGowe Mv4GMjE6guaQsvv5rILBQoffncy051W6bpmAKuHUOFoRPwab2ossj6ZeQqABVp/m xuZj9GKN6tnXqEzLGaE8 =v7Ei -----END PGP SIGNATURE----- --Apple-Mail=_1AB8A1EA-7E5B-4AB0-AECF-1CF679C64235-- From nobody Tue Oct 20 14:33:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBA11ACE2D for ; Tue, 20 Oct 2015 14:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5lJdOw2HLtz for ; Tue, 20 Oct 2015 14:32:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F51B2CB2 for ; Tue, 20 Oct 2015 14:31:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZoeV6-0000GyC; Tue, 20 Oct 2015 23:31:20 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org> <562696FF.7040501@gmail.com> In-reply-to: Your message of "Tue, 20 Oct 2015 22:04:40 +0200 ." Date: Tue, 20 Oct 2015 23:31:14 +0200 Archived-At: Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 21:33:00 -0000 In your letter dated Tue, 20 Oct 2015 22:04:40 +0200 you wrote: >indeed. addresses are ephemeral. unfortunately nothing above layer 3 has >come to terms with that. >using address lifetimes as a "routing protocol" is a very bad idea >though, in anything but single link networks... It is not a routing protocol. With ingress filtering an address becomes unavailable when a link goes down because the other link doesn't support the prefix from which the address was taken. The routing part is (in theory) a trivial extension to most routing protocols and fibs. Distributing which links are up or down and therefor which prefixes are available or not is probable something for HNCP (or similar). Though in setups with a single router, it probably can be done by hand as well. From nobody Tue Oct 20 17:52:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F21B2AAA for ; Tue, 20 Oct 2015 17:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6_3MVncGAym for ; Tue, 20 Oct 2015 17:52:24 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66D21B2A90 for ; Tue, 20 Oct 2015 17:52:23 -0700 (PDT) Received: by qkbl190 with SMTP id l190so15785210qkb.2 for ; Tue, 20 Oct 2015 17:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=5cKVGJF0VEPUTdcdDNzE+RkkEuSJKc71qNreaRoYmjw=; b=sKJ4VHdaKJTFe9uor4KF0ON99KI669f7jVU1eazQgLtkhIa9h7gj5pbC68ND9UBY/P m2FujamuZyDzxpiOebQoj9FAvcGYehVPB4fJq7ZDYBsq4AaxGjRn5rAgshChkn8gXrUs ttXjVMT8hzaic1zpnFC4Bq3KVXgSkKAGL8c71hY8VVjpzPEnat0JOTM9a/XMqF3gLKOL 6xSv1x72P2oSzIyul6YCWv7Ozyc9qAl3FfYsbiMEYIavXtyMYpIjNkdplOq7zAAb2vfB 5MNVTle5PgC4VoeArmOGicoLaWjyMVbfbGF/JZAZK/1wfhgE8d46RgAL2ipzxDu2Rhd8 iStA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=5cKVGJF0VEPUTdcdDNzE+RkkEuSJKc71qNreaRoYmjw=; b=eiO55ptrIYyzL2vigw+c30dhSGADhfqYAzZfhXZGffAl4ODcSWId1HzbC0MSEqBpXc rr5+vUdhOGaL72w+XLG6KqESHAN5WKnp3KFJIgd3UCWB9jNPM2SRfL8z6aUbCBqndtRC kyui8Kqd+MHtnCzemKy2RS8CqVnVQkcpHu/5s8T2A7BHqStGjZMQw8ZUEJUEuIlMmPx2 3zUfm70omYMWf3syJaPA386t/SncL91zKO7XyIGF2RFv9HUUleOhdYx/cHyehASHrEdg au4LhkyT8f0hsF7vCqCQs4qG843fgJ6Fw/1wa0hmzK1ZAjlJ2AXMysL1Czj8oPApRWgQ TJ/w== X-Gm-Message-State: ALoCoQlfWtYUz3+I3oEdfoI5vu4yE7eGC+KdHvSj1EOHbXQRjqe3Z6VK2gSj02htvoKBvr3hdbYv X-Received: by 10.55.41.93 with SMTP id p90mr7520221qkh.14.1445388743052; Tue, 20 Oct 2015 17:52:23 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [173.35.15.124]) by smtp.googlemail.com with ESMTPSA id 23sm1884280qhy.6.2015.10.20.17.52.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 17:52:22 -0700 (PDT) To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> From: Victor Kuarsingh Message-ID: <5626E1C6.8050209@jvknet.com> Date: Tue, 20 Oct 2015 20:52:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> Content-Type: multipart/alternative; boundary="------------010402050709040806030406" Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 00:52:26 -0000 This is a multi-part message in MIME format. --------------010402050709040806030406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit John/Gunter, Overall, good draft, well explained case and detailed explanation of deployment. On to comment... Based on this text .. "The /64 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the WLAN-GW or from a pool signalled by the Radius server in a radius attribute." Its seems clear that the /64s would come from a pool and/or block as you noted. I would think that under the operational considerations section we would want to add some text that notes the management requirements to size/manage those blocks/pools. Under a traditional case, with a /64 per WLAN-GW, the number of addresses that can be consumed by that one /64 would not require management. However, in this case, it's possible to exhaust the # of blocks. If the WLAN-GW is L3, then in large venues - say stadiums or open areas, sizing for peak demand periods would need to be considered as well. Sizing/management is likely not as much of an issue in the "coffee shop" deployment instance. The text need not be complicated, but should note that some attention / management is required. regards, Victor K On 2015-10-20 2:35 PM, Fred Baker (fred) wrote: > Posted yesterday. Your comment solicited. > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt >> Date: October 19, 2015 at 12:50:01 PM PDT >> To: >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Unique IPv6 Prefix Per Host >> Authors : John Jason Brzozowski >> Gunter Van De Velde >> Filename : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt >> Pages : 14 >> Date : 2015-10-19 >> >> Abstract: >> In some IPv6 environments the need has arisen for hosts to be able to >> utilise a unique IPv6 prefix even though the link or media may be >> shared. Typically hosts (subscribers) on a shared network, like Wi- >> Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6 >> prefix that is allocated or assigned for use on a specific link. >> Benefits of a unique IPv6 prefix compared to a unique IPv6 address >> from the service provider are going from enhanced subscriber >> management to improved isolation between subscribers. >> >> In most deployments today IPv6 address assignment from a single IPv6 >> prefix on a shared network is done by either using IPv6 stateless >> address auto-configuration (SLAAC) and/or stateful DHCPv6. While >> this is still viable and operates as designed there are some large >> scale environments where this concept introduces significant >> performance challenges and implications, specifically related to IPv6 >> router and neighbor discovery. This document outlines an approach >> utilising existing IPv6 protocols to allow hosts to be assigned a >> unique IPv6 prefix (instead of a unique IPv6 address from a shared >> IPv6 prefix). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-host/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------010402050709040806030406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit John/Gunter,

Overall, good draft, well explained case and detailed explanation of deployment.

On to comment...

Based on this text .. "The /64
   prefix can be derived from a locally managed pool or aggregate IPv6
   block assigned to the WLAN-GW or from a pool signalled by the Radius
   server in a radius attribute."

Its seems clear that the /64s would come from a pool and/or block as you noted. 

I would think that under the operational considerations section we would want to add some text that notes the management requirements to size/manage those blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the number of addresses that can be consumed by that one /64 would not require management. 

However, in this case, it's possible to exhaust the #  of blocks.  If the WLAN-GW is L3, then in large venues - say stadiums or open areas, sizing for peak demand periods would need to be considered as well.  Sizing/management is likely not as much of an issue in the "coffee shop" deployment instance.


The text need not be complicated, but should note that some attention / management is required.

regards,

Victor K




On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:
Posted yesterday. Your comment solicited.


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Date: October 19, 2015 at 12:50:01 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


       Title           : Unique IPv6 Prefix Per Host
       Authors         : John Jason Brzozowski
                         Gunter Van De Velde
	Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
	Pages           : 14
	Date            : 2015-10-19

Abstract:
  In some IPv6 environments the need has arisen for hosts to be able to
  utilise a unique IPv6 prefix even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, like Wi-
  Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
  prefix that is allocated or assigned for use on a specific link.
  Benefits of a unique IPv6 prefix compared to a unique IPv6 address
  from the service provider are going from enhanced subscriber
  management to improved isolation between subscribers.

  In most deployments today IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.  This document outlines an approach
  utilising existing IPv6 protocols to allow hosts to be assigned a
  unique IPv6 prefix (instead of a unique IPv6 address from a shared
  IPv6 prefix).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


      

      

      

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


    

    

  


--------------010402050709040806030406--


From nobody Tue Oct 20 18:31:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5141B2BC1 for ; Tue, 20 Oct 2015 18:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level: 
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2daiS5bVRBn for ; Tue, 20 Oct 2015 18:31:01 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13021B2C13 for ; Tue, 20 Oct 2015 18:31:00 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-fa-5626ead22fb7
Received: from pacdcexhub04.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 7F.00.04607.2DAE6265; Tue, 20 Oct 2015 21:30:59 -0400 (EDT)
Received: from PACDCEX47.cable.comcast.com (24.40.2.146) by pacdcexhub04.cable.comcast.com (24.40.56.121) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 Oct 2015 21:30:58 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by pacdcex47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 20 Oct 2015 21:30:57 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Tue, 20 Oct 2015 21:30:57 -0400
From: "Brzozowski, John" 
To: Victor Kuarsingh 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRC5rNn1oaXPpdb0m/H+tIWUdOwp51KQ4X
Date: Wed, 21 Oct 2015 01:30:56 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>, <5626E1C6.8050209@jvknet.com>
In-Reply-To: <5626E1C6.8050209@jvknet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_FD4C158A3E4F4B7D83970941B2CCC959CableComcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsXiEq4ko3v5lVqYweJGAYv3686wWZw+tpfZ 4vrix6wOzB5Tfm9k9Viy5CeTx99nZ9gDmKO4bFJSczLLUov07RK4Mh6+eMJU0JhWcfniXOYG xmmhXYycHBICJhIv78xhhLDFJC7cW8/WxcjFISSwi0lixt4PrBDOXkaJLZNvM4NUCQnsZpQ4 vTgBInGSUeLoxucsIAk2ARuJ1x9+go0SEdCQuDHrKlicWcBb4tb+WWBxYYFoiR1b+tkgamIk Zr1oZIKwjSQWPvnJDmKzCKhK3FnzEayGV8BF4tvj7YwQyyYySjxf/4sVJMEpoCWxqn8dmM0I dPf3U2uYIJaJS9x6Mp8J4h8BiSV7zjND2KISLx//Y4WwDSS2Lt0HdVy6xIXWtewQywQlTs58 AhTnAFqmJzHvgTREubjE4SM7WCcwSs5CsmEWku5ZSLoh4joSC3Z/YoOwtSWWLXzNDGOfOfCY CVl8ASP7Kka5gsTklOTcjPzSEgNDveTEpJxUveT83OTE4hIQvYkRHPnyy3cw3nvhdIhRgINR iYd36QO1MCHWxLLiytxDjBIczEoivCevAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzbr73K1RI ID2xJDU7NbUgtQgmy8TBKdXAeCR77b2b06edOv7PXCRrRfoDAfs4u87JIUztbTcfiq868O3t M7kPMcdbz5uzuk2o+lAWM0dqrvZUoStzDPjnGDKerz+nzxxaIJDdYzzz10PnF7+WxB020am9 4rl/gTe31WWZGedF+PS+/z193y8g3OLfG4vK/kDe96oH9HrufI1YIsXLfWp/lxJLcUaioRZz UXEiAFgdZ534AgAA
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 01:31:04 -0000

--_000_FD4C158A3E4F4B7D83970941B2CCC959CableComcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Victor.  I will confer with Gunter on some text.

As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks.  The W=
LAN-GW IPv6 capacity would have to be managed similar to how we manage bloc=
k sizes for prefix delegation.  The parent IPv6 block would have to be able=
 to a accommodate the overall capacity of the WLAN-GW.

Once a WLAN-GW reaches capacity either from a bandwidth point of view, IPv6=
 prefixes, etc. the WLAN-GW split would need to occur.

One more note, the WLAN-GW would only advertise the parent IPv6 block to av=
oid route table bloat.  Perhaps this should be listed as another operationa=
l consideration.

John
+1-484-962-0060

On Oct 20, 2015, at 20:52, Victor Kuarsingh > wrote:

John/Gunter,

Overall, good draft, well explained case and detailed explanation of deploy=
ment.

On to comment...

Based on this text .. "The /64
   prefix can be derived from a locally managed pool or aggregate IPv6
   block assigned to the WLAN-GW or from a pool signalled by the Radius
   server in a radius attribute."

Its seems clear that the /64s would come from a pool and/or block as you no=
ted.

I would think that under the operational considerations section we would wa=
nt to add some text that notes the management requirements to size/manage t=
hose blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the n=
umber of addresses that can be consumed by that one /64 would not require m=
anagement.

However, in this case, it's possible to exhaust the #  of blocks.  If the W=
LAN-GW is L3, then in large venues - say stadiums or open areas, sizing for=
 peak demand periods would need to be considered as well.  Sizing/managemen=
t is likely not as much of an issue in the "coffee shop" deployment instanc=
e.


The text need not be complicated, but should note that some attention / man=
agement is required.

regards,

Victor K




On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:

Posted yesterday. Your comment solicited.



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Date: October 19, 2015 at 12:50:01 PM PDT
To: 
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


       Title           : Unique IPv6 Prefix Per Host
       Authors         : John Jason Brzozowski
                         Gunter Van De Velde
        Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.t=
xt
        Pages           : 14
        Date            : 2015-10-19

Abstract:
  In some IPv6 environments the need has arisen for hosts to be able to
  utilise a unique IPv6 prefix even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, like Wi-
  Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
  prefix that is allocated or assigned for use on a specific link.
  Benefits of a unique IPv6 prefix compared to a unique IPv6 address
  from the service provider are going from enhanced subscriber
  management to improved isolation between subscribers.

  In most deployments today IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.  This document outlines an approach
  utilising existing IPv6 protocols to allow hosts to be assigned a
  unique IPv6 prefix (instead of a unique IPv6 address from a shared
  IPv6 prefix).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-ho=
st/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




_______________________________________________
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

--_000_FD4C158A3E4F4B7D83970941B2CCC959CableComcastcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Thanks Victor.  I will confer with Gunter on some text.







As an aside I view the WLAN-GW as I would a =
CMTS in DOCSIS networks.  The WLAN-GW IPv6 capacity would have to be m=
anaged similar to how we manage block sizes for prefix delegation.  Th=
e parent IPv6 block would have to be able to
 a accommodate the overall capacity of the WLAN-GW.







Once a WLAN-GW reaches capacity either from =
a bandwidth point of view, IPv6 prefixes, etc. the WLAN-GW split would need=
 to occur.







One more note, the WLAN-GW would only advert=
ise the parent IPv6 block to avoid route table bloat.  Perhaps this sh=
ould be listed as another operational consideration.



John

+1-484-962-0060






On Oct 20, 2015, at 20:52, Victor Kuarsingh <victor@jvknet.com> wrote:








John/Gunter,



Overall, good draft, well explained case and detailed explanation of deploy=
ment.



On to comment...



Based on this text .. "The /64

   prefix can be derived from a locally managed pool or aggregate=
 IPv6

   block assigned to the WLAN-GW or from a pool signalled by the =
Radius

   server in a radius attribute."



Its seems clear that the /64s would come from a pool and/or block as you no=
ted.  



I would think that under the operational considerations section we would wa=
nt to add some text that notes the management requirements to size/manage t=
hose blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, =
the number of addresses that can be consumed
 by that one /64 would not require management.  



However, in this case, it's possible to exhaust the #  of blocks. =
; If the WLAN-GW is L3, then in large venues - say stadiums or open areas, =
sizing for peak demand periods would need to be considered as well.  S=
izing/management is likely not as much of an issue
 in the "coffee shop" deployment instance.





The text need not be complicated, but should note that some attention / man=
agement is required.



regards,



Victor K










On 2015-10-20 2:35 PM, Fred Baker (fred) wro=
te:






Posted yesterday. Your comment solicited.






Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Date: October 19, 2015 at 12:50:01 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


       Title           : Unique IPv6 Prefix Per Host
       Authors         : John Jason Brzozowski
                         Gunter Van De Velde
	Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
	Pages           : 14
	Date            : 2015-10-19

Abstract:
  In some IPv6 environments the need has arisen for hosts to be able to
  utilise a unique IPv6 prefix even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, like Wi-
  Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
  prefix that is allocated or assigned for use on a specific link.
  Benefits of a unique IPv6 prefix compared to a unique IPv6 address
  from the service provider are going from enhanced subscriber
  management to improved isolation between subscribers.

  In most deployments today IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.  This document outlines an approach
  utilising existing IPv6 protocols to allow hosts to be assigned a
  unique IPv6 prefix (instead of a unique IPv6 address from a shared
  IPv6 prefix).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.or=
g/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-host/

There's also a htmlized version available at:
https://tools.ietf.org/html/dr=
aft-jjmb-v6ops-unique-ipv6-prefix-per-host-00


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt









 


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













_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.i=
etf.org/mailman/listinfo/v6ops








--_000_FD4C158A3E4F4B7D83970941B2CCC959CableComcastcom_--


From nobody Tue Oct 20 18:41:15 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626231B2C34 for ; Tue, 20 Oct 2015 18:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHZ0cu9tgBk1 for ; Tue, 20 Oct 2015 18:41:10 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E7F1B2C31 for ; Tue, 20 Oct 2015 18:41:10 -0700 (PDT)
Received: by qkca6 with SMTP id a6so16820754qkc.3 for ; Tue, 20 Oct 2015 18:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=0mI+y2qxEJe6m2kCmLPNuEVSCTRtzfN6Hv86t81XXMI=; b=ggvKWgTSgEmuQG0mf07TQvlDg2MYIni2IF5+Z9AStmoWCdM1izY17av68z/BZKHNFB 83BB9N4Itd/SEdUDbgqlGyh4SjdpS8taYGvvcRNFWmlDMHGRpgRl9ipukEDzJ0UaVX0b U0b0WJjUIonRyyXEhn/QowGuXh98VG9ubL8ZvRiP3a6B2YuPwINL7pfpaf4Id6Jw7fX7 TFG+CEsbhxHJKlpbUgfM7Exv6YAt3+AXRDhp9yNBSwFO8APvbQlIiupjd/wpFxYaTgfT iNrXyzk250xPQ96+hG+oZxBtj9TY83Hze4iRyr1AQ1L2bFx4z/5jRKE1TmX9T9e+9l45 ydug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=0mI+y2qxEJe6m2kCmLPNuEVSCTRtzfN6Hv86t81XXMI=; b=S2/pHWop584+sidSDFHbcZFMSqWdw5zu8vwsXc76LOwiTZrM0kVSnlDHIZxVIu0Q7d 66miZadbo8Wv0OX+6Yktkc6OWCRy9IrTEoq/EihOtPqCBCDJK9OJMd86EtodFx/k3j9p Z7g5az2Jm810f1jETP4Pe6a7fu85PoB5tMBtKU7L+FCQCTHe8dtoLp3XgcOsiFWEsINE jhq7CgjQhb3K5LJ+jy7Hs6+VbtEWKyp4+TdTSe0rEfWJg9oZ9KOJnzpWYx59NOT75Rmr pUqIhZT2CHQqPbMx6ViQF8N84tpyvQuhD5s+6yPpiZYSaHHfkEBPRAFczMkRqyG0e3BV 83Ng==
X-Gm-Message-State: ALoCoQkUwuA0NaPNBm0scm1Sj5To3KSz04M5zBoz3tSFfD31tdXvn79+0NNAA2DaDyD/PTIX8NIS
X-Received: by 10.141.23.82 with SMTP id z79mr8408452qhd.39.1445391669269; Tue, 20 Oct 2015 18:41:09 -0700 (PDT)
Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [173.35.15.124]) by smtp.googlemail.com with ESMTPSA id 89sm2376558qgf.43.2015.10.20.18.41.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 18:41:08 -0700 (PDT)
To: "Brzozowski, John" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5626E1C6.8050209@jvknet.com> 
From: Victor Kuarsingh 
Message-ID: <5626ED35.3010607@jvknet.com>
Date: Tue, 20 Oct 2015 21:41:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060702090001000206070002"
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 01:41:13 -0000

This is a multi-part message in MIME format.
--------------060702090001000206070002
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



On 2015-10-20 9:30 PM, Brzozowski, John wrote:
>
> As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks. 
>  The WLAN-GW IPv6 capacity would have to be managed similar to how we 
> manage block sizes for prefix delegation.  The parent IPv6 block would 
> have to be able to a accommodate the overall capacity of the WLAN-GW.
>
Yes, that makes sense.


>
> One more note, the WLAN-GW would only advertise the parent IPv6 block 
> to avoid route table bloat.  Perhaps this should be listed as another 
> operational consideration.
Good point. Text saying that would help to ensure the practice is clear.

regards,

Victor K


>
> John
> +1-484-962-0060
>
> On Oct 20, 2015, at 20:52, Victor Kuarsingh  > wrote:
>
>> John/Gunter,
>>
>> Overall, good draft, well explained case and detailed explanation of 
>> deployment.
>>
>> On to comment...
>>
>> Based on this text .. "The /64
>>    prefix can be derived from a locally managed pool or aggregate IPv6
>>    block assigned to the WLAN-GW or from a pool signalled by the Radius
>>    server in a radius attribute."
>>
>> Its seems clear that the /64s would come from a pool and/or block as 
>> you noted.
>>
>> I would think that under the operational considerations section we 
>> would want to add some text that notes the management requirements to 
>> size/manage those blocks/pools. Under a traditional case, with a /64 
>> per WLAN-GW, the number of addresses that can be consumed by that one 
>> /64 would not require management.
>>
>> However, in this case, it's possible to exhaust the #  of blocks.  If 
>> the WLAN-GW is L3, then in large venues - say stadiums or open areas, 
>> sizing for peak demand periods would need to be considered as well.  
>> Sizing/management is likely not as much of an issue in the "coffee 
>> shop" deployment instance.
>>
>>
>> The text need not be complicated, but should note that some attention 
>> / management is required.
>>
>> regards,
>>
>> Victor K
>>
>>
>>
>>
>> On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:
>>> Posted yesterday. Your comment solicited.
>>>
>>>> Begin forwarded message:
>>>>
>>>> From:internet-drafts@ietf.org
>>>> Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>> Date: October 19, 2015 at 12:50:01 PM PDT
>>>> To:
>>>> Reply-To:internet-drafts@ietf.org
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>         Title           : Unique IPv6 Prefix Per Host
>>>>         Authors         : John Jason Brzozowski
>>>>                           Gunter Van De Velde
>>>> 	Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>> 	Pages           : 14
>>>> 	Date            : 2015-10-19
>>>>
>>>> Abstract:
>>>>    In some IPv6 environments the need has arisen for hosts to be able to
>>>>    utilise a unique IPv6 prefix even though the link or media may be
>>>>    shared.  Typically hosts (subscribers) on a shared network, like Wi-
>>>>    Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
>>>>    prefix that is allocated or assigned for use on a specific link.
>>>>    Benefits of a unique IPv6 prefix compared to a unique IPv6 address
>>>>    from the service provider are going from enhanced subscriber
>>>>    management to improved isolation between subscribers.
>>>>
>>>>    In most deployments today IPv6 address assignment from a single IPv6
>>>>    prefix on a shared network is done by either using IPv6 stateless
>>>>    address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
>>>>    this is still viable and operates as designed there are some large
>>>>    scale environments where this concept introduces significant
>>>>    performance challenges and implications, specifically related to IPv6
>>>>    router and neighbor discovery.  This document outlines an approach
>>>>    utilising existing IPv6 protocols to allow hosts to be assigned a
>>>>    unique IPv6 prefix (instead of a unique IPv6 address from a shared
>>>>    IPv6 prefix).
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-host/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available attools.ietf.org .
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories:http://www.ietf.org/shadow.html
>>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>> _______________________________________________
>>> 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


--------------060702090001000206070002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 2015-10-20 9:30 PM, Brzozowski, John
      wrote:

    

    

      
      


      

      
As an aside I view the WLAN-GW as I
        would a CMTS in DOCSIS networks.  The WLAN-GW IPv6 capacity
        would have to be managed similar to how we manage block sizes
        for prefix delegation.  The parent IPv6 block would have to be
        able to a accommodate the overall capacity of the WLAN-GW.

      


      

    

    Yes, that makes sense.

    

    

    

      


      

      
One more note, the WLAN-GW would only
        advertise the parent IPv6 block to avoid route table bloat.
         Perhaps this should be listed as another operational
        consideration.

      

    

    Good point. Text saying that would help to ensure the practice is
    clear. 

    

    regards,

    

    Victor K

    

    

    

      

        

        John
        
+1-484-962-0060

      

      


        On Oct 20, 2015, at 20:52, Victor Kuarsingh <victor@jvknet.com>
        wrote:

        

      

      

        
John/Gunter,

          

          Overall, good draft, well explained case and detailed
          explanation of deployment.

          

          On to comment...

          

          Based on this text .. "The /64

             prefix can be derived from a locally managed pool or
          aggregate IPv6

             block assigned to the WLAN-GW or from a pool signalled by
          the Radius

             server in a radius attribute."

          

          Its seems clear that the /64s would come from a pool and/or
          block as you noted.  

          

          I would think that under the operational considerations
          section we would want to add some text that notes the
          management requirements to size/manage those blocks/pools. 
          Under a traditional case, with a /64 per WLAN-GW, the number
          of addresses that can be consumed by that one /64 would not
          require management.  

          

          However, in this case, it's possible to exhaust the #  of
          blocks.  If the WLAN-GW is L3, then in large venues - say
          stadiums or open areas, sizing for peak demand periods would
          need to be considered as well.  Sizing/management is likely
          not as much of an issue in the "coffee shop" deployment
          instance.

          

          

          The text need not be complicated, but should note that some
          attention / management is required.

          

          regards,

          

          Victor K

          

          

          

          

          
On 2015-10-20 2:35 PM, Fred Baker
            (fred) wrote:

          

          

            
Posted yesterday. Your comment solicited.



            

              
Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Date: October 19, 2015 at 12:50:01 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


       Title           : Unique IPv6 Prefix Per Host
       Authors         : John Jason Brzozowski
                         Gunter Van De Velde
	Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
	Pages           : 14
	Date            : 2015-10-19

Abstract:
  In some IPv6 environments the need has arisen for hosts to be able to
  utilise a unique IPv6 prefix even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, like Wi-
  Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
  prefix that is allocated or assigned for use on a specific link.
  Benefits of a unique IPv6 prefix compared to a unique IPv6 address
  from the service provider are going from enhanced subscriber
  management to improved isolation between subscribers.

  In most deployments today IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.  This document outlines an approach
  utilising existing IPv6 protocols to allow hosts to be assigned a
  unique IPv6 prefix (instead of a unique IPv6 address from a shared
  IPv6 prefix).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


            

            

            

            

            
_______________________________________________
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

        

      

    

    

  


--------------060702090001000206070002--


From nobody Tue Oct 20 19:50:57 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A651AD21C for ; Tue, 20 Oct 2015 19:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ7YYlaNvrUp for ; Tue, 20 Oct 2015 19:50:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E148C1AD1F5 for ; Tue, 20 Oct 2015 19:50:54 -0700 (PDT)
Received: from mb.local ([172.56.8.215]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9L2olZw076106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2015 02:50:52 GMT (envelope-from joelja@bogus.com)
To: Philip Matthews , Brian E Carpenter 
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca>
From: joel jaeggli 
X-Enigmail-Draft-Status: N1110
Message-ID: <5626FD84.1050101@bogus.com>
Date: Tue, 20 Oct 2015 19:50:44 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gqVW35cfQdLo1pM8AJEDFRFMTAlS2Ecjq"
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 02:50:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gqVW35cfQdLo1pM8AJEDFRFMTAlS2Ecjq
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 10/19/15 2:02 PM, Philip Matthews wrote:
> Brian:
>=20
> What solution would you recommend today to a small-to-medium-sized
> enterprise that cannot get PI space and wants the flexibility to
> easily change providers and possibly multi-home?

PI space usage is actually about attachment costs, not about the ability
or inability to obtain it. it's obtainable but not usable if you favor
low attachment cost.

Enterprises that favor low attachment costs like my home business favor
provider managed address ranges, low friction interaction with cloud
providers, soas for basically applications  and so on);are not going to
place a great deal of value on source ip addresses, because among other
things they aren't very stable; I'm sending this email from a train, my
pan currently has addressing from t-mobile, when I get home that will
change to comcast, the devices at home, which  can reach from here are
still on comcast.  for newly initiated connections source address
selection will tend to favor the network that currently works or if more
than one exists favor the lower cost/faster  one however you choose to
weight that .

> If the enterprise numbers their network internally with PA space,
> then they need to renumber to change providers. Though this is
> definitely easier in IPv6 than IPv4, it is still not "easy".  And
> what about multi-homing?

if you want a genuinly low attachment cost network al la homenet then
renumbering for the purposes of useful source selection needs to be
readily feasible, and fairly transparent. For destination based
multihoming DNS based GTM, health-checking, low ttls  and other features
commonly provided as applications are really the rule of the day today
and that doesn't seem likely to change.

> - Philip
>=20
>=20
> On 2015-10-19, at 16:03 , Brian E Carpenter wrote:
>=20
>>> If ULAs are the only non-Link-Local address available the hosts,
>>> the enterprise will need to use translation technologies such as
>>> NPT[RFC6296] or NAT66 to reach the Internet.
>>=20
>> I think this is still the wrong message. Here's my suggestion:
>>=20
>> The best approach is to use ULAs for internal communications and=20
>> normal IPv6 addresses for external communications. Running
>> multiple addresses in this way is a standard feature of IPv6. If
>> for some reason an enterprise decides to use ULAs as the only
>> non-Link-Local address available to its hosts, the enterprise will
>> also need to use the experimental address prefix technology
>> translation known as NPTv6 [RFC6296] to reach the Internet. Full
>> address translation (known as NAT66) is never needed for IPv6 since
>> there is no address shortage.
>>=20
>> Regards Brian Carpenter
>>=20
>> _______________________________________________ v6ops mailing list=20
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>=20
> _______________________________________________ v6ops mailing list=20
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>=20



--gqVW35cfQdLo1pM8AJEDFRFMTAlS2Ecjq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlYm/YQACgkQ8AA1q7Z/VrLpJwCcCLIiGTwhE9EIulKRCdxouTM2
3YEAn1j9iJA/TX6UIt9dSPGSO47aqZWd
=VrHU
-----END PGP SIGNATURE-----

--gqVW35cfQdLo1pM8AJEDFRFMTAlS2Ecjq--


From nobody Wed Oct 21 03:30:11 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A037B1A21B6 for ; Wed, 21 Oct 2015 03:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.011
X-Spam-Level: 
X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0iVaintbT_q for ; Wed, 21 Oct 2015 03:30:08 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F471A21B5 for ; Wed, 21 Oct 2015 03:30:08 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5A459D7882; Wed, 21 Oct 2015 03:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=8PHM9j/1eiHBHbzSCfS5HoG1Di0=; b= bHXD0oThEpa4+YuXdZMGnKecMIdyrsfyEv3TqKdQVwjaHNF9NLbad5pHttRqWEkf VNUXO4Z33acuYcuCtNHvS9xB8SPnnIs9bvobfkbhsjS8YMbeWuj0sbtPnPRfMkL/ RnV/G6CRCyeDL8P9hcONUCfsqe4UNFLPgzFWNXrO9Lk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=T7maQvTzD6fxKooBpJ7UfCITLN YXjMl8YeygJGZjpCf5/t9pcjJmbajgdYAxtHK5mHdg835VcI/kF7u+yspApngjhR QoZpnmvPUKOpIdLo4FZQYNd0hCJtFz1ySWf47+2k/aGLGz1Df9xgwzxet3lqLcz6 cw2fi6MZK2qlnhFUA=
Received: from h.hanazo.no (unknown [173.38.220.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 1C77ED78A3; Wed, 21 Oct 2015 03:30:06 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 048456E8E87; Wed, 21 Oct 2015 12:30:05 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: multipart/signed; boundary="Apple-Mail=_55B218D0-18D4-478F-818E-069C412DAE82"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Wed, 21 Oct 2015 12:30:04 +0200
Message-Id: <4C481BE7-7301-4750-98D9-4F36EEB094BC@employees.org>
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org>  <562696FF.7040501@gmail.com>  
To: Philip Homburg 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 10:30:09 -0000

--Apple-Mail=_55B218D0-18D4-478F-818E-069C412DAE82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Philip,

> In your letter dated Tue, 20 Oct 2015 22:04:40 +0200 you wrote:
>> indeed. addresses are ephemeral. unfortunately nothing above layer 3 =
has
>> come to terms with that.
>> using address lifetimes as a "routing protocol" is a very bad idea
>> though, in anything but single link networks...
>=20
> It is not a routing protocol. With ingress filtering an address =
becomes
> unavailable when a link goes down because the other link doesn't =
support
> the prefix from which the address was taken.
>=20
> The routing part is (in theory) a trivial extension to most routing =
protocols
> and fibs.
>=20
> Distributing which links are up or down and therefor which prefixes =
are
> available or not is probable something for HNCP (or similar). Though =
in
> setups with a single router, it probably can be done by hand as well.

in that it would try to convey reachability it would be a routing =
protocol.

quick brain dump of the issues I see with it:
 - doesn't work in traditional networks (without HNCP) where you don't =
have a protocol to distribute address lifetimes
 - unclear how it should deal with link flaps
 - only "works" when the directly connected upstream links fails, =
doesn't deal with the plethora of other failures there might be behind =
the first upstream
 - unclear how current implementations deal with it

essentially routing !=3D addressing.

I would posit that it doesn't solve the problem, and that we should =
spend time on solving the problem reasonably completely, instead of =
wasting it on hacks.

cheers,
Ole



--Apple-Mail=_55B218D0-18D4-478F-818E-069C412DAE82
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWJ2ksAAoJEL7aWKiYQt92POAQAI+EkY992kiv0+fj8XHcCOou
uf+YXxARcYTp/V7T5Sk99OhM8PvuOmslGL9f5J5HyAXfeYrXIDa3iFCZ9pGpVcbY
HAhiXbUUk2jMEwp/f6uQye2+ESyWpV86pb/9+nby0maOl0rlYPNfIpHewSUtQuZO
pyHELavEjqOljjGDqTpGjd1eQpfnhP36GV2jQpP+3/Krsj5rMZm/SBwOmLIzcU0d
tGuTboSFos7RRtfrnCtrqxIfeeaR6o2Y6Xa53Osi3bSFHzVHIW3ngfEpM2mAQBeh
RrxtcKY9csUi64o7D4w4Sb15p6jn0mJMrH8BjjYvmV9KBV1Mwy/l8sgDlg/fWugO
OmHz7R8Ey13MxSG1I9D9BaAB1a6IPtnx5ZdRdpNMP/5krohXQVb5y1cZeha5hEXj
knBQmbOI/O9vEUbSeeZ+E2RX5RGju+LzOyXsCkaWlLT5jnBtLrqIahvnPAAb1mC5
qpZ3qFsiSLN+tSEEjJLLApGuv9SzW0qpvW0L4MRV09aKlcpg6pj9aMcYc9p3qHlH
TOOx5s+XufH6OxQRPG4dQFSs2Osposh/5ctae6X+ueqKYclA52+fC5n8hCoifDiE
WHxipZ1xDYqGuYli4OVAg7eNWozabbI3PKfL9ygyPHGVpIxSOl5Klq1oZ95nn/W0
Z/d1uYdvU+grzRmv/EnR
=HkQz
-----END PGP SIGNATURE-----

--Apple-Mail=_55B218D0-18D4-478F-818E-069C412DAE82--


From nobody Wed Oct 21 04:39:08 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6671A904E for ; Wed, 21 Oct 2015 04:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSWe6M0AT3AZ for ; Wed, 21 Oct 2015 04:39:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB561A8ADC for ; Wed, 21 Oct 2015 04:39:04 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZorjS-0000FsC; Wed, 21 Oct 2015 13:39:02 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org>  <562696FF.7040501@gmail.com>   <4C481BE7-7301-4750-98D9-4F36EEB094BC@employees.org> 
In-reply-to: Your message of "Wed, 21 Oct 2015 12:30:04 +0200 ." <4C481BE7-7301-4750-98D9-4F36EEB094BC@employees.org> 
Date: Wed, 21 Oct 2015 13:39:02 +0200
Archived-At: 
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 11:39:06 -0000

>I would posit that it doesn't solve the problem, and that we should 
>spend time on solving the problem reasonably completely, instead of 
>wasting it on hacks.

I think the techincal problems are easy enough to solve. So I'll focus on this
question.

I don't think we can have every small business inject a /48 in BGP. I don't
think ISPs are ready to have a large fraction of their customers bringing
PA space. Let alone do it for almost no extra cost to the customer. So that
option is out, at least for the near future.

At the moment, NAT is quite effective in providing some sort of cheap 
multi-homing for IPv4.

So unless we find a way to provide something better than NAT, people are just
going to implement some kind of NAT for IPv6.

Routing in this context (uplinks to different ISPs, taking into account
source addresses of packets) is mostly a solved problem.

This leaves finding a way to control what source addresses are used. And then
we have a poor man's multi-homing solution.

(DNS is also an issue. I guess all servers are 'in the cloud' these days)



From nobody Wed Oct 21 04:52:05 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833A51A92BC for ; Wed, 21 Oct 2015 04:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkB2RckeCbxg for ; Wed, 21 Oct 2015 04:52:01 -0700 (PDT)
Received: from tor-smtp-05.primus.ca (smtp-auth2-151.primus.ca [216.254.140.151]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB01A9250 for ; Wed, 21 Oct 2015 04:52:01 -0700 (PDT)
Received: from bas5-ottawa10-3096710379.dsl.bell.ca ([184.148.12.235] helo=[10.0.1.16]) by tor-smtp-05.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Zorw0-0003bd-8a; Wed, 21 Oct 2015 07:52:00 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Philip Matthews 
In-Reply-To: <5626FD84.1050101@bogus.com>
Date: Wed, 21 Oct 2015 07:51:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <5626FD84.1050101@bogus.com>
To: joel jaeggli 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - bas5-ottawa10-3096710379.dsl.bell.ca ([10.0.1.16]) [184.148.12.235]
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 11:52:03 -0000

I agree that a business with 1 - 5 employees is likely to go the homenet =
route.

I was thinking of the somewhat larger business of say 70 - 200 =
employees, perhaps 2 or 4 locations, and with internal infrastructure. =
They have a small IT department (perhaps just 1 person), firewalls, =
perhaps VoIP, perhaps an extranet relationships with suppliers or =
partners, etc.

I am not an expert in the Enterprise area, so someone else may correct =
me, but I believe that such companies have not traditionally gotten PI =
space. Today, they would instead get PA space, use private addresses =
internally, and use NAT to avoid the renumbering issue when changing =
providers or to multi-home.

If such a company came to me today and asked "How do I deploy IPv6", =
then I would be reluctant to say "Get PA space from your provider and =
use it internally".  I feel this would be doing them a dis-service.=20

It seems to me that the ideas that Brian mentions might become options =
in the future, but they are still in development and are not something =
that one could recommend to a company today.=20

So right now, i see two options that I could realistically recommend to =
them:
1) Push them to get PI space.  (Would they qualify?  Perhaps someone =
more familiar with RIR policies can comment.)
2) Use ULA space internally and deploy NPT66.

Is there a viable 3rd option that a company could deploy today?

- Philip


On 2015-10-20, at 22:50 , joel jaeggli wrote:

> On 10/19/15 2:02 PM, Philip Matthews wrote:
>> Brian:
>>=20
>> What solution would you recommend today to a small-to-medium-sized
>> enterprise that cannot get PI space and wants the flexibility to
>> easily change providers and possibly multi-home?
>=20
> PI space usage is actually about attachment costs, not about the =
ability
> or inability to obtain it. it's obtainable but not usable if you favor
> low attachment cost.
>=20
> Enterprises that favor low attachment costs like my home business =
favor
> provider managed address ranges, low friction interaction with cloud
> providers, soas for basically applications  and so on);are not going =
to
> place a great deal of value on source ip addresses, because among =
other
> things they aren't very stable; I'm sending this email from a train, =
my
> pan currently has addressing from t-mobile, when I get home that will
> change to comcast, the devices at home, which  can reach from here are
> still on comcast.  for newly initiated connections source address
> selection will tend to favor the network that currently works or if =
more
> than one exists favor the lower cost/faster  one however you choose to
> weight that .
>=20
>> If the enterprise numbers their network internally with PA space,
>> then they need to renumber to change providers. Though this is
>> definitely easier in IPv6 than IPv4, it is still not "easy".  And
>> what about multi-homing?
>=20
> if you want a genuinly low attachment cost network al la homenet then
> renumbering for the purposes of useful source selection needs to be
> readily feasible, and fairly transparent. For destination based
> multihoming DNS based GTM, health-checking, low ttls  and other =
features
> commonly provided as applications are really the rule of the day today
> and that doesn't seem likely to change.
>=20
>> - Philip
>>=20
>>=20
>> On 2015-10-19, at 16:03 , Brian E Carpenter wrote:
>>=20
>>>> If ULAs are the only non-Link-Local address available the hosts,
>>>> the enterprise will need to use translation technologies such as
>>>> NPT[RFC6296] or NAT66 to reach the Internet.
>>>=20
>>> I think this is still the wrong message. Here's my suggestion:
>>>=20
>>> The best approach is to use ULAs for internal communications and=20
>>> normal IPv6 addresses for external communications. Running
>>> multiple addresses in this way is a standard feature of IPv6. If
>>> for some reason an enterprise decides to use ULAs as the only
>>> non-Link-Local address available to its hosts, the enterprise will
>>> also need to use the experimental address prefix technology
>>> translation known as NPTv6 [RFC6296] to reach the Internet. Full
>>> address translation (known as NAT66) is never needed for IPv6 since
>>> there is no address shortage.
>>>=20
>>> Regards Brian Carpenter
>>>=20
>>> _______________________________________________ v6ops mailing list=20=

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


From nobody Wed Oct 21 05:59:32 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218551A6F83 for ; Wed, 21 Oct 2015 05:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.411
X-Spam-Level: 
X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpEbINWTXmwG for ; Wed, 21 Oct 2015 05:59:29 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4D11A6FB9 for ; Wed, 21 Oct 2015 05:59:21 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D64FDD7886; Wed, 21 Oct 2015 05:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=NUmBajGzW/u7Vdt5Q6nKijob940=; b= oszzZy12XNv4UpP1WfqujO5pjFZcrY/Ppr5O6wuPs6k3Z3lDp9DE8tERyGAmj5KY /ofUZpzar3kgcrac3Wyt0ogo9xEdCx0Zld21E5uqznjFCpwfYxGwzf9GIwKMHLzx i93dOv30Xb2N+OwvHM4WjFsB8nNZ9G/VgCgzfmUOYTk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=i6ameYgcyJA2SBZthThrwNeFHu A6L6k7npuVwlr8j9Ir9kgO+DoS4B9+s+YakQH1t/yd+nfFUlUaZEiYZbStsL/0Mz uH1HMdwrEsoQ9IdRKXIcaE4MkS2A3OEVj0TxId1AmDuPVmREhnGySAr9Wej8tES9 MpHaJ3EDadIyCU9po=
Received: from h.hanazo.no (unknown [173.38.220.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 99032D7882; Wed, 21 Oct 2015 05:59:19 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5FE3A6EC2CA; Wed, 21 Oct 2015 14:59:18 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: multipart/signed; boundary="Apple-Mail=_EA922AF0-07E8-4B41-BCA4-73843FE5B18E"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Wed, 21 Oct 2015 14:59:17 +0200
Message-Id: 
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org>  <562696FF.7040501@gmail.com>   <4C481BE7-7301-4750-98D9-4F36EEB094BC@employees.org> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 12:59:31 -0000

--Apple-Mail=_EA922AF0-07E8-4B41-BCA4-73843FE5B18E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Philip,

>> I would posit that it doesn't solve the problem, and that we should
>> spend time on solving the problem reasonably completely, instead of
>> wasting it on hacks.
>=20
> I think the techincal problems are easy enough to solve. So I'll focus =
on this
> question.

I don't think there was a question there. ;-)

for IPv6 multi-prefix multi-homing you have to significantly change your =
thinking away from the type of "site-multihoming" we do for IPv4. with =
MHMP the host is in control. sure, the network can offer some help, in =
indicating that something is amiss with ICMP messages, but where the =
rubber hits the road is at the host.

in MHMP the host is of course in a much better position to make sensible =
choices among it's set of candidate SA,DA pairs than what the network =
is. but we need the host to essentially fulfil the goals of RFC3582.

while you might not think the technical issues are hard, although I =
encourage you to read the source code of MOSH and MP-TCP, there is a big =
implementation gap and deployment problem here.

cheers,
Ole

--Apple-Mail=_EA922AF0-07E8-4B41-BCA4-73843FE5B18E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWJ4wmAAoJEL7aWKiYQt92hgQQAK70rQ3o9N683Q7E+3yRNKNP
emc3qS+VlxKqY6w3+OYWkEMydO2CW0PTMrXwZE6KszlCs56NTRArzITuQLcabOg5
ofDWM+WAiJ9brexw/U6lHJfxVYqvqzDv41jlCkZEav1gQvpCkO87ir981DnSwBga
Ei4y1WiOdy4FcrXHIANEX1YzVa8pcCloJJEOzS5XACNcbuqEfocD4scTOlssP8mE
EJH7/4adqoFllfPD7qJzdzwZzk/g+mWcLcMEv5azOM4oHlO9ZI89Judi5Pw1i9pJ
C5Cq3TLc8O7hFw/CJgskZHJclm4Ya0ZA6SLEx34EY9EkFuXsZeFYsl3YJZFYhys0
QMostf5RiHln8Qq54lcoROKno5ydF6cWKaUmPyhaRt8yhCh7BybbM9RsLkiwTv6e
N6SQ6stjm5b3yWB45xM933gL2DhAX0bJGwtBpQsEv0i4os2THlBrLqQB4I8NxMi+
5DHtb+8OaxvMRHPXCeKrHKZEbOv21rNyUEXTp/mQXTVHC219cB9RvWpZkaCTkAP/
emwndkZ88xdbKLTEsC/FTUBjMFsRhyUGojQi5NQK+9qP+Ikr/rqvm74dcCTjDcx3
l4gPlxDOFa7Q+zO0JIumfRe7i5PkUUACMzt08eG1yu2m0daux78C21/pKAuj8B0j
u3CUe98kvoS3lQAEksY5
=YIT0
-----END PGP SIGNATURE-----

--Apple-Mail=_EA922AF0-07E8-4B41-BCA4-73843FE5B18E--


From nobody Wed Oct 21 06:16:46 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87691A6FFB for ; Wed, 21 Oct 2015 06:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VxR7wFYLxmg for ; Wed, 21 Oct 2015 06:16:40 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8455D1A6FFD for ; Wed, 21 Oct 2015 06:16:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZotFs-0000HDC; Wed, 21 Oct 2015 15:16:36 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <56258D8D.2010702@gmail.com> <0CC12E67-C9FB-4AC3-8E2F-5482BB942688@employees.org>  <562696FF.7040501@gmail.com>   <4C481BE7-7301-4750-98D9-4F36EEB094BC@employees.org>   
In-reply-to: Your message of "Wed, 21 Oct 2015 14:59:17 +0200 ."  
Date: Wed, 21 Oct 2015 15:16:33 +0200
Archived-At: 
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 13:16:45 -0000

In your letter dated Wed, 21 Oct 2015 14:59:17 +0200 you wrote:
>while you might not think the technical issues are hard, although I 
>encourage you to read the source code of MOSH and MP-TCP, there is a big 
>implementation gap and deployment problem here.

I'm not trying deal with Section 3.1.6 of RFC-3582. In a 'traditional'
IPv4 context with multi-homing and NAT this doesn't work. IPv6 with NAT
would also not satisfy the transport layer transparency.

Note that both mosh and mptcp have problems that are non-local. Mosh because it
is yet another security protocol that needs to be validated and deployed.
Mptcp because too many middle boxes destroy end-to-end transparency of the
internet. And of course, mptcp also needs to be deployed.

In contrast, playing with the preferred lifetime of prefixes is completely
local to a site.



From nobody Wed Oct 21 07:38:35 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91991A9078 for ; Wed, 21 Oct 2015 07:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdU0Kfi2XB9z for ; Wed, 21 Oct 2015 07:38:29 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FABD1A9073 for ; Wed, 21 Oct 2015 07:38:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9LEcSAh003557; Wed, 21 Oct 2015 07:38:28 -0700
Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9LEcPHf003483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 21 Oct 2015 07:38:25 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.143]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 07:38:24 -0700
From: "Templin, Fred L" 
To: "Brzozowski, John" , Victor Kuarsingh 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRC5rO/+MZsnq7pUCTitCxpFGwKp51nmYAgABlGtA=
Date: Wed, 21 Oct 2015 14:38:23 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2AE10@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>, <5626E1C6.8050209@jvknet.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F2AE10XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 14:38:34 -0000

--_000_2134F8430051B64F815C691A62D9831832F2AE10XCHBLV504nwnosb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, what this draft is discussing is already covered in AERO, where DHCPv6 =
PD is
used to delegate a unique IPv6 prefix per host. Please refer to that docume=
nt:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

AERO has been presented at the past 4 IETFs in the dmm working group
(charts available in proceedings). From some of the recent discussions on
multi-addressing and prefix delegation it sounds like it should also be
presented in v6ops.

Thanks - Fred
fred.l.templin@boeing.com

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brzozowski, John
Sent: Tuesday, October 20, 2015 6:31 PM
To: Victor Kuarsingh
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-p=
er-host-00.txt

Thanks Victor.  I will confer with Gunter on some text.

As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks.  The W=
LAN-GW IPv6 capacity would have to be managed similar to how we manage bloc=
k sizes for prefix delegation.  The parent IPv6 block would have to be able=
 to a accommodate the overall capacity of the WLAN-GW.

Once a WLAN-GW reaches capacity either from a bandwidth point of view, IPv6=
 prefixes, etc. the WLAN-GW split would need to occur.

One more note, the WLAN-GW would only advertise the parent IPv6 block to av=
oid route table bloat.  Perhaps this should be listed as another operationa=
l consideration.

John
+1-484-962-0060

On Oct 20, 2015, at 20:52, Victor Kuarsingh > wrote:
John/Gunter,

Overall, good draft, well explained case and detailed explanation of deploy=
ment.

On to comment...

Based on this text .. "The /64
   prefix can be derived from a locally managed pool or aggregate IPv6
   block assigned to the WLAN-GW or from a pool signalled by the Radius
   server in a radius attribute."

Its seems clear that the /64s would come from a pool and/or block as you no=
ted.

I would think that under the operational considerations section we would wa=
nt to add some text that notes the management requirements to size/manage t=
hose blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the n=
umber of addresses that can be consumed by that one /64 would not require m=
anagement.

However, in this case, it's possible to exhaust the #  of blocks.  If the W=
LAN-GW is L3, then in large venues - say stadiums or open areas, sizing for=
 peak demand periods would need to be considered as well.  Sizing/managemen=
t is likely not as much of an issue in the "coffee shop" deployment instanc=
e.


The text need not be complicated, but should note that some attention / man=
agement is required.

regards,

Victor K



On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:

Posted yesterday. Your comment solicited.



Begin forwarded message:



From: internet-drafts@ietf.org

Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

Date: October 19, 2015 at 12:50:01 PM PDT

To: 

Reply-To: internet-drafts@ietf.org





A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





       Title           : Unique IPv6 Prefix Per Host

       Authors         : John Jason Brzozowski

                         Gunter Van De Velde

    Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

    Pages           : 14

    Date            : 2015-10-19



Abstract:

  In some IPv6 environments the need has arisen for hosts to be able to

  utilise a unique IPv6 prefix even though the link or media may be

  shared.  Typically hosts (subscribers) on a shared network, like Wi-

  Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6

  prefix that is allocated or assigned for use on a specific link.

  Benefits of a unique IPv6 prefix compared to a unique IPv6 address

  from the service provider are going from enhanced subscriber

  management to improved isolation between subscribers.



  In most deployments today IPv6 address assignment from a single IPv6

  prefix on a shared network is done by either using IPv6 stateless

  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While

  this is still viable and operates as designed there are some large

  scale environments where this concept introduces significant

  performance challenges and implications, specifically related to IPv6

  router and neighbor discovery.  This document outlines an approach

  utilising existing IPv6 protocols to allow hosts to be assigned a

  unique IPv6 prefix (instead of a unique IPv6 address from a shared

  IPv6 prefix).





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-ho=
st/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




_______________________________________________

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

--_000_2134F8430051B64F815C691A62D9831832F2AE10XCHBLV504nwnosb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi, what this draft is discussing is =
already covered in AERO, where DHCPv6 PD is


used to delegate a unique IPv6 prefix=
 per host. Please refer to that document:


 


https://datatracker.ietf.org/doc/draft-temp=
lin-aerolink/


 


AERO has been presented at the past 4=
 IETFs in the dmm working group


(charts available in proceedings). Fr=
om some of the recent discussions on


multi-addressing and prefix delegatio=
n it sounds like it should also be


presented in v6ops.=



 


Thanks – Fred=



fred.l.templin@boeing.com<=
/span>


 








From: v6ops [mailto:v6ops-bounces@ie=
tf.org]
On Behalf Of Brzozowski, John

Sent: Tuesday, October 20, 2015 6:31 PM

To: Victor Kuarsingh

Cc: v6ops@ietf.org

Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-p=
refix-per-host-00.txt






 




Thanks Victor.  I will confer with Gunter on so=
me text.






 






As an aside I view the WLAN-GW as I would a CMTS in =
DOCSIS networks.  The WLAN-GW IPv6 capacity would have to be managed s=
imilar to how we manage block sizes for prefix delegation.  The parent=
 IPv6 block would have to be able to a accommodate
 the overall capacity of the WLAN-GW.






 






Once a WLAN-GW reaches capacity either from a bandwi=
dth point of view, IPv6 prefixes, etc. the WLAN-GW split would need to occu=
r.






 






One more note, the WLAN-GW would only advertise the =
parent IPv6 block to avoid route table bloat.  Perhaps this should be =
listed as another operational consideration.



John 




+1-484-962-0060=











On Oct 20, 2015, at 20:52, Victor Kuarsingh <victor@jvknet.com> wrote:








John/Gunter,



Overall, good draft, well explained case and detailed explanation of deploy=
ment.



On to comment...



Based on this text .. "The /64

   prefix can be derived from a locally managed pool or aggregate=
 IPv6

   block assigned to the WLAN-GW or from a pool signalled by the =
Radius

   server in a radius attribute."



Its seems clear that the /64s would come from a pool and/or block as you no=
ted.  



I would think that under the operational considerations section we would wa=
nt to add some text that notes the management requirements to size/manage t=
hose blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, =
the number of addresses that can be consumed
 by that one /64 would not require management.  



However, in this case, it's possible to exhaust the #  of blocks. =
; If the WLAN-GW is L3, then in large venues - say stadiums or open areas, =
sizing for peak demand periods would need to be considered as well.  S=
izing/management is likely not as much of an issue
 in the "coffee shop" deployment instance.





The text need not be complicated, but should note that some attention / man=
agement is required.



regards,



Victor K












On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:=







Posted yesterday. Your comment solicited.


 




Begin forwarded message:


 


From: internet-drafts@ietf=
.org


Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.t=
xt


Date: October 19, 2015 at 12:50:01 PM PDT


To: <i-d-announce@ietf.org=
>


Reply-To: internet-drafts@=
ietf.org


 


 


A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


 


 


       Title    &nbs=
p;      : Unique IPv6 Prefix Per Host

       Authors    &n=
bsp;    : John Jason Brzozowski


           &nbs=
p;             =
Gunter Van De Velde


    Filename        =
: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt


    Pages       &nbs=
p;   : 14


    Date        =
;    : 2015-10-19


 


Abstract:


  In some IPv6 environments the need has arisen for hosts to be a=
ble to


  utilise a unique IPv6 prefix even though the link or media may =
be


  shared.  Typically hosts (subscribers) on a shared network=
, like Wi-


  Fi or Ethernet, will acquire unique IPv6 addresses from a commo=
n IPv6


  prefix that is allocated or assigned for use on a specific link=
.


  Benefits of a unique IPv6 prefix compared to a unique IPv6 addr=
ess


  from the service provider are going from enhanced subscriber


  management to improved isolation between subscribers.


 


  In most deployments today IPv6 address assignment from a single=
 IPv6


  prefix on a shared network is done by either using IPv6 statele=
ss


  address auto-configuration (SLAAC) and/or stateful DHCPv6. =
; While


  this is still viable and operates as designed there are some la=
rge


  scale environments where this concept introduces significant


  performance challenges and implications, specifically related t=
o IPv6


  router and neighbor discovery.  This document outlines an =
approach


  utilising existing IPv6 protocols to allow hosts to be assigned=
 a


  unique IPv6 prefix (instead of a unique IPv6 address from a sha=
red


  IPv6 prefix).


 


 


The IETF datatracker status page for this draft is:


https://datatracker.ietf.org/doc/draft-jjmb-v6ops-uniq=
ue-ipv6-prefix-per-host/


 


There's also a htmlized version available at:


https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-=
prefix-per-host-00


 


 


Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.


 


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-drafts/


 


_______________________________________________


I-D-Announce mailing list


I-D-Announce@ietf.org


https:/=
/www.ietf.org/mailman/listinfo/i-d-announce


Internet-Draft directories: http://www.ietf.org/shadow.html


or ftp://ftp.iet=
f.org/ietf/1shadow-sites.txt













_______________________________________________


v6ops mailing list


v6ops@ietf.org


https://www.ie=
tf.org/mailman/listinfo/v6ops




 










_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.or=
g/mailman/listinfo/v6ops












--_000_2134F8430051B64F815C691A62D9831832F2AE10XCHBLV504nwnosb_--


From nobody Wed Oct 21 08:45:55 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A211A9132 for ; Wed, 21 Oct 2015 08:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level: 
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3VLmmoILuTx for ; Wed, 21 Oct 2015 08:45:47 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F63E1A9123 for ; Wed, 21 Oct 2015 08:45:43 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-5f-5627b326a326
Received: from PACDCEXHUB01.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 92.9C.04607.623B7265; Wed, 21 Oct 2015 11:45:42 -0400 (EDT)
Received: from PACDCEX48.cable.comcast.com (24.40.2.147) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 21 Oct 2015 11:45:33 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX48.cable.comcast.com (24.40.2.147) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 21 Oct 2015 11:45:32 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Wed, 21 Oct 2015 11:45:32 -0400
From: "Brzozowski, John" 
To: "Templin, Fred L" , Victor Kuarsingh 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRC5rNn1oaXPpdb0m/H+tIWUdOwp51KQ4XgAEfEID//8+zAA==
Date: Wed, 21 Oct 2015 15:45:31 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5626E1C6.8050209@jvknet.com>  <2134F8430051B64F815C691A62D9831832F2AE10@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F2AE10@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.10]
Content-Type: multipart/alternative; boundary="_000_D24D2A7F18D07Bjohnbrzozowskicablecomcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42JxCVeS0VXbrB5mcHe2rMX5U1NYLE4f28ts cX3xY1YHZo/fB98weyxZ8pPJ4++zM+wBzFFcNimpOZllqUX6dglcGXub3zEXvGthqjj1cQlT A+P/v4xdjJwcEgImEj2XV7BC2GISF+6tZ+ti5OIQEtjFJNHT3MkC4exllJh8ppkdwtnNKDH7 /Q0mCOcko8TWLY+ZQfrZBGwkXn/4CTZXRCBS4sbS6UBFHBzMAqoSs//wg4SFBaIldmzpZ4Mo iZGY9aKRCcJ2krj5ZD0LiM0CVH5z/zY2kFZeAXuJN+9NIFbNZJJ4smwGO0icUyBUYvt5JZBy RqCrv59aAzaGWUBc4taT+UwQ3whILNlznhnCFpV4+fgf2JeiAnoS7af+s0HEDSS2Lt3HAmHL SxyZ8I8FYk6yxKPli8BqeAUEJU7OfMICslYIqHfeA2mIcnGJw0d2sE5glJ6FZPMsJN2zkHTP AoeDpsT6XfoQJYoSU7ofskPYGhKtc+ZC2Q4SL5auYUFWs4CRYxWjXEFickpybkZ+aYmBoV5y YlJOql5yfm5yYnEJiN7ECE4f8st3MN574XSIUYCDUYmH994y9TAh1sSy4srcQ4wSHMxKIrwl G4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeTff+xUqJJCeWJKanZpakFoEk2Xi4JRqYGTdbbz0 UsJnxrk2nOpOpb/kcg31jphuOpHf3KfVazlp4pmpdzpMff7OP/X3URLTZqV7Gx6ysnmFNfHN 0tT5NP3Lz6m7ngR71/y5EPPT5OGuf456n5jEBbYfinm/+7OH057fb0JVWDR4zq28OuHjBIdO h7MWV51DRCTmT77GXSedxiLIMf3FnYdKLMUZiYZazEXFiQDdOroHGwMAAA==
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 15:45:49 -0000

--_000_D24D2A7F18D07Bjohnbrzozowskicablecomcastcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RnJlZCwNCg0KUmVwbHlpbmcgaGVyZSBpbnN0ZWFkIG9mIG9mZiBsaXN0LiAgSSB0b29rIGEgcXVp
Y2sgbG9vayBhdCB0aGUgZHJhZnQgYW5kIGFkbWl0IHRoZXJlIGFyZSBzb21lIGFzcGVjdHMgb2Yg
dGhlIGRyYWZ0IHRoYXQgc2VlbSBzaW1pbGFyIHRvIHdoYXQgd2UgaGF2ZSBkb25lLiAgSG93ZXZl
ciwgdGhlcmUgaXMgYSBsb3QgbW9yZSB0byBBRVJPIHRoYW4gd2hhdCB3ZSBuZWVkLiAgV2UgdXRp
bGl6ZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRldmVsb3BlZCBubyBleHRlbnNpb25zIHRvIHRo
ZSBzYW1lLCB0aGVyZSBzZWVtcyB0byBiZSBzb21lIG5ldyBkZXZlbG9wbWVudCByZWxhdGVkIHRv
IEFFUk8uDQoNCk91ciBhcHByb2FjaCBmb3IgUEQsIHdoaWNoIGlzIGEgZnV0dXJlcyBpdGVtIGlz
IGJhc2ljYWxseSB3aGF0IHdlIGtub3cgdG9kYXkgZm9yIFBELCBSRkMzNjMzLiAgV2Ugc2F3IG5v
IG5lZWQgdG8gcmVpbnZlbnQgdGhlIHdoZWVsIG5vciBkbyB3ZSBpbnRlbmQgdG8uDQoNCkkgbG9v
ayBmb3J3YXJkIHRvIGhlYXJpbmcgbW9yZSBhYm91dCBBRVJPLCBpdHMgdXNlIGNhc2VzLCBhbmQg
YXZhaWxhYmxlIGltcGxlbWVudGF0aW9ucyBpbiBZb2tvaGFtYS4NCg0KSm9obg0KKzEtNDg0LTk2
Mi0wMDYwDQoNCkZyb206IEZyZWQgVGVtcGxpbiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt
YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9i
ZXIgMjEsIDIwMTUgYXQgMTA6MzgNClRvOiBKb2huIEphc29uIEJyem96b3dza2kgPGpvaG5fYnJ6
b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbTxtYWlsdG86am9obl9icnpvem93c2tpQGNhYmxlLmNv
bWNhc3QuY29tPj4sIFZpY3RvciBLdWFyc2luZ2ggPHZpY3RvckBqdmtuZXQuY29tPG1haWx0bzp2
aWN0b3JAanZrbmV0LmNvbT4+DQpDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9w
c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0
LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KDQpIaSwgd2hh
dCB0aGlzIGRyYWZ0IGlzIGRpc2N1c3NpbmcgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIEFFUk8sIHdo
ZXJlIERIQ1B2NiBQRCBpcw0KdXNlZCB0byBkZWxlZ2F0ZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBw
ZXIgaG9zdC4gUGxlYXNlIHJlZmVyIHRvIHRoYXQgZG9jdW1lbnQ6DQoNCmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4tYWVyb2xpbmsvDQoNCkFFUk8gaGFzIGJl
ZW4gcHJlc2VudGVkIGF0IHRoZSBwYXN0IDQgSUVURnMgaW4gdGhlIGRtbSB3b3JraW5nIGdyb3Vw
DQooY2hhcnRzIGF2YWlsYWJsZSBpbiBwcm9jZWVkaW5ncykuIEZyb20gc29tZSBvZiB0aGUgcmVj
ZW50IGRpc2N1c3Npb25zIG9uDQptdWx0aS1hZGRyZXNzaW5nIGFuZCBwcmVmaXggZGVsZWdhdGlv
biBpdCBzb3VuZHMgbGlrZSBpdCBzaG91bGQgYWxzbyBiZQ0KcHJlc2VudGVkIGluIHY2b3BzLg0K
DQpUaGFua3Mg4oCTIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOmZyZWQu
bC50ZW1wbGluQGJvZWluZy5jb20+DQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyem96b3dza2ksIEpvaG4NClNlbnQ6IFR1ZXNkYXks
IE9jdG9iZXIgMjAsIDIwMTUgNjozMSBQTQ0KVG86IFZpY3RvciBLdWFyc2luZ2gNCkNjOiB2Nm9w
c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBG
d2Q6IEktRCBBY3Rpb246IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o
b3N0LTAwLnR4dA0KDQpUaGFua3MgVmljdG9yLiAgSSB3aWxsIGNvbmZlciB3aXRoIEd1bnRlciBv
biBzb21lIHRleHQuDQoNCkFzIGFuIGFzaWRlIEkgdmlldyB0aGUgV0xBTi1HVyBhcyBJIHdvdWxk
IGEgQ01UUyBpbiBET0NTSVMgbmV0d29ya3MuICBUaGUgV0xBTi1HVyBJUHY2IGNhcGFjaXR5IHdv
dWxkIGhhdmUgdG8gYmUgbWFuYWdlZCBzaW1pbGFyIHRvIGhvdyB3ZSBtYW5hZ2UgYmxvY2sgc2l6
ZXMgZm9yIHByZWZpeCBkZWxlZ2F0aW9uLiAgVGhlIHBhcmVudCBJUHY2IGJsb2NrIHdvdWxkIGhh
dmUgdG8gYmUgYWJsZSB0byBhIGFjY29tbW9kYXRlIHRoZSBvdmVyYWxsIGNhcGFjaXR5IG9mIHRo
ZSBXTEFOLUdXLg0KDQpPbmNlIGEgV0xBTi1HVyByZWFjaGVzIGNhcGFjaXR5IGVpdGhlciBmcm9t
IGEgYmFuZHdpZHRoIHBvaW50IG9mIHZpZXcsIElQdjYgcHJlZml4ZXMsIGV0Yy4gdGhlIFdMQU4t
R1cgc3BsaXQgd291bGQgbmVlZCB0byBvY2N1ci4NCg0KT25lIG1vcmUgbm90ZSwgdGhlIFdMQU4t
R1cgd291bGQgb25seSBhZHZlcnRpc2UgdGhlIHBhcmVudCBJUHY2IGJsb2NrIHRvIGF2b2lkIHJv
dXRlIHRhYmxlIGJsb2F0LiAgUGVyaGFwcyB0aGlzIHNob3VsZCBiZSBsaXN0ZWQgYXMgYW5vdGhl
ciBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9uLg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0K
T24gT2N0IDIwLCAyMDE1LCBhdCAyMDo1MiwgVmljdG9yIEt1YXJzaW5naCA8dmljdG9yQGp2a25l
dC5jb208bWFpbHRvOnZpY3RvckBqdmtuZXQuY29tPj4gd3JvdGU6DQpKb2huL0d1bnRlciwNCg0K
T3ZlcmFsbCwgZ29vZCBkcmFmdCwgd2VsbCBleHBsYWluZWQgY2FzZSBhbmQgZGV0YWlsZWQgZXhw
bGFuYXRpb24gb2YgZGVwbG95bWVudC4NCg0KT24gdG8gY29tbWVudC4uLg0KDQpCYXNlZCBvbiB0
aGlzIHRleHQgLi4gIlRoZSAvNjQNCiAgIHByZWZpeCBjYW4gYmUgZGVyaXZlZCBmcm9tIGEgbG9j
YWxseSBtYW5hZ2VkIHBvb2wgb3IgYWdncmVnYXRlIElQdjYNCiAgIGJsb2NrIGFzc2lnbmVkIHRv
IHRoZSBXTEFOLUdXIG9yIGZyb20gYSBwb29sIHNpZ25hbGxlZCBieSB0aGUgUmFkaXVzDQogICBz
ZXJ2ZXIgaW4gYSByYWRpdXMgYXR0cmlidXRlLiINCg0KSXRzIHNlZW1zIGNsZWFyIHRoYXQgdGhl
IC82NHMgd291bGQgY29tZSBmcm9tIGEgcG9vbCBhbmQvb3IgYmxvY2sgYXMgeW91IG5vdGVkLg0K
DQpJIHdvdWxkIHRoaW5rIHRoYXQgdW5kZXIgdGhlIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25z
IHNlY3Rpb24gd2Ugd291bGQgd2FudCB0byBhZGQgc29tZSB0ZXh0IHRoYXQgbm90ZXMgdGhlIG1h
bmFnZW1lbnQgcmVxdWlyZW1lbnRzIHRvIHNpemUvbWFuYWdlIHRob3NlIGJsb2Nrcy9wb29scy4g
IFVuZGVyIGEgdHJhZGl0aW9uYWwgY2FzZSwgd2l0aCBhIC82NCBwZXIgV0xBTi1HVywgdGhlIG51
bWJlciBvZiBhZGRyZXNzZXMgdGhhdCBjYW4gYmUgY29uc3VtZWQgYnkgdGhhdCBvbmUgLzY0IHdv
dWxkIG5vdCByZXF1aXJlIG1hbmFnZW1lbnQuDQoNCkhvd2V2ZXIsIGluIHRoaXMgY2FzZSwgaXQn
cyBwb3NzaWJsZSB0byBleGhhdXN0IHRoZSAjICBvZiBibG9ja3MuICBJZiB0aGUgV0xBTi1HVyBp
cyBMMywgdGhlbiBpbiBsYXJnZSB2ZW51ZXMgLSBzYXkgc3RhZGl1bXMgb3Igb3BlbiBhcmVhcywg
c2l6aW5nIGZvciBwZWFrIGRlbWFuZCBwZXJpb2RzIHdvdWxkIG5lZWQgdG8gYmUgY29uc2lkZXJl
ZCBhcyB3ZWxsLiAgU2l6aW5nL21hbmFnZW1lbnQgaXMgbGlrZWx5IG5vdCBhcyBtdWNoIG9mIGFu
IGlzc3VlIGluIHRoZSAiY29mZmVlIHNob3AiIGRlcGxveW1lbnQgaW5zdGFuY2UuDQoNCg0KVGhl
IHRleHQgbmVlZCBub3QgYmUgY29tcGxpY2F0ZWQsIGJ1dCBzaG91bGQgbm90ZSB0aGF0IHNvbWUg
YXR0ZW50aW9uIC8gbWFuYWdlbWVudCBpcyByZXF1aXJlZC4NCg0KcmVnYXJkcywNCg0KVmljdG9y
IEsNCg0KDQoNCk9uIDIwMTUtMTAtMjAgMjozNSBQTSwgRnJlZCBCYWtlciAoZnJlZCkgd3JvdGU6
DQoNClBvc3RlZCB5ZXN0ZXJkYXkuIFlvdXIgY29tbWVudCBzb2xpY2l0ZWQuDQoNCg0KDQpCZWdp
biBmb3J3YXJkZWQgbWVzc2FnZToNCg0KDQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBJLUQgQWN0aW9u
OiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCg0K
RGF0ZTogT2N0b2JlciAxOSwgMjAxNSBhdCAxMjo1MDowMSBQTSBQRFQNCg0KVG86IDxpLWQtYW5u
b3VuY2VAaWV0Zi5vcmc+PG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQoNClJlcGx5LVRv
OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
Zz4NCg0KDQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg
b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCg0KDQoNCg0KICAgICAgIFRp
dGxlICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdA0KDQogICAgICAgQXV0
aG9ycyAgICAgICAgIDogSm9obiBKYXNvbiBCcnpvem93c2tpDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICBHdW50ZXIgVmFuIERlIFZlbGRlDQoNCiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFm
dC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCg0KICAgIFBh
Z2VzICAgICAgICAgICA6IDE0DQoNCiAgICBEYXRlICAgICAgICAgICAgOiAyMDE1LTEwLTE5DQoN
Cg0KDQpBYnN0cmFjdDoNCg0KICBJbiBzb21lIElQdjYgZW52aXJvbm1lbnRzIHRoZSBuZWVkIGhh
cyBhcmlzZW4gZm9yIGhvc3RzIHRvIGJlIGFibGUgdG8NCg0KICB1dGlsaXNlIGEgdW5pcXVlIElQ
djYgcHJlZml4IGV2ZW4gdGhvdWdoIHRoZSBsaW5rIG9yIG1lZGlhIG1heSBiZQ0KDQogIHNoYXJl
ZC4gIFR5cGljYWxseSBob3N0cyAoc3Vic2NyaWJlcnMpIG9uIGEgc2hhcmVkIG5ldHdvcmssIGxp
a2UgV2ktDQoNCiAgRmkgb3IgRXRoZXJuZXQsIHdpbGwgYWNxdWlyZSB1bmlxdWUgSVB2NiBhZGRy
ZXNzZXMgZnJvbSBhIGNvbW1vbiBJUHY2DQoNCiAgcHJlZml4IHRoYXQgaXMgYWxsb2NhdGVkIG9y
IGFzc2lnbmVkIGZvciB1c2Ugb24gYSBzcGVjaWZpYyBsaW5rLg0KDQogIEJlbmVmaXRzIG9mIGEg
dW5pcXVlIElQdjYgcHJlZml4IGNvbXBhcmVkIHRvIGEgdW5pcXVlIElQdjYgYWRkcmVzcw0KDQog
IGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgYXJlIGdvaW5nIGZyb20gZW5oYW5jZWQgc3Vic2Ny
aWJlcg0KDQogIG1hbmFnZW1lbnQgdG8gaW1wcm92ZWQgaXNvbGF0aW9uIGJldHdlZW4gc3Vic2Ny
aWJlcnMuDQoNCg0KDQogIEluIG1vc3QgZGVwbG95bWVudHMgdG9kYXkgSVB2NiBhZGRyZXNzIGFz
c2lnbm1lbnQgZnJvbSBhIHNpbmdsZSBJUHY2DQoNCiAgcHJlZml4IG9uIGEgc2hhcmVkIG5ldHdv
cmsgaXMgZG9uZSBieSBlaXRoZXIgdXNpbmcgSVB2NiBzdGF0ZWxlc3MNCg0KICBhZGRyZXNzIGF1
dG8tY29uZmlndXJhdGlvbiAoU0xBQUMpIGFuZC9vciBzdGF0ZWZ1bCBESENQdjYuICBXaGlsZQ0K
DQogIHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCB0aGVyZSBh
cmUgc29tZSBsYXJnZQ0KDQogIHNjYWxlIGVudmlyb25tZW50cyB3aGVyZSB0aGlzIGNvbmNlcHQg
aW50cm9kdWNlcyBzaWduaWZpY2FudA0KDQogIHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGlt
cGxpY2F0aW9ucywgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2Ng0KDQogIHJvdXRlciBhbmQg
bmVpZ2hib3IgZGlzY292ZXJ5LiAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaA0K
DQogIHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scyB0byBhbGxvdyBob3N0cyB0byBi
ZSBhc3NpZ25lZCBhDQoNCiAgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGEgdW5pcXVl
IElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVkDQoNCiAgSVB2NiBwcmVmaXgpLg0KDQoNCg0KDQoN
ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KDQpo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p
cHY2LXByZWZpeC1wZXItaG9zdC8NCg0KDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp
b24gYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtampt
Yi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDANCg0KDQoNCg0KDQpQbGVhc2Ug
bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv
ZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh
dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KDQoN
CkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
Cg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkktRC1Bbm5vdW5jZSBtYWls
aW5nIGxpc3QNCg0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0
Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91
bmNlDQoNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3No
YWRvdy5odG1sDQoNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0
DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNCnY2b3BzIG1haWxpbmcgbGlzdA0KDQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0
Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1h
aWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K

--_000_D24D2A7F18D07Bjohnbrzozowskicablecomcastcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <04DF5A1DDD76214A9FFBC4D21FD97056@cable.comcast.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
OHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PkZyZWQsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZXBseWluZyBoZXJlIGlu
c3RlYWQgb2Ygb2ZmIGxpc3QuICZuYnNwO0kgdG9vayBhIHF1aWNrIGxvb2sgYXQgdGhlIGRyYWZ0
IGFuZCBhZG1pdCB0aGVyZSBhcmUgc29tZSBhc3BlY3RzIG9mIHRoZSBkcmFmdCB0aGF0IHNlZW0g
c2ltaWxhciB0byB3aGF0IHdlIGhhdmUgZG9uZS4gJm5ic3A7SG93ZXZlciwgdGhlcmUgaXMgYSBs
b3QgbW9yZSB0byBBRVJPIHRoYW4gd2hhdCB3ZSBuZWVkLiAmbmJzcDtXZSB1dGlsaXplIGV4aXN0
aW5nIHByb3RvY29scyBhbmQgZGV2ZWxvcGVkDQogbm8gZXh0ZW5zaW9ucyB0byB0aGUgc2FtZSwg
dGhlcmUgc2VlbXMgdG8gYmUgc29tZSBuZXcgZGV2ZWxvcG1lbnQgcmVsYXRlZCB0byBBRVJPLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T3VyIGFwcHJvYWNoIGZvciBQRCwgd2hpY2gg
aXMgYSBmdXR1cmVzIGl0ZW0gaXMgYmFzaWNhbGx5IHdoYXQgd2Uga25vdyB0b2RheSBmb3IgUEQs
IFJGQzM2MzMuICZuYnNwO1dlIHNhdyBubyBuZWVkIHRvIHJlaW52ZW50IHRoZSB3aGVlbCBub3Ig
ZG8gd2UgaW50ZW5kIHRvLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBsb29rIGZv
cndhcmQgdG8gaGVhcmluZyBtb3JlIGFib3V0IEFFUk8sIGl0cyB1c2UgY2FzZXMsIGFuZCBhdmFp
bGFibGUgaW1wbGVtZW50YXRpb25zIGluIFlva29oYW1hLjwvZGl2Pg0KPGRpdj4NCjxkaXY+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPjxicj4NCjwvc3Bhbj48
L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsi
PkpvaG48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVz
IE5ldyBSb21hbic7Ij4mIzQzOzEtPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1Rp
bWVzIE5ldyBSb21hbic7Ij40ODQtOTYyLTAwNjA8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU
SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0
ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg
Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF
RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp
ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkZyZWQgVGVtcGxpbiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJv
ZWluZy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl
OiA8L3NwYW4+V2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IGF0IDEwOjM4PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Sm9obiBKYXNvbiBCcnpvem93c2tp
ICZsdDs8YSBocmVmPSJtYWlsdG86am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tIj5q
b2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb208L2E+Jmd0OywgVmljdG9yIEt1YXJzaW5n
aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpY3RvckBqdmtuZXQuY29tIj52aWN0b3JAanZrbmV0LmNv
bTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+
djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw
YW4+UkU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p
cHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5
bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lO
OjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi
IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6
dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy
IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ
Zm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4t
VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi
PkhpLCB3aGF0IHRoaXMgZHJhZnQgaXMgZGlzY3Vzc2luZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4g
QUVSTywgd2hlcmUgREhDUHY2IFBEIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+dXNlZCB0byBkZWxl
Z2F0ZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBwZXIgaG9zdC4gUGxlYXNlIHJlZmVyIHRvIHRoYXQg
ZG9jdW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+
PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi1h
ZXJvbGluay8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4t
YWVyb2xpbmsvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1
KTsiPkFFUk8gaGFzIGJlZW4gcHJlc2VudGVkIGF0IHRoZSBwYXN0IDQgSUVURnMgaW4gdGhlIGRt
bSB3b3JraW5nIGdyb3VwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+KGNoYXJ0cyBhdmFpbGFibGUgaW4g
cHJvY2VlZGluZ3MpLiBGcm9tIHNvbWUgb2YgdGhlIHJlY2VudCBkaXNjdXNzaW9ucyBvbjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi
KDMxLCA3MywgMTI1KTsiPm11bHRpLWFkZHJlc3NpbmcgYW5kIHByZWZpeCBkZWxlZ2F0aW9uIGl0
IHNvdW5kcyBsaWtlIGl0IHNob3VsZCBhbHNvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+cHJlc2Vu
dGVkIGluIHY2b3BzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1
KTsiPlRoYW5rcyDigJMgRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxhIGhyZWY9Im1haWx0bzpm
cmVkLmwudGVtcGxpbkBib2VpbmcuY29tIj5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog
cmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g
MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4gdjZvcHMg
WzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86djZvcHMtYm91
bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyem96b3dza2ksIEpvaG48
YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSA2OjMxIFBNPGJyPg0K
PGI+VG86PC9iPiBWaWN0b3IgS3VhcnNpbmdoPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls
dG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlw
djYtcHJlZml4LXBlci1ob3N0LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgVmljdG9yLiAmbmJzcDtJIHdpbGwgY29uZmVy
IHdpdGggR3VudGVyIG9uIHNvbWUgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QXMgYW4gYXNpZGUgSSB2aWV3IHRoZSBXTEFOLUdXIGFzIEkgd291bGQg
YSBDTVRTIGluIERPQ1NJUyBuZXR3b3Jrcy4gJm5ic3A7VGhlIFdMQU4tR1cgSVB2NiBjYXBhY2l0
eSB3b3VsZCBoYXZlIHRvIGJlIG1hbmFnZWQgc2ltaWxhciB0byBob3cgd2UgbWFuYWdlIGJsb2Nr
IHNpemVzIGZvciBwcmVmaXggZGVsZWdhdGlvbi4gJm5ic3A7VGhlIHBhcmVudCBJUHY2IGJsb2Nr
IHdvdWxkIGhhdmUgdG8gYmUgYWJsZSB0byBhIGFjY29tbW9kYXRlDQogdGhlIG92ZXJhbGwgY2Fw
YWNpdHkgb2YgdGhlIFdMQU4tR1cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFw
cGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uY2UgYSBXTEFOLUdXIHJlYWNoZXMgY2FwYWNpdHkgZWl0aGVyIGZyb20gYSBi
YW5kd2lkdGggcG9pbnQgb2YgdmlldywgSVB2NiBwcmVmaXhlcywgZXRjLiB0aGUgV0xBTi1HVyBz
cGxpdCB3b3VsZCBuZWVkIHRvIG9jY3VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbmUgbW9yZSBub3RlLCB0aGUgV0xBTi1HVyB3b3VsZCBvbmx5IGFkdmVy
dGlzZSB0aGUgcGFyZW50IElQdjYgYmxvY2sgdG8gYXZvaWQgcm91dGUgdGFibGUgYmxvYXQuICZu
YnNwO1BlcmhhcHMgdGhpcyBzaG91bGQgYmUgbGlzdGVkIGFzIGFub3RoZXIgb3BlcmF0aW9uYWwg
Y29uc2lkZXJhdGlvbi48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdCI+
Sm9objwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQiPiYjNDM7MS00ODQtOTYyLTAwNjA8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gT2N0IDIwLCAyMDE1LCBh
dCAyMDo1MiwgVmljdG9yIEt1YXJzaW5naCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpY3RvckBqdmtu
ZXQuY29tIj52aWN0b3JAanZrbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPkpvaG4vR3VudGVyLDxicj4NCjxicj4NCk92ZXJhbGwsIGdvb2QgZHJhZnQsIHdl
bGwgZXhwbGFpbmVkIGNhc2UgYW5kIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9mIGRlcGxveW1lbnQu
PGJyPg0KPGJyPg0KT24gdG8gY29tbWVudC4uLjxicj4NCjxicj4NCkJhc2VkIG9uIHRoaXMgdGV4
dCAuLiAmcXVvdDtUaGUgLzY0PGJyPg0KJm5ic3A7Jm5ic3A7IHByZWZpeCBjYW4gYmUgZGVyaXZl
ZCBmcm9tIGEgbG9jYWxseSBtYW5hZ2VkIHBvb2wgb3IgYWdncmVnYXRlIElQdjY8YnI+DQombmJz
cDsmbmJzcDsgYmxvY2sgYXNzaWduZWQgdG8gdGhlIFdMQU4tR1cgb3IgZnJvbSBhIHBvb2wgc2ln
bmFsbGVkIGJ5IHRoZSBSYWRpdXM8YnI+DQombmJzcDsmbmJzcDsgc2VydmVyIGluIGEgcmFkaXVz
IGF0dHJpYnV0ZS4mcXVvdDs8YnI+DQo8YnI+DQpJdHMgc2VlbXMgY2xlYXIgdGhhdCB0aGUgLzY0
cyB3b3VsZCBjb21lIGZyb20gYSBwb29sIGFuZC9vciBibG9jayBhcyB5b3Ugbm90ZWQuJm5ic3A7
IDxicj4NCjxicj4NCkkgd291bGQgdGhpbmsgdGhhdCB1bmRlciB0aGUgb3BlcmF0aW9uYWwgY29u
c2lkZXJhdGlvbnMgc2VjdGlvbiB3ZSB3b3VsZCB3YW50IHRvIGFkZCBzb21lIHRleHQgdGhhdCBu
b3RlcyB0aGUgbWFuYWdlbWVudCByZXF1aXJlbWVudHMgdG8gc2l6ZS9tYW5hZ2UgdGhvc2UgYmxv
Y2tzL3Bvb2xzLiZuYnNwOyBVbmRlciBhIHRyYWRpdGlvbmFsIGNhc2UsIHdpdGggYSAvNjQgcGVy
IFdMQU4tR1csIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoYXQgY2FuIGJlIGNvbnN1bWVkDQog
YnkgdGhhdCBvbmUgLzY0IHdvdWxkIG5vdCByZXF1aXJlIG1hbmFnZW1lbnQuJm5ic3A7IDxicj4N
Cjxicj4NCkhvd2V2ZXIsIGluIHRoaXMgY2FzZSwgaXQncyBwb3NzaWJsZSB0byBleGhhdXN0IHRo
ZSAjJm5ic3A7IG9mIGJsb2Nrcy4mbmJzcDsgSWYgdGhlIFdMQU4tR1cgaXMgTDMsIHRoZW4gaW4g
bGFyZ2UgdmVudWVzIC0gc2F5IHN0YWRpdW1zIG9yIG9wZW4gYXJlYXMsIHNpemluZyBmb3IgcGVh
ayBkZW1hbmQgcGVyaW9kcyB3b3VsZCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMgd2VsbC4mbmJz
cDsgU2l6aW5nL21hbmFnZW1lbnQgaXMgbGlrZWx5IG5vdCBhcyBtdWNoIG9mIGFuIGlzc3VlDQog
aW4gdGhlICZxdW90O2NvZmZlZSBzaG9wJnF1b3Q7IGRlcGxveW1lbnQgaW5zdGFuY2UuPGJyPg0K
PGJyPg0KPGJyPg0KVGhlIHRleHQgbmVlZCBub3QgYmUgY29tcGxpY2F0ZWQsIGJ1dCBzaG91bGQg
bm90ZSB0aGF0IHNvbWUgYXR0ZW50aW9uIC8gbWFuYWdlbWVudCBpcyByZXF1aXJlZC48YnI+DQo8
YnI+DQpyZWdhcmRzLDxicj4NCjxicj4NClZpY3RvciBLPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxNS0xMC0y
MCAyOjM1IFBNLCBGcmVkIEJha2VyIChmcmVkKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cHJlPlBvc3RlZCB5ZXN0ZXJkYXkuIFlvdXIgY29tbWVudCBzb2xpY2l0ZWQuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5CZWdpbiBm
b3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5Gcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu
b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt
cGVyLWhvc3QtMDAudHh0PG86cD48L286cD48L3ByZT4NCjxwcmU+RGF0ZTogT2N0b2JlciAxOSwg
MjAxNSBhdCAxMjo1MDowMSBQTSBQRFQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogPGEgaHJl
Zj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+Jmx0O2ktZC1hbm5vdW5jZUBpZXRmLm9y
ZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+UmVwbHktVG86IDxhIGhyZWY9Im1haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi
bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRp
dGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDogVW5pcXVlIElQdjYgUHJlZml4IFBlciBIb3N0PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBKb2huIEphc29uIEJyem96
b3dza2k8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgR3VudGVyIFZhbiBEZSBWZWxkZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA6IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE0PG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAy
MDE1LTEwLTE5PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IEluIHNvbWUgSVB2
NiBlbnZpcm9ubWVudHMgdGhlIG5lZWQgaGFzIGFyaXNlbiBmb3IgaG9zdHMgdG8gYmUgYWJsZSB0
bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB1dGlsaXNlIGEgdW5pcXVlIElQdjYgcHJl
Zml4IGV2ZW4gdGhvdWdoIHRoZSBsaW5rIG9yIG1lZGlhIG1heSBiZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyBzaGFyZWQuJm5ic3A7IFR5cGljYWxseSBob3N0cyAoc3Vic2NyaWJlcnMp
IG9uIGEgc2hhcmVkIG5ldHdvcmssIGxpa2UgV2ktPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7IEZpIG9yIEV0aGVybmV0LCB3aWxsIGFjcXVpcmUgdW5pcXVlIElQdjYgYWRkcmVzc2VzIGZy
b20gYSBjb21tb24gSVB2NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBwcmVmaXggdGhh
dCBpcyBhbGxvY2F0ZWQgb3IgYXNzaWduZWQgZm9yIHVzZSBvbiBhIHNwZWNpZmljIGxpbmsuPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IEJlbmVmaXRzIG9mIGEgdW5pcXVlIElQdjYgcHJl
Zml4IGNvbXBhcmVkIHRvIGEgdW5pcXVlIElQdjYgYWRkcmVzczxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGFyZSBnb2luZyBmcm9tIGVuaGFu
Y2VkIHN1YnNjcmliZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgbWFuYWdlbWVudCB0
byBpbXByb3ZlZCBpc29sYXRpb24gYmV0d2VlbiBzdWJzY3JpYmVycy48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgSW4gbW9zdCBkZXBs
b3ltZW50cyB0b2RheSBJUHY2IGFkZHJlc3MgYXNzaWdubWVudCBmcm9tIGEgc2luZ2xlIElQdjY8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgcHJlZml4IG9uIGEgc2hhcmVkIG5ldHdvcmsg
aXMgZG9uZSBieSBlaXRoZXIgdXNpbmcgSVB2NiBzdGF0ZWxlc3M8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsgYWRkcmVzcyBhdXRvLWNvbmZpZ3VyYXRpb24gKFNMQUFDKSBhbmQvb3Igc3Rh
dGVmdWwgREhDUHY2LiZuYnNwOyBXaGlsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB0
aGlzIGlzIHN0aWxsIHZpYWJsZSBhbmQgb3BlcmF0ZXMgYXMgZGVzaWduZWQgdGhlcmUgYXJlIHNv
bWUgbGFyZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgc2NhbGUgZW52aXJvbm1lbnRz
IHdoZXJlIHRoaXMgY29uY2VwdCBpbnRyb2R1Y2VzIHNpZ25pZmljYW50PG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7IHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywg
c3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyByb3V0ZXIgYW5kIG5laWdoYm9yIGRpc2NvdmVyeS4mbmJzcDsgVGhpcyBkb2N1bWVudCBvdXRs
aW5lcyBhbiBhcHByb2FjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB1dGlsaXNpbmcg
ZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB1bmlxdWUgSVB2NiBwcmVmaXggKGluc3RlYWQg
b2YgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQ8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsgSVB2NiBwcmVmaXgpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBJ
RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LyI+aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt
cGVyLWhvc3QvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMCI+aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4
LXBlci1ob3N0LTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlBsZWFzZSBub3RlIHRo
YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p
c3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh
bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyI+
dG9vbHMuaWV0Zi5vcmc8L2E+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v
bnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJmdHA6Ly9mdHAu
aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy
YWZ0cy88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5JLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZyI+SS1ELUFu
bm91bmNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5JbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vciA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcv
aWV0Zi8xc2hhZG93LXNpdGVzLnR4dCI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1z
aXRlcy50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnY2b3BzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9
Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3By
ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92
Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll
dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D24D2A7F18D07Bjohnbrzozowskicablecomcastcom_--


From nobody Wed Oct 21 09:05:59 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA51B29E0 for ; Wed, 21 Oct 2015 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWvSibROs1zH for ; Wed, 21 Oct 2015 09:05:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF91C1B29DE for ; Wed, 21 Oct 2015 09:05:54 -0700 (PDT)
Received: from mb.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9LG5qsc079927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2015 16:05:53 GMT (envelope-from joelja@bogus.com)
To: Philip Matthews 
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <5626FD84.1050101@bogus.com> <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
From: joel jaeggli 
X-Enigmail-Draft-Status: N1110
Message-ID: <5627B7D9.2010003@bogus.com>
Date: Wed, 21 Oct 2015 09:05:45 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tNJG5FB6AbBkpQ54okUljOmaACTL1fLM2"
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 16:05:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tNJG5FB6AbBkpQ54okUljOmaACTL1fLM2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 10/21/15 4:51 AM, Philip Matthews wrote:
> I agree that a business with 1 - 5 employees is likely to go the
> homenet route.
>=20
> I was thinking of the somewhat larger business of say 70 - 200
> employees, perhaps 2 or 4 locations, and with internal
> infrastructure. They have a small IT department (perhaps just 1
> person), firewalls, perhaps VoIP, perhaps an extranet relationships
> with suppliers or partners, etc.
>=20
> I am not an expert in the Enterprise area, so someone else may
> correct me, but I believe that such companies have not traditionally
> gotten PI space. Today, they would instead get PA space, use private
> addresses internally, and use NAT to avoid the renumbering issue when
> changing providers or to multi-home.
>=20
> If such a company came to me today and asked "How do I deploy IPv6",
> then I would be reluctant to say "Get PA space from your provider and
> use it internally".  I feel this would be doing them a dis-service.

so I oddly enough work in an enterprise that's of a somewhat similar
scale (200ish)...

The bigger office it has a gig link from level3 a pair of firewalls, a
pa v4 prefix and a pa v6 prefix. When we moved from down the road we had
building supplied link to XO (with no v6). the v4  is natted, the v6 is
not. the internal structure involves a total of 4 subnets of which three
are dual stacked.

The smaller offices are comcast business links (in the us) or as
appropriate in-country providers.

We obviously do have PI space, (the business is a CDN after all) we
don't use it in conjuction with the offices, whose networks exist to
provide connectivity to the people in them, not to support the core
tooling of the enterprise, which lives in colocation facilities, cloud
providers, and SOAS applications.

> It seems to me that the ideas that Brian mentions might become
> options in the future, but they are still in development and are not
> something that one could recommend to a company today.

Some enterprises have large investment in buildings hardware and
supporting  infrastructure in service to the core mission of the
enterprise (think of hospitals, airports, factories, large mining
operations and so on). these are going to favor heavily structured
network deployments. Those are not likely well suited to fluid
renumbering. in others numbering should be of little actual consequence
because it doesn't figure centrally in the infrastrcture.


> So right now, i see two options that I could realistically recommend
> to them: 1) Push them to get PI space.  (Would they qualify?  Perhaps
> someone more familiar with RIR policies can comment.) 2) Use ULA
> space internally and deploy NPT66.
>=20
> Is there a viable 3rd option that a company could deploy today?
>=20
> - Philip
>=20
>=20
> On 2015-10-20, at 22:50 , joel jaeggli wrote:
>=20
>> On 10/19/15 2:02 PM, Philip Matthews wrote:
>>> Brian:
>>>=20
>>> What solution would you recommend today to a
>>> small-to-medium-sized enterprise that cannot get PI space and
>>> wants the flexibility to easily change providers and possibly
>>> multi-home?
>>=20
>> PI space usage is actually about attachment costs, not about the
>> ability or inability to obtain it. it's obtainable but not usable
>> if you favor low attachment cost.
>>=20
>> Enterprises that favor low attachment costs like my home business
>> favor provider managed address ranges, low friction interaction
>> with cloud providers, soas for basically applications  and so
>> on);are not going to place a great deal of value on source ip
>> addresses, because among other things they aren't very stable; I'm
>> sending this email from a train, my pan currently has addressing
>> from t-mobile, when I get home that will change to comcast, the
>> devices at home, which  can reach from here are still on comcast.
>> for newly initiated connections source address selection will tend
>> to favor the network that currently works or if more than one
>> exists favor the lower cost/faster  one however you choose to=20
>> weight that .
>>=20
>>> If the enterprise numbers their network internally with PA
>>> space, then they need to renumber to change providers. Though
>>> this is definitely easier in IPv6 than IPv4, it is still not
>>> "easy".  And what about multi-homing?
>>=20
>> if you want a genuinly low attachment cost network al la homenet
>> then renumbering for the purposes of useful source selection needs
>> to be readily feasible, and fairly transparent. For destination
>> based multihoming DNS based GTM, health-checking, low ttls  and
>> other features commonly provided as applications are really the
>> rule of the day today and that doesn't seem likely to change.
>>=20
>>> - Philip
>>>=20
>>>=20
>>> On 2015-10-19, at 16:03 , Brian E Carpenter wrote:
>>>=20
>>>>> If ULAs are the only non-Link-Local address available the
>>>>> hosts, the enterprise will need to use translation
>>>>> technologies such as NPT[RFC6296] or NAT66 to reach the
>>>>> Internet.
>>>>=20
>>>> I think this is still the wrong message. Here's my suggestion:
>>>>=20
>>>> The best approach is to use ULAs for internal communications
>>>> and normal IPv6 addresses for external communications. Running=20
>>>> multiple addresses in this way is a standard feature of IPv6.
>>>> If for some reason an enterprise decides to use ULAs as the
>>>> only non-Link-Local address available to its hosts, the
>>>> enterprise will also need to use the experimental address
>>>> prefix technology translation known as NPTv6 [RFC6296] to reach
>>>> the Internet. Full address translation (known as NAT66) is
>>>> never needed for IPv6 since there is no address shortage.
>>>>=20
>>>> Regards Brian Carpenter
>>>>=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
>=20



--tNJG5FB6AbBkpQ54okUljOmaACTL1fLM2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlYnt9kACgkQ8AA1q7Z/VrKjJgCeO98KRIuwZ8a1QuL1NLkuHq0R
kjgAn1eJY4VNr/TAqBz/ckAyG4wzvMgf
=o7Nz
-----END PGP SIGNATURE-----

--tNJG5FB6AbBkpQ54okUljOmaACTL1fLM2--


From nobody Wed Oct 21 10:35:38 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBA41B2B39 for ; Wed, 21 Oct 2015 10:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbYTfkRLF9ou for ; Wed, 21 Oct 2015 10:35:33 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03711B2B5D for ; Wed, 21 Oct 2015 10:35:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9LHZSOi007544; Wed, 21 Oct 2015 12:35:28 -0500
Received: from XCH-BLV-306.nw.nos.boeing.com (xch-blv-306.nw.nos.boeing.com [130.247.25.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9LHZL7W007483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 21 Oct 2015 12:35:21 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.40]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 10:35:19 -0700
From: "Templin, Fred L" 
To: "Brzozowski, John" , Victor Kuarsingh 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRC5rO/+MZsnq7pUCTitCxpFGwKp51nmYAgABlGtCAAImrgP//pb6Q
Date: Wed, 21 Oct 2015 17:35:18 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2B2A1@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5626E1C6.8050209@jvknet.com>  <2134F8430051B64F815C691A62D9831832F2AE10@XCH-BLV-504.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F2B2A1XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 17:35:37 -0000

--_000_2134F8430051B64F815C691A62D9831832F2B2A1XCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSm9obiwNCg0KQXQgaXRzIGNvcmUsIEFFUk8gaXMgYWJvdXQgREhDUHY2IFByZWZpeCBEZWxl
Z2F0aW9uIG92ZXIgdHVubmVscy4gQSB3YXkgdG8gZ2V0IGEgcHJlZml4DQp0byBhIGZpeGVkIG9y
IG1vYmlsZSBkZXZpY2UgdGhhdCB0aGUgZGV2aWNlIGNhbiB1c2UgdG8gZWl0aGVyIG51bWJlciBp
dHMgZG93bnN0cmVhbQ0KYXR0YWNoZWQgbmV0d29ya3MsIG9yIHRvIGFzc2lnbiBvbmUgb3IgbW9y
ZSBhZGRyZXNzZXMgdG8gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoDQp0aGUgcHJlZml4IGRlbGVn
YXRpb24gd2FzIHJlY2VpdmVkIChvciBib3RoKS4gREhDUHY2IHByZWZpeCBkZWxlZ2F0aW9uIG92
ZXIgdHVubmVscw0KaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSB3YXkgaXQgd29ya3Mgb3ZlciBhbiBv
cmRpbmFyeSBpbnRlcmZhY2UsIGJ1dCB0aGVyZSBhcmUgc2V2ZXJhbA0KaW1wbGVtZW50YXRpb24g
ZGV0YWlscyDigJMgQUVSTyBzcGVjaWZpZXMgdGhvc2UuDQoNCkFFUk8gYWxzbyBpbmNsdWRlcyBJ
UHY2IE5EIGZ1bmN0aW9ucyB0byBzdXBwb3J0IHJvdXRlIG9wdGltaXphdGlvbi4gVGhlc2UgZnVu
Y3Rpb25zDQpuZWVkIG5vdCBiZSBlbXBsb3llZCB3aGVuIHRoZSBlbmQgdXNlciBkZXZpY2UgY2Fu
IHJlbWFpbiB0ZXRoZXJlZCB0byBpdHMgc2VydmVyDQooaS5lLiwgdGhlIG5vZGUgdGhhdCBwcm92
aWRlZCB0aGUgcHJlZml4IGRlbGVnYXRpb24pLiBBRVJPIG1vYmlsaXR5IGFsc28gaXMgb3B0aW9u
YWwNCmlmIHRoZSBkZXZpY2UgdGhhdCByZWNlaXZlcyB0aGUgZGVsZWdhdGVkIHByZWZpeCBpcyBh
IGZpeGVkIG5vZGUuIEJ1dCwgbW9iaWxpdHkgaXMNCmJhc2VkIG9uIHN0YW5kYXJkIERIQ1B2NiBt
ZXNzYWdpbmcgc28gaXQgaXMgYWx3YXlzIGF2YWlsYWJsZSBpZiBuZWVkZWQuDQoNCkFFUk8gaXMg
Y3VycmVudGx5IHJ1bm5pbmcgb24gbGludXggYW5kIEFuZHJvaWQuIFRoZSBsaW51eCBpbXBsZW1l
bnRhdGlvbiBoYXMgYmVlbg0KYW5ub3VuY2VkIG9uIG90aGVyIElFVEYgbGlzdHMsIGFuZCBpcyBh
dmFpbGFibGUgZm9yIHB1YmxpYyBhY2Nlc3M6DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v
cmcvYXJjaC9tc2cvaW50LWFyZWEvNFBxcDZOWVpJa0JZbjV4WklMTjdrUVFxREhVDQoNCkkgd291
bGQgYmUgaGFwcHkgdG8gZGlzY3VzcyBhbnkgb2YgdGhpcyBhdCB0aGUgdXBjb21pbmcgbWVldGlu
Zy4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206
IEJyem96b3dza2ksIEpvaG4gW21haWx0bzpKb2huX0Jyem96b3dza2lAY2FibGUuY29tY2FzdC5j
b21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjEsIDIwMTUgODo0NiBBTQ0KVG86IFRlbXBs
aW4sIEZyZWQgTDsgVmljdG9yIEt1YXJzaW5naA0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlw
djYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KDQpGcmVkLA0KDQpSZXBseWluZyBoZXJlIGluc3Rl
YWQgb2Ygb2ZmIGxpc3QuICBJIHRvb2sgYSBxdWljayBsb29rIGF0IHRoZSBkcmFmdCBhbmQgYWRt
aXQgdGhlcmUgYXJlIHNvbWUgYXNwZWN0cyBvZiB0aGUgZHJhZnQgdGhhdCBzZWVtIHNpbWlsYXIg
dG8gd2hhdCB3ZSBoYXZlIGRvbmUuICBIb3dldmVyLCB0aGVyZSBpcyBhIGxvdCBtb3JlIHRvIEFF
Uk8gdGhhbiB3aGF0IHdlIG5lZWQuICBXZSB1dGlsaXplIGV4aXN0aW5nIHByb3RvY29scyBhbmQg
ZGV2ZWxvcGVkIG5vIGV4dGVuc2lvbnMgdG8gdGhlIHNhbWUsIHRoZXJlIHNlZW1zIHRvIGJlIHNv
bWUgbmV3IGRldmVsb3BtZW50IHJlbGF0ZWQgdG8gQUVSTy4NCg0KT3VyIGFwcHJvYWNoIGZvciBQ
RCwgd2hpY2ggaXMgYSBmdXR1cmVzIGl0ZW0gaXMgYmFzaWNhbGx5IHdoYXQgd2Uga25vdyB0b2Rh
eSBmb3IgUEQsIFJGQzM2MzMuICBXZSBzYXcgbm8gbmVlZCB0byByZWludmVudCB0aGUgd2hlZWwg
bm9yIGRvIHdlIGludGVuZCB0by4NCg0KSSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBtb3JlIGFi
b3V0IEFFUk8sIGl0cyB1c2UgY2FzZXMsIGFuZCBhdmFpbGFibGUgaW1wbGVtZW50YXRpb25zIGlu
IFlva29oYW1hLg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KRnJvbTogRnJlZCBUZW1wbGlu
IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vpbmcu
Y29tPj4NCkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciAyMSwgMjAxNSBhdCAxMDozOA0KVG86IEpv
aG4gSmFzb24gQnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPG1h
aWx0bzpqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20+PiwgVmljdG9yIEt1YXJzaW5n
aCA8dmljdG9yQGp2a25ldC5jb208bWFpbHRvOnZpY3RvckBqdmtuZXQuY29tPj4NCkNjOiB2Nm9w
cyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBb
djZvcHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm
aXgtcGVyLWhvc3QtMDAudHh0DQoNCkhpLCB3aGF0IHRoaXMgZHJhZnQgaXMgZGlzY3Vzc2luZyBp
cyBhbHJlYWR5IGNvdmVyZWQgaW4gQUVSTywgd2hlcmUgREhDUHY2IFBEIGlzDQp1c2VkIHRvIGRl
bGVnYXRlIGEgdW5pcXVlIElQdjYgcHJlZml4IHBlciBob3N0LiBQbGVhc2UgcmVmZXIgdG8gdGhh
dCBkb2N1bWVudDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVt
cGxpbi1hZXJvbGluay8NCg0KQUVSTyBoYXMgYmVlbiBwcmVzZW50ZWQgYXQgdGhlIHBhc3QgNCBJ
RVRGcyBpbiB0aGUgZG1tIHdvcmtpbmcgZ3JvdXANCihjaGFydHMgYXZhaWxhYmxlIGluIHByb2Nl
ZWRpbmdzKS4gRnJvbSBzb21lIG9mIHRoZSByZWNlbnQgZGlzY3Vzc2lvbnMgb24NCm11bHRpLWFk
ZHJlc3NpbmcgYW5kIHByZWZpeCBkZWxlZ2F0aW9uIGl0IHNvdW5kcyBsaWtlIGl0IHNob3VsZCBh
bHNvIGJlDQpwcmVzZW50ZWQgaW4gdjZvcHMuDQoNClRoYW5rcyDigJMgRnJlZA0KZnJlZC5sLnRl
bXBsaW5AYm9laW5nLmNvbTxtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbT4NCg0KRnJv
bTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJ6
b3pvd3NraSwgSm9obg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSA2OjMxIFBNDQpU
bzogVmljdG9yIEt1YXJzaW5naA0KQ2M6IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm
Lm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12
Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNClRoYW5rcyBWaWN0b3Iu
ICBJIHdpbGwgY29uZmVyIHdpdGggR3VudGVyIG9uIHNvbWUgdGV4dC4NCg0KQXMgYW4gYXNpZGUg
SSB2aWV3IHRoZSBXTEFOLUdXIGFzIEkgd291bGQgYSBDTVRTIGluIERPQ1NJUyBuZXR3b3Jrcy4g
IFRoZSBXTEFOLUdXIElQdjYgY2FwYWNpdHkgd291bGQgaGF2ZSB0byBiZSBtYW5hZ2VkIHNpbWls
YXIgdG8gaG93IHdlIG1hbmFnZSBibG9jayBzaXplcyBmb3IgcHJlZml4IGRlbGVnYXRpb24uICBU
aGUgcGFyZW50IElQdjYgYmxvY2sgd291bGQgaGF2ZSB0byBiZSBhYmxlIHRvIGEgYWNjb21tb2Rh
dGUgdGhlIG92ZXJhbGwgY2FwYWNpdHkgb2YgdGhlIFdMQU4tR1cuDQoNCk9uY2UgYSBXTEFOLUdX
IHJlYWNoZXMgY2FwYWNpdHkgZWl0aGVyIGZyb20gYSBiYW5kd2lkdGggcG9pbnQgb2Ygdmlldywg
SVB2NiBwcmVmaXhlcywgZXRjLiB0aGUgV0xBTi1HVyBzcGxpdCB3b3VsZCBuZWVkIHRvIG9jY3Vy
Lg0KDQpPbmUgbW9yZSBub3RlLCB0aGUgV0xBTi1HVyB3b3VsZCBvbmx5IGFkdmVydGlzZSB0aGUg
cGFyZW50IElQdjYgYmxvY2sgdG8gYXZvaWQgcm91dGUgdGFibGUgYmxvYXQuICBQZXJoYXBzIHRo
aXMgc2hvdWxkIGJlIGxpc3RlZCBhcyBhbm90aGVyIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb24u
DQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQpPbiBPY3QgMjAsIDIwMTUsIGF0IDIwOjUyLCBW
aWN0b3IgS3VhcnNpbmdoIDx2aWN0b3JAanZrbmV0LmNvbTxtYWlsdG86dmljdG9yQGp2a25ldC5j
b20+PiB3cm90ZToNCkpvaG4vR3VudGVyLA0KDQpPdmVyYWxsLCBnb29kIGRyYWZ0LCB3ZWxsIGV4
cGxhaW5lZCBjYXNlIGFuZCBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiBkZXBsb3ltZW50Lg0KDQpP
biB0byBjb21tZW50Li4uDQoNCkJhc2VkIG9uIHRoaXMgdGV4dCAuLiAiVGhlIC82NA0KICAgcHJl
Zml4IGNhbiBiZSBkZXJpdmVkIGZyb20gYSBsb2NhbGx5IG1hbmFnZWQgcG9vbCBvciBhZ2dyZWdh
dGUgSVB2Ng0KICAgYmxvY2sgYXNzaWduZWQgdG8gdGhlIFdMQU4tR1cgb3IgZnJvbSBhIHBvb2wg
c2lnbmFsbGVkIGJ5IHRoZSBSYWRpdXMNCiAgIHNlcnZlciBpbiBhIHJhZGl1cyBhdHRyaWJ1dGUu
Ig0KDQpJdHMgc2VlbXMgY2xlYXIgdGhhdCB0aGUgLzY0cyB3b3VsZCBjb21lIGZyb20gYSBwb29s
IGFuZC9vciBibG9jayBhcyB5b3Ugbm90ZWQuDQoNCkkgd291bGQgdGhpbmsgdGhhdCB1bmRlciB0
aGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB3ZSB3b3VsZCB3YW50IHRvIGFk
ZCBzb21lIHRleHQgdGhhdCBub3RlcyB0aGUgbWFuYWdlbWVudCByZXF1aXJlbWVudHMgdG8gc2l6
ZS9tYW5hZ2UgdGhvc2UgYmxvY2tzL3Bvb2xzLiAgVW5kZXIgYSB0cmFkaXRpb25hbCBjYXNlLCB3
aXRoIGEgLzY0IHBlciBXTEFOLUdXLCB0aGUgbnVtYmVyIG9mIGFkZHJlc3NlcyB0aGF0IGNhbiBi
ZSBjb25zdW1lZCBieSB0aGF0IG9uZSAvNjQgd291bGQgbm90IHJlcXVpcmUgbWFuYWdlbWVudC4N
Cg0KSG93ZXZlciwgaW4gdGhpcyBjYXNlLCBpdCdzIHBvc3NpYmxlIHRvIGV4aGF1c3QgdGhlICMg
IG9mIGJsb2Nrcy4gIElmIHRoZSBXTEFOLUdXIGlzIEwzLCB0aGVuIGluIGxhcmdlIHZlbnVlcyAt
IHNheSBzdGFkaXVtcyBvciBvcGVuIGFyZWFzLCBzaXppbmcgZm9yIHBlYWsgZGVtYW5kIHBlcmlv
ZHMgd291bGQgbmVlZCB0byBiZSBjb25zaWRlcmVkIGFzIHdlbGwuICBTaXppbmcvbWFuYWdlbWVu
dCBpcyBsaWtlbHkgbm90IGFzIG11Y2ggb2YgYW4gaXNzdWUgaW4gdGhlICJjb2ZmZWUgc2hvcCIg
ZGVwbG95bWVudCBpbnN0YW5jZS4NCg0KDQpUaGUgdGV4dCBuZWVkIG5vdCBiZSBjb21wbGljYXRl
ZCwgYnV0IHNob3VsZCBub3RlIHRoYXQgc29tZSBhdHRlbnRpb24gLyBtYW5hZ2VtZW50IGlzIHJl
cXVpcmVkLg0KDQpyZWdhcmRzLA0KDQpWaWN0b3IgSw0KDQoNCg0KDQpPbiAyMDE1LTEwLTIwIDI6
MzUgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3RlOg0KDQpQb3N0ZWQgeWVzdGVyZGF5LiBZb3Vy
IGNvbW1lbnQgc29saWNpdGVkLg0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCg0K
DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZz4NCg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUt
aXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNCkRhdGU6IE9jdG9iZXIgMTksIDIwMTUgYXQg
MTI6NTA6MDEgUE0gUERUDQoNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPjxtYWlsdG86aS1k
LWFubm91bmNlQGlldGYub3JnPg0KDQpSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoNCg0KDQoNCg0KQSBOZXcgSW50ZXJu
ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp
cmVjdG9yaWVzLg0KDQoNCg0KDQoNCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBVbmlxdWUgSVB2
NiBQcmVmaXggUGVyIEhvc3QNCg0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4gSmFzb24g
QnJ6b3pvd3NraQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgR3VudGVyIFZhbiBEZSBWZWxk
ZQ0KDQogICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1w
cmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNCiAgICBQYWdlcyAgICAgICAgICAgOiAxNA0KDQogICAg
RGF0ZSAgICAgICAgICAgIDogMjAxNS0xMC0xOQ0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgSW4gc29t
ZSBJUHY2IGVudmlyb25tZW50cyB0aGUgbmVlZCBoYXMgYXJpc2VuIGZvciBob3N0cyB0byBiZSBh
YmxlIHRvDQoNCiAgdXRpbGlzZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBldmVuIHRob3VnaCB0aGUg
bGluayBvciBtZWRpYSBtYXkgYmUNCg0KICBzaGFyZWQuICBUeXBpY2FsbHkgaG9zdHMgKHN1YnNj
cmliZXJzKSBvbiBhIHNoYXJlZCBuZXR3b3JrLCBsaWtlIFdpLQ0KDQogIEZpIG9yIEV0aGVybmV0
LCB3aWxsIGFjcXVpcmUgdW5pcXVlIElQdjYgYWRkcmVzc2VzIGZyb20gYSBjb21tb24gSVB2Ng0K
DQogIHByZWZpeCB0aGF0IGlzIGFsbG9jYXRlZCBvciBhc3NpZ25lZCBmb3IgdXNlIG9uIGEgc3Bl
Y2lmaWMgbGluay4NCg0KICBCZW5lZml0cyBvZiBhIHVuaXF1ZSBJUHY2IHByZWZpeCBjb21wYXJl
ZCB0byBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MNCg0KICBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVy
IGFyZSBnb2luZyBmcm9tIGVuaGFuY2VkIHN1YnNjcmliZXINCg0KICBtYW5hZ2VtZW50IHRvIGlt
cHJvdmVkIGlzb2xhdGlvbiBiZXR3ZWVuIHN1YnNjcmliZXJzLg0KDQoNCg0KICBJbiBtb3N0IGRl
cGxveW1lbnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBzaW5nbGUgSVB2
Ng0KDQogIHByZWZpeCBvbiBhIHNoYXJlZCBuZXR3b3JrIGlzIGRvbmUgYnkgZWl0aGVyIHVzaW5n
IElQdjYgc3RhdGVsZXNzDQoNCiAgYWRkcmVzcyBhdXRvLWNvbmZpZ3VyYXRpb24gKFNMQUFDKSBh
bmQvb3Igc3RhdGVmdWwgREhDUHY2LiAgV2hpbGUNCg0KICB0aGlzIGlzIHN0aWxsIHZpYWJsZSBh
bmQgb3BlcmF0ZXMgYXMgZGVzaWduZWQgdGhlcmUgYXJlIHNvbWUgbGFyZ2UNCg0KICBzY2FsZSBl
bnZpcm9ubWVudHMgd2hlcmUgdGhpcyBjb25jZXB0IGludHJvZHVjZXMgc2lnbmlmaWNhbnQNCg0K
ICBwZXJmb3JtYW5jZSBjaGFsbGVuZ2VzIGFuZCBpbXBsaWNhdGlvbnMsIHNwZWNpZmljYWxseSBy
ZWxhdGVkIHRvIElQdjYNCg0KICByb3V0ZXIgYW5kIG5laWdoYm9yIGRpc2NvdmVyeS4gIFRoaXMg
ZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2gNCg0KICB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2
NiBwcm90b2NvbHMgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYQ0KDQogIHVuaXF1ZSBJ
UHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJl
ZA0KDQogIElQdjYgcHJlZml4KS4NCg0KDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0
dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvDQoNCg0K
DQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4
LXBlci1ob3N0LTAwDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUg
aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn
PGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g
YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQoNCkktRC1Bbm5vdW5jZUBp
ZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KDQpJbnRlcm5ldC1EcmFmdCBkaXJl
Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQpvciBmdHA6Ly9mdHAu
aWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnY2b3BzIG1haWxpbmcgbGlzdA0K
DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5v
cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby92Nm9wcw0K

--_000_2134F8430051B64F815C691A62D9831832F2B2A1XCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm
b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBK
b2huLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXQgaXRzIGNv
cmUsIEFFUk8gaXMgYWJvdXQgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIG92ZXIgdHVubmVscy4g
QSB3YXkgdG8gZ2V0IGEgcHJlZml4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIGEgZml4ZWQgb3IgbW9i
aWxlIGRldmljZSB0aGF0IHRoZSBkZXZpY2UgY2FuIHVzZSB0byBlaXRoZXIgbnVtYmVyIGl0cyBk
b3duc3RyZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmF0dGFjaGVkIG5ldHdvcmtzLCBvciB0byBhc3Np
Z24gb25lIG9yIG1vcmUgYWRkcmVzc2VzIHRvIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj50aGUgcHJlZml4IGRlbGVnYXRpb24gd2FzIHJlY2VpdmVkIChvciBib3Ro
KS4gREhDUHY2IHByZWZpeCBkZWxlZ2F0aW9uIG92ZXIgdHVubmVsczxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5pcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIHdheSBpdCB3b3JrcyBvdmVyIGFuIG9yZGluYXJ5IGlu
dGVyZmFjZSwgYnV0IHRoZXJlIGFyZSBzZXZlcmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmltcGxlbWVu
dGF0aW9uIGRldGFpbHMg4oCTIEFFUk8gc3BlY2lmaWVzIHRob3NlLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QUVSTyBhbHNvIGluY2x1ZGVzIElQdjYgTkQgZnVu
Y3Rpb25zIHRvIHN1cHBvcnQgcm91dGUgb3B0aW1pemF0aW9uLiBUaGVzZSBmdW5jdGlvbnM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+bmVlZCBub3QgYmUgZW1wbG95ZWQgd2hlbiB0aGUgZW5kIHVzZXIgZGV2
aWNlIGNhbiByZW1haW4gdGV0aGVyZWQgdG8gaXRzIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4o
aS5lLiwgdGhlIG5vZGUgdGhhdCBwcm92aWRlZCB0aGUgcHJlZml4IGRlbGVnYXRpb24pLiBBRVJP
IG1vYmlsaXR5IGFsc28gaXMgb3B0aW9uYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWYgdGhlIGRldmlj
ZSB0aGF0IHJlY2VpdmVzIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGlzIGEgZml4ZWQgbm9kZS4gQnV0
LCBtb2JpbGl0eSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5iYXNlZCBvbiBzdGFuZGFyZCBESENQdjYg
bWVzc2FnaW5nIHNvIGl0IGlzIGFsd2F5cyBhdmFpbGFibGUgaWYgbmVlZGVkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QUVSTyBpcyBjdXJyZW50bHkgcnVubmlu
ZyBvbiBsaW51eCBhbmQgQW5kcm9pZC4gVGhlIGxpbnV4IGltcGxlbWVudGF0aW9uIGhhcyBiZWVu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPmFubm91bmNlZCBvbiBvdGhlciBJRVRGIGxpc3RzLCBhbmQgaXMg
YXZhaWxhYmxlIGZvciBwdWJsaWMgYWNjZXNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo
L21zZy9pbnQtYXJlYS80UHFwNk5ZWklrQlluNXhaSUxON2tRUXFESFUiPmh0dHBzOi8vbWFpbGFy
Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaW50LWFyZWEvNFBxcDZOWVpJa0JZbjV4WklMTjdrUVFx
REhVPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3b3Vs
ZCBiZSBoYXBweSB0byBkaXNjdXNzIGFueSBvZiB0aGlzIGF0IHRoZSB1cGNvbWluZyBtZWV0aW5n
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIOKAkyBG
cmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu
MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PiBCcnpvem93c2tpLCBKb2huIFttYWlsdG86Sm9obl9Ccnpvem93c2tpQGNhYmxlLmNvbWNhc3Qu
Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAyMSwgMjAxNSA4OjQ2
IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEw7IFZpY3RvciBLdWFyc2luZ2g8YnI+
DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZv
cHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt
cGVyLWhvc3QtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5G
cmVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOmJsYWNrIj5SZXBseWluZyBoZXJlIGluc3RlYWQgb2Ygb2ZmIGxpc3QuICZuYnNw
O0kgdG9vayBhIHF1aWNrIGxvb2sgYXQgdGhlIGRyYWZ0IGFuZCBhZG1pdCB0aGVyZSBhcmUgc29t
ZSBhc3BlY3RzIG9mIHRoZSBkcmFmdCB0aGF0IHNlZW0gc2ltaWxhciB0byB3aGF0IHdlIGhhdmUg
ZG9uZS4gJm5ic3A7SG93ZXZlciwNCiB0aGVyZSBpcyBhIGxvdCBtb3JlIHRvIEFFUk8gdGhhbiB3
aGF0IHdlIG5lZWQuICZuYnNwO1dlIHV0aWxpemUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBkZXZl
bG9wZWQgbm8gZXh0ZW5zaW9ucyB0byB0aGUgc2FtZSwgdGhlcmUgc2VlbXMgdG8gYmUgc29tZSBu
ZXcgZGV2ZWxvcG1lbnQgcmVsYXRlZCB0byBBRVJPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PdXIgYXBwcm9hY2gg
Zm9yIFBELCB3aGljaCBpcyBhIGZ1dHVyZXMgaXRlbSBpcyBiYXNpY2FsbHkgd2hhdCB3ZSBrbm93
IHRvZGF5IGZvciBQRCwgUkZDMzYzMy4gJm5ic3A7V2Ugc2F3IG5vIG5lZWQgdG8gcmVpbnZlbnQg
dGhlIHdoZWVsIG5vciBkbyB3ZSBpbnRlbmQgdG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgbG9vayBmb3J3YXJk
IHRvIGhlYXJpbmcgbW9yZSBhYm91dCBBRVJPLCBpdHMgdXNlIGNhc2VzLCBhbmQgYXZhaWxhYmxl
IGltcGxlbWVudGF0aW9ucyBpbiBZb2tvaGFtYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpi
bGFjayI+Sm9objwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNrIj4mIzQzOzEtNDg0LTk2Mi0wMDYwPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5GcmVkIFRlbXBsaW4gJmx0OzxhIGhyZWY9Im1haWx0
bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9h
PiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IGF0IDEw
OjM4PGJyPg0KPGI+VG86IDwvYj5Kb2huIEphc29uIEJyem96b3dza2kgJmx0OzxhIGhyZWY9Im1h
aWx0bzpqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20iPmpvaG5fYnJ6b3pvd3NraUBj
YWJsZS5jb21jYXN0LmNvbTwvYT4mZ3Q7LCBWaWN0b3IgS3VhcnNpbmdoICZsdDs8YSBocmVmPSJt
YWlsdG86dmljdG9yQGp2a25ldC5jb20iPnZpY3RvckBqdmtuZXQuY29tPC9hPiZndDs8YnI+DQo8
Yj5DYzogPC9iPnY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3Bz
QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFt2Nm9wc10gRndkOiBJ
LUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0w
MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4t
bGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O
X0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksIHdoYXQgdGhpcyBkcmFmdCBpcyBkaXNjdXNzaW5n
IGlzIGFscmVhZHkgY292ZXJlZCBpbiBBRVJPLCB3aGVyZSBESENQdjYgUEQgaXM8L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dXNlZCB0byBkZWxlZ2F0
ZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBwZXIgaG9zdC4gUGxlYXNlIHJlZmVyIHRvIHRoYXQgZG9j
dW1lbnQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGlu
LWFlcm9saW5rLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxp
bi1hZXJvbGluay88L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5BRVJPIGhhcyBiZWVuIHByZXNlbnRlZCBhdCB0aGUgcGFzdCA0IElFVEZzIGlu
IHRoZSBkbW0gd29ya2luZyBncm91cDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj4oY2hhcnRzIGF2YWlsYWJsZSBpbiBwcm9jZWVkaW5ncykuIEZyb20g
c29tZSBvZiB0aGUgcmVjZW50IGRpc2N1c3Npb25zIG9uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm11bHRpLWFkZHJlc3NpbmcgYW5kIHByZWZpeCBk
ZWxlZ2F0aW9uIGl0IHNvdW5kcyBsaWtlIGl0IHNob3VsZCBhbHNvIGJlPC9zcGFuPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByZXNlbnRlZCBpbiB2Nm9wcy48
L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r
cyDigJMgRnJlZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48YSBocmVmPSJtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSI+ZnJlZC5sLnRl
bXBsaW5AYm9laW5nLmNvbTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2siPiB2Nm9wcyBbPGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJ6
b3pvd3NraSwgSm9objxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDIwLCAyMDE1
IDY6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IFZpY3RvciBLdWFyc2luZ2g8YnI+DQo8Yj5DYzo8L2I+
IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12
Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0PC9zcGFuPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+VGhhbmtzIFZpY3Rvci4gJm5ic3A7SSB3aWxsIGNvbmZlciB3aXRoIEd1
bnRlciBvbiBzb21lIHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPkFzIGFuIGFzaWRlIEkgdmlldyB0aGUgV0xBTi1HVyBhcyBJIHdvdWxk
IGEgQ01UUyBpbiBET0NTSVMgbmV0d29ya3MuICZuYnNwO1RoZSBXTEFOLUdXIElQdjYgY2FwYWNp
dHkgd291bGQgaGF2ZSB0byBiZSBtYW5hZ2VkIHNpbWlsYXIgdG8gaG93IHdlIG1hbmFnZSBibG9j
ayBzaXplcyBmb3IgcHJlZml4IGRlbGVnYXRpb24uICZuYnNwO1RoZSBwYXJlbnQgSVB2NiBibG9j
ayB3b3VsZA0KIGhhdmUgdG8gYmUgYWJsZSB0byBhIGFjY29tbW9kYXRlIHRoZSBvdmVyYWxsIGNh
cGFjaXR5IG9mIHRoZSBXTEFOLUdXLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj5PbmNlIGEgV0xBTi1HVyByZWFjaGVzIGNhcGFjaXR5IGVpdGhl
ciBmcm9tIGEgYmFuZHdpZHRoIHBvaW50IG9mIHZpZXcsIElQdjYgcHJlZml4ZXMsIGV0Yy4gdGhl
IFdMQU4tR1cgc3BsaXQgd291bGQgbmVlZCB0byBvY2N1ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T25lIG1vcmUgbm90ZSwgdGhlIFdMQU4t
R1cgd291bGQgb25seSBhZHZlcnRpc2UgdGhlIHBhcmVudCBJUHY2IGJsb2NrIHRvIGF2b2lkIHJv
dXRlIHRhYmxlIGJsb2F0LiAmbmJzcDtQZXJoYXBzIHRoaXMgc2hvdWxkIGJlIGxpc3RlZCBhcyBh
bm90aGVyIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb24uPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2NvbG9yOmJsYWNrIj5Kb2huPC9zcGFuPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Y29sb3I6YmxhY2si
PiYjNDM7MS00ODQtOTYyLTAwNjA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj48YnI+DQpPbiBPY3QgMjAsIDIwMTUsIGF0IDIwOjUyLCBWaWN0b3IgS3VhcnNpbmdoICZs
dDs8YSBocmVmPSJtYWlsdG86dmljdG9yQGp2a25ldC5jb20iPnZpY3RvckBqdmtuZXQuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+Sm9obi9HdW50ZXIsPGJyPg0KPGJyPg0KT3ZlcmFsbCwgZ29vZCBkcmFm
dCwgd2VsbCBleHBsYWluZWQgY2FzZSBhbmQgZGV0YWlsZWQgZXhwbGFuYXRpb24gb2YgZGVwbG95
bWVudC48YnI+DQo8YnI+DQpPbiB0byBjb21tZW50Li4uPGJyPg0KPGJyPg0KQmFzZWQgb24gdGhp
cyB0ZXh0IC4uICZxdW90O1RoZSAvNjQ8YnI+DQombmJzcDsmbmJzcDsgcHJlZml4IGNhbiBiZSBk
ZXJpdmVkIGZyb20gYSBsb2NhbGx5IG1hbmFnZWQgcG9vbCBvciBhZ2dyZWdhdGUgSVB2Njxicj4N
CiZuYnNwOyZuYnNwOyBibG9jayBhc3NpZ25lZCB0byB0aGUgV0xBTi1HVyBvciBmcm9tIGEgcG9v
bCBzaWduYWxsZWQgYnkgdGhlIFJhZGl1czxicj4NCiZuYnNwOyZuYnNwOyBzZXJ2ZXIgaW4gYSBy
YWRpdXMgYXR0cmlidXRlLiZxdW90Ozxicj4NCjxicj4NCkl0cyBzZWVtcyBjbGVhciB0aGF0IHRo
ZSAvNjRzIHdvdWxkIGNvbWUgZnJvbSBhIHBvb2wgYW5kL29yIGJsb2NrIGFzIHlvdSBub3RlZC4m
bmJzcDsgPGJyPg0KPGJyPg0KSSB3b3VsZCB0aGluayB0aGF0IHVuZGVyIHRoZSBvcGVyYXRpb25h
bCBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdlIHdvdWxkIHdhbnQgdG8gYWRkIHNvbWUgdGV4dCB0
aGF0IG5vdGVzIHRoZSBtYW5hZ2VtZW50IHJlcXVpcmVtZW50cyB0byBzaXplL21hbmFnZSB0aG9z
ZSBibG9ja3MvcG9vbHMuJm5ic3A7IFVuZGVyIGEgdHJhZGl0aW9uYWwgY2FzZSwgd2l0aCBhIC82
NCBwZXIgV0xBTi1HVywgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgdGhhdCBjYW4gYmUgY29uc3Vt
ZWQNCiBieSB0aGF0IG9uZSAvNjQgd291bGQgbm90IHJlcXVpcmUgbWFuYWdlbWVudC4mbmJzcDsg
PGJyPg0KPGJyPg0KSG93ZXZlciwgaW4gdGhpcyBjYXNlLCBpdCdzIHBvc3NpYmxlIHRvIGV4aGF1
c3QgdGhlICMmbmJzcDsgb2YgYmxvY2tzLiZuYnNwOyBJZiB0aGUgV0xBTi1HVyBpcyBMMywgdGhl
biBpbiBsYXJnZSB2ZW51ZXMgLSBzYXkgc3RhZGl1bXMgb3Igb3BlbiBhcmVhcywgc2l6aW5nIGZv
ciBwZWFrIGRlbWFuZCBwZXJpb2RzIHdvdWxkIG5lZWQgdG8gYmUgY29uc2lkZXJlZCBhcyB3ZWxs
LiZuYnNwOyBTaXppbmcvbWFuYWdlbWVudCBpcyBsaWtlbHkgbm90IGFzIG11Y2ggb2YgYW4gaXNz
dWUNCiBpbiB0aGUgJnF1b3Q7Y29mZmVlIHNob3AmcXVvdDsgZGVwbG95bWVudCBpbnN0YW5jZS48
YnI+DQo8YnI+DQo8YnI+DQpUaGUgdGV4dCBuZWVkIG5vdCBiZSBjb21wbGljYXRlZCwgYnV0IHNo
b3VsZCBub3RlIHRoYXQgc29tZSBhdHRlbnRpb24gLyBtYW5hZ2VtZW50IGlzIHJlcXVpcmVkLjxi
cj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KPGJyPg0KVmljdG9yIEs8YnI+DQo8YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PbiAyMDE1LTEwLTIwIDI6MzUgUE0sIEZy
ZWQgQmFrZXIgKGZyZWQpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UG9zdGVkIHllc3RlcmRheS4gWW91ciBjb21t
ZW50IHNvbGljaXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206
IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj5TdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1
ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EYXRlOiBPY3RvYmVyIDE5LCAyMDE1IGF0IDEy
OjUwOjAxIFBNIFBEVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPlRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj4m
bHQ7aS1kLWFubm91bmNlQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXBseS1UbzogPGEgaHJlZj0ibWFpbHRv
OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s
aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBVbmlxdWUgSVB2NiBQcmVmaXggUGVy
IEhvc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEpvaG4gSmFzb24gQnJ6
b3pvd3NraTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHdW50ZXIgVmFuIERlIFZlbGRl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv
c3QtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMTQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA6IDIwMTUtMTAtMTk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BYnN0cmFjdDo8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgSW4gc29t
ZSBJUHY2IGVudmlyb25tZW50cyB0aGUgbmVlZCBoYXMgYXJpc2VuIGZvciBob3N0cyB0byBiZSBh
YmxlIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7IHV0aWxpc2UgYSB1bmlxdWUgSVB2NiBwcmVmaXggZXZlbiB0aG91Z2ggdGhl
IGxpbmsgb3IgbWVkaWEgbWF5IGJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IHNoYXJlZC4mbmJzcDsgVHlwaWNhbGx5IGhvc3Rz
IChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29yaywgbGlrZSBXaS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgRmkgb3Ig
RXRoZXJuZXQsIHdpbGwgYWNxdWlyZSB1bmlxdWUgSVB2NiBhZGRyZXNzZXMgZnJvbSBhIGNvbW1v
biBJUHY2PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7IHByZWZpeCB0aGF0IGlzIGFsbG9jYXRlZCBvciBhc3NpZ25lZCBmb3IgdXNl
IG9uIGEgc3BlY2lmaWMgbGluay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgQmVuZWZpdHMgb2YgYSB1bmlxdWUgSVB2NiBwcmVm
aXggY29tcGFyZWQgdG8gYSB1bmlxdWUgSVB2NiBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IGZyb20gdGhlIHNlcnZp
Y2UgcHJvdmlkZXIgYXJlIGdvaW5nIGZyb20gZW5oYW5jZWQgc3Vic2NyaWJlcjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBtYW5h
Z2VtZW50IHRvIGltcHJvdmVkIGlzb2xhdGlvbiBiZXR3ZWVuIHN1YnNjcmliZXJzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyBJbiBtb3N0IGRlcGxveW1lbnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZy
b20gYSBzaW5nbGUgSVB2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyBwcmVmaXggb24gYSBzaGFyZWQgbmV0d29yayBpcyBkb25l
IGJ5IGVpdGhlciB1c2luZyBJUHY2IHN0YXRlbGVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBhZGRyZXNzIGF1dG8tY29uZmln
dXJhdGlvbiAoU0xBQUMpIGFuZC9vciBzdGF0ZWZ1bCBESENQdjYuJm5ic3A7IFdoaWxlPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
IHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCB0aGVyZSBhcmUg
c29tZSBsYXJnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyBzY2FsZSBlbnZpcm9ubWVudHMgd2hlcmUgdGhpcyBjb25jZXB0IGlu
dHJvZHVjZXMgc2lnbmlmaWNhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgcGVyZm9ybWFuY2UgY2hhbGxlbmdlcyBhbmQgaW1w
bGljYXRpb25zLCBzcGVjaWZpY2FsbHkgcmVsYXRlZCB0byBJUHY2PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IHJvdXRlciBhbmQg
bmVpZ2hib3IgZGlzY292ZXJ5LiZuYnNwOyBUaGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJv
YWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7IHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scyB0byBhbGxvdyBob3N0
cyB0byBiZSBhc3NpZ25lZCBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBh
IHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBJUHY2IHByZWZpeCkuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg
aXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamptYi12
Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvIj5odHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC88
L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVl
LWlwdjYtcHJlZml4LXBlci1ob3N0LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDA8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g
dGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIj50b29scy5p
ZXRmLm9yZzwvYT4uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh
bm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkktRC1Bbm5vdW5jZSBtYWls
aW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIj5JLUQtQW5ub3Vu
Y2VAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pLWQtYW5ub3VuY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
aS1kLWFubm91bmNlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRw
Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o
dG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPm9yIDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu
dHh0Ij5mdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+djZvcHMgbWFpbGluZyBsaXN0PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEg
aHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2
Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2
b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
djZvcHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_2134F8430051B64F815C691A62D9831832F2B2A1XCHBLV504nwnosb_--



From nobody Wed Oct 21 11:47:35 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FB31A90FE for ; Wed, 21 Oct 2015 11:47:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTBreGlDTsxd for ; Wed, 21 Oct 2015 11:47:29 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E260D1A8849 for ; Wed, 21 Oct 2015 11:47:28 -0700 (PDT)
Received: by qkbl190 with SMTP id l190so43246788qkb.2 for ; Wed, 21 Oct 2015 11:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QPcNDjvbwebaPn6h7tC77zMjhmnpa55dWk7XCoJeHrM=; b=c2ZPiFsq9im+2xBeA2LmG0x1KWwi8UrZPW1MBhCFDHiHOQx82tEbJrajuuuFoQVuu5 ZvJK5E5K2gxJueFMDOu+Swtcp5sYC1P7Drj7hgR1VLHSwC3rQl/td9S0SceKGIvGfIEq W4p4P0sio2Xe/MgzSQ3MiZLVFDN8MO5SiuId8UnkNsK+6uwHQSXK5nB785pwh1CefoRj AMKa9rP03ycfgKTsgpTm0zFEaPZb7gUpAcr1Xm3P0M+70Qg6ETZ8QZZKF1T0hy1HK5TP 8sde7RCqzochWbo87rrzGOyONPYWJs/DVB34RvKejjMl2JLeY9//aNycfpKPfVacQOyD Hfcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QPcNDjvbwebaPn6h7tC77zMjhmnpa55dWk7XCoJeHrM=; b=UJhJzoCKbHvI4nNJSt3Lkh86ZxAYSlMtLHBJiZOPKbi7k3v+BsW60ve46fjubcz4CB X3029lH3UutNrmx8UIvH/qeyBu+x8Rs6/QYFu3nylyUEwyJtGk1k9xl4kgX1jc6EfBQM Klq92WPtVfIdy7SDzLEUuz2RLfE2Y2MQbR9K//ynzTPTxUCVpQVxAEKwzsQgpAwDfesv 4FM5Azf5toUdcDlscG47PAQKjVhfq+sbV/Fpcshbcg8GaiCIHxR5owkL1yelgVlohnXx gc72gPut7UqhBcYVWgrutTzCKR2DpFdfHeZz7x7k2wSjgA/BTQHlfKCIbvvsA4cfyYxO EwOw==
X-Gm-Message-State: ALoCoQkRpPIrh5vLHhpdopeZXG8sPYUl3Kdc9Ix/siP/NKzPDi7Un+YVgGvMsqssRJqdDNbjHHvd
X-Received: by 10.55.41.93 with SMTP id p90mr12874118qkh.14.1445453247967; Wed, 21 Oct 2015 11:47:27 -0700 (PDT)
Received: from [10.132.40.235] ([173.38.117.67]) by smtp.gmail.com with ESMTPSA id y14sm3407916qky.4.2015.10.21.11.47.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Oct 2015 11:47:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-8EDFD5E7-8F02-42EC-9705-489984D1F375
Mime-Version: 1.0 (1.0)
From: Victor Kuarsingh 
X-Mailer: iPhone Mail (13A452)
In-Reply-To: 
Date: Wed, 21 Oct 2015 14:47:26 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <4121F793-D794-4266-90BE-33427ACC0CC0@jvknet.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5626E1C6.8050209@jvknet.com>  <2134F8430051B64F815C691A62D9831832F2AE10@XCH-BLV-504.nw.nos.boeing.com> 
To: "Brzozowski, John" , v6ops@ietf.org
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 18:47:33 -0000

--Apple-Mail-8EDFD5E7-8F02-42EC-9705-489984D1F375
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

WG Chairs,

I would be interested in discussing this topic.  Since this draft documents a=
 real world IPv6 deployment and a real world solution,  I think it has value=
.  WiFi deployments are growing in number,  so it's timely.

I also think the notion of using existing protocols and working models is of=
 importance and relevance in the operator space.

The flow through conversation in how this topic intersects with AERO is also=
 of interest.

Regards,

Victor K

Sent from my iPhone

> On Oct 21, 2015, at 11:45, Brzozowski, John  wrote:
>=20
> Fred,
>=20
> Replying here instead of off list.  I took a quick look at the draft and a=
dmit there are some aspects of the draft that seem similar to what we have d=
one.  However, there is a lot more to AERO than what we need.  We utilize ex=
isting protocols and developed no extensions to the same, there seems to be s=
ome new development related to AERO.
>=20
> Our approach for PD, which is a futures item is basically what we know tod=
ay for PD, RFC3633.  We saw no need to reinvent the wheel nor do we intend t=
o.
>=20
> I look forward to hearing more about AERO, its use cases, and available im=
plementations in Yokohama.
>=20
> John
> +1-484-962-0060
>=20
> From: Fred Templin 
> Date: Wednesday, October 21, 2015 at 10:38
> To: John Jason Brzozowski , Victor Kuar=
singh 
> Cc: v6ops 
> Subject: RE: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-=
per-host-00.txt
>=20
> Hi, what this draft is discussing is already covered in AERO, where DHCPv6=
 PD is
> used to delegate a unique IPv6 prefix per host. Please refer to that docum=
ent:
> =20
> https://datatracker.ietf.org/doc/draft-templin-aerolink/
> =20
> AERO has been presented at the past 4 IETFs in the dmm working group
> (charts available in proceedings). =46rom some of the recent discussions o=
n
> multi-addressing and prefix delegation it sounds like it should also be
> presented in v6ops.
> =20
> Thanks =E2=80=93 Fred
> fred.l.templin@boeing.com
> =20
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brzozowski, John
> Sent: Tuesday, October 20, 2015 6:31 PM
> To: Victor Kuarsingh
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-=
per-host-00.txt
> =20
> Thanks Victor.  I will confer with Gunter on some text.
> =20
> As an aside I view the WLAN-GW as I would a CMTS in DOCSIS networks.  The W=
LAN-GW IPv6 capacity would have to be managed similar to how we manage block=
 sizes for prefix delegation.  The parent IPv6 block would have to be able t=
o a accommodate the overall capacity of the WLAN-GW.
> =20
> Once a WLAN-GW reaches capacity either from a bandwidth point of view, IPv=
6 prefixes, etc. the WLAN-GW split would need to occur.
> =20
> One more note, the WLAN-GW would only advertise the parent IPv6 block to a=
void route table bloat.  Perhaps this should be listed as another operationa=
l consideration.
>=20
> John
> +1-484-962-0060
>=20
> On Oct 20, 2015, at 20:52, Victor Kuarsingh  wrote:
>=20
> John/Gunter,
>=20
> Overall, good draft, well explained case and detailed explanation of deplo=
yment.
>=20
> On to comment...
>=20
> Based on this text .. "The /64
>    prefix can be derived from a locally managed pool or aggregate IPv6
>    block assigned to the WLAN-GW or from a pool signalled by the Radius
>    server in a radius attribute."
>=20
> Its seems clear that the /64s would come from a pool and/or block as you n=
oted. =20
>=20
> I would think that under the operational considerations section we would w=
ant to add some text that notes the management requirements to size/manage t=
hose blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the nu=
mber of addresses that can be consumed by that one /64 would not require man=
agement. =20
>=20
> However, in this case, it's possible to exhaust the #  of blocks.  If the W=
LAN-GW is L3, then in large venues - say stadiums or open areas, sizing for p=
eak demand periods would need to be considered as well.  Sizing/management i=
s likely not as much of an issue in the "coffee shop" deployment instance.
>=20
>=20
> The text need not be complicated, but should note that some attention / ma=
nagement is required.
>=20
> regards,
>=20
> Victor K
>=20
>=20
>=20
>=20
> On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:
> Posted yesterday. Your comment solicited.
> =20
> Begin forwarded message:
> =20
> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> Date: October 19, 2015 at 12:50:01 PM PDT
> To: 
> Reply-To: internet-drafts@ietf.org
> =20
> =20
> A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
> =20
> =20
>        Title           : Unique IPv6 Prefix Per Host
>        Authors         : John Jason Brzozowski
>                          Gunter Van De Velde
>     Filename        : draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>     Pages           : 14
>     Date            : 2015-10-19
> =20
> Abstract:
>   In some IPv6 environments the need has arisen for hosts to be able to
>   utilise a unique IPv6 prefix even though the link or media may be
>   shared.  Typically hosts (subscribers) on a shared network, like Wi-
>   Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6
>   prefix that is allocated or assigned for use on a specific link.
>   Benefits of a unique IPv6 prefix compared to a unique IPv6 address
>   from the service provider are going from enhanced subscriber
>   management to improved isolation between subscribers.
> =20
>   In most deployments today IPv6 address assignment from a single IPv6
>   prefix on a shared network is done by either using IPv6 stateless
>   address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
>   this is still viable and operates as designed there are some large
>   scale environments where this concept introduces significant
>   performance challenges and implications, specifically related to IPv6
>   router and neighbor discovery.  This document outlines an approach
>   utilising existing IPv6 protocols to allow hosts to be assigned a
>   unique IPv6 prefix (instead of a unique IPv6 address from a shared
>   IPv6 prefix).
> =20
> =20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-h=
ost/
> =20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-0=
0
> =20
> =20
> Please note that it may take a couple of minutes from the time of submissi=
on
> until the htmlized version and diff are available at tools.ietf.org.
> =20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> =20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=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

--Apple-Mail-8EDFD5E7-8F02-42EC-9705-489984D1F375
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


WG Chairs,

I would be interested in d=
iscussing this topic.  Since this draft documents a real world IPv6 dep=
loyment and a real world solution,  I think it has value.  WiFi de=
ployments are growing in number,  so it's timely.

I also think the not=
ion of using existing protocols and working models is of importance and rele=
vance in the operator space.

<=
div id=3D"AppleMailSignature">The flow through conversation in how this topi=
c intersects with AERO is also of interest.

Regards,

Victor K

Sent f=
rom my iPhone

On Oct 21, 2015, at 11:45, Brzozowski, John <=
John_Brzozowski@Cable.C=
omcast.com> wrote:











Fred,







Replying here instead of off list.  I took a quick look at the dra=
ft and admit there are some aspects of the draft that seem similar to what w=
e have done.  However, there is a lot more to AERO than what we need. &=
nbsp;We utilize existing protocols and developed
 no extensions to the same, there seems to be some new development related t=
o AERO.







Our approach for PD, which is a futures item is basically what we know t=
oday for PD, RFC3633.  We saw no need to reinvent the wheel nor do we i=
ntend to.







I look forward to hearing more about AERO, its use cases, and available=
 implementations in Yokohama.









John


+1-484-962-0060















From: Fred Templin <Fred.L.Templin@boeing.com>

Date: Wednesday, October 21, 2015 at=
 10:38

To: John Jason Brzozowski <john_brzozowski@cable.comcast=
.com>, Victor Kuarsingh <vict=
or@jvknet.com>

Cc: v6ops <v6ops@ietf.org>

Subject: RE: [v6ops] Fwd: I-D Action=
: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt



















Hi, what this draft is discussing is a=
lready covered in AERO, where DHCPv6 PD is


used to delegate a unique IPv6 prefix=
 per host. Please refer to that document:


 


https://datatracker.ietf.org/doc/draft-templ=
in-aerolink/


 


AERO has been presented at the past 4=
 IETFs in the dmm working group


(charts available in proceedings). =46rom=
 some of the recent discussions on


multi-addressing and prefix delegatio=
n it sounds like it should also be


presented in v6ops.=



 


Thanks =E2=80=93 Fred


fred.l.templin@boeing.com


 








From: v6ops [ma=
ilto:v6ops-bounces@ietf.org]
On Behalf Of Brzozowski, John

Sent: Tuesday, October 20, 2015 6:31 PM

To: Victor Kuarsingh

Cc: v6ops@ietf.org

Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-pr=
efix-per-host-00.txt






 




Thanks Victor.  I will confer with Gunter on som=
e text.






 






As an aside I view the WLAN-GW as I would a CMTS in D=
OCSIS networks.  The WLAN-GW IPv6 capacity would have to be managed sim=
ilar to how we manage block sizes for prefix delegation.  The parent IP=
v6 block would have to be able to a accommodate
 the overall capacity of the WLAN-GW.






 






Once a WLAN-GW reaches capacity either from a bandwid=
th point of view, IPv6 prefixes, etc. the WLAN-GW split would need to occur.=







 






One more note, the WLAN-GW would only advertise the p=
arent IPv6 block to avoid route table bloat.  Perhaps this should be li=
sted as another operational consideration.



John 




+1-484-962-0060










On Oct 20, 2015, at 20:52, Victor Kuarsingh <victor@jvknet.com> wrote:








John/Gunter,



Overall, good draft, well explained case and detailed explanation of deploym=
ent.



On to comment...



Based on this text .. "The /64

   prefix can be derived from a locally managed pool or aggregate I=
Pv6

   block assigned to the WLAN-GW or from a pool signalled by the R=
adius

   server in a radius attribute."



Its seems clear that the /64s would come from a pool and/or block as you not=
ed.  



I would think that under the operational considerations section we would wan=
t to add some text that notes the management requirements to size/manage tho=
se blocks/pools.  Under a traditional case, with a /64 per WLAN-GW, the=
 number of addresses that can be consumed
 by that one /64 would not require management.  



However, in this case, it's possible to exhaust the #  of blocks. =
 If the WLAN-GW is L3, then in large venues - say stadiums or open areas, si=
zing for peak demand periods would need to be considered as well.  Sizi=
ng/management is likely not as much of an issue
 in the "coffee shop" deployment instance.





The text need not be complicated, but should note that some attention / mana=
gement is required.



regards,



Victor K












On 2015-10-20 2:35 PM, Fred Baker (fred) wrote:<=
/o:p>






Posted yesterday. Your comment solicited.


 




Begin forwarded message:


 


From: internet-drafts@ietf.=
org


Subject: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.tx=
t


Date: October 19, 2015 at 12:50:01 PM PDT


To: <i-d-announce@ietf.org&=
gt;


Reply-To: internet-drafts@i=
etf.org


 


 


A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.


 


 


       Title     =
;      : Unique IPv6 Prefix Per Host

       Authors    &nb=
sp;    : John Jason Brzozowski


            =
;             Gu=
nter Van De Velde


    Filename        :=
 draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt


    Pages        =
;   : 14


    Date        =
    : 2015-10-19


 


Abstract:


  In some IPv6 environments the need has arisen for hosts to be ab=
le to


  utilise a unique IPv6 prefix even though the link or media may b=
e


  shared.  Typically hosts (subscribers) on a shared network,=
 like Wi-


  Fi or Ethernet, will acquire unique IPv6 addresses from a common=
 IPv6


  prefix that is allocated or assigned for use on a specific link.=



  Benefits of a unique IPv6 prefix compared to a unique IPv6 addre=
ss


  from the service provider are going from enhanced subscriber


  management to improved isolation between subscribers.=



 


  In most deployments today IPv6 address assignment from a single I=
Pv6


  prefix on a shared network is done by either using IPv6 stateles=
s


  address auto-configuration (SLAAC) and/or stateful DHCPv6. =
 While


  this is still viable and operates as designed there are some lar=
ge


  scale environments where this concept introduces significant


  performance challenges and implications, specifically related to=
 IPv6


  router and neighbor discovery.  This document outlines an a=
pproach


  utilising existing IPv6 protocols to allow hosts to be assigned a=



  unique IPv6 prefix (instead of a unique IPv6 address from a shar=
ed


  IPv6 prefix).


 


 


The IETF datatracker status page for this draft is:


https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique=
-ipv6-prefix-per-host/


 


There's also a htmlized version available at:


https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-pr=
efix-per-host-00


 


 


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.


 


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/inte=
rnet-drafts/


 


_______________________________________________


I-D-Announce mailing list


I-D-Announce@ietf.org=



https://=
www.ietf.org/mailman/listinfo/i-d-announce


Internet-Draft directories: http://www.ietf.org/shadow.html


or ftp://ftp.ietf=
.org/ietf/1shadow-sites.txt













_______________________________________________


v6ops mailing list


v6ops@ietf.org


https://www.iet=
f.org/mailman/listinfo/v6ops




 










_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org=
/mailman/listinfo/v6ops



















=

--Apple-Mail-8EDFD5E7-8F02-42EC-9705-489984D1F375--


From nobody Wed Oct 21 15:03:56 2015
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 65AEF1B3259; Wed, 21 Oct 2015 15:03:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151021220354.26679.47973.idtracker@ietfa.amsl.com>
Date: Wed, 21 Oct 2015 15:03:54 -0700
Archived-At: 
Cc: v6ops@ietf.org
Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-siit-eam-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Oct 2015 22:03:54 -0000

--NextPart

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

    Title         : Explicit Address Mappings for Stateless IP/ICMP Translation
    Author(s)     : T. Anderson, et al
    Filename      : draft-ietf-v6ops-siit-eam
    Pages         : 18 
    Date          : 2015-10-21 
    
   This document extends the Stateless IP/ICMP Translation Algorithm
   (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally
   updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP
   translation between arbitrary (non-IPv4-translatable) IPv6 endpoints
   and IPv4.


A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-v6ops-siit-eam-03.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-v6ops-siit-eam";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2015-10-21150354.I-D@ietf.org>


--NextPart--


From nobody Thu Oct 22 05:47:27 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB941B36B7 for ; Thu, 22 Oct 2015 05:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUnCxIRZjfe for ; Thu, 22 Oct 2015 05:47:23 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2311B36B0 for ; Thu, 22 Oct 2015 05:47:22 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9MClKTl008972 for ; Thu, 22 Oct 2015 14:47:20 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 625DC206821 for ; Thu, 22 Oct 2015 14:53:02 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58E282024CD for ; Thu, 22 Oct 2015 14:53:02 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9MClJrT014435 for ; Thu, 22 Oct 2015 14:47:20 +0200
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>
From: Alexandre Petrescu 
Message-ID: <5628DAD7.1010203@gmail.com>
Date: Thu, 22 Oct 2015 14:47:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 12:47:25 -0000

Hello,

Assigning a prefix-per-host in a WiFi deployment, rather than an 
individual addresses within a same prefix, has also been considered in 
Proxy Mobile IP deployments and it works ok.  It has some advantages, 
and some inconvenients, depending how it's done.

I have some comments on the draft.

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
> If radius server discovers that the UE/ subscriber is a fresh device
> trying to gain access onto the Wi-Fi network it will identify some
> parameters (e.g.  IPv6 /64 prefix)
[...]
 > This RA contains a few important parameters for the EU/ subscriber to
 > consume: (1) a /64 prefix and (2) flags.

I would like to suggest to substitute /63 for /64 throughout the 
document.  A /64 will not allow smartphones to tether cleanly.

For a discussion of why 64 one can refer to RFC7521 "Analysis of 64 
boundary..."

For a discussion of why 63 - where to start?

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>    The WLAN-GW will use the received Radius information to compose the
>    response to the UE/subscriber originated RS message.  The WLAN-GW
>    will answer using a unicast RA (Router Advertisement) to the UE/
>    subscriber.  This RA contains a few important parameters for the EU/
>    subscriber to consume: (1) a /64 prefix and (2) flags.

Since a captive portal is used, it would make sense to use the Captive 
Portal IPv6 RA Option as well (draft-wkumari-dhc-capport-16 LC'ed 
towards RFC end of September).

draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>    When a new UE connects to the community Wi-Fi it connects to the Wi-
>    Fi network by attaching to the relevant 'open' SSID advertised for
>    use as part of the community Wi-Fi offering.

But some community networks use a 'hidden' SSID, known only by members 
of that community.

Yours,

Alex


Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
> Posted yesterday. Your comment solicited.
>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org Subject: I-D Action:
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date: October
>> 19, 2015 at 12:50:01 PM PDT To:  Reply-To:
>> internet-drafts@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title           : Unique IPv6 Prefix Per Host Authors         :
>> John Jason Brzozowski Gunter Van De Velde Filename        :
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14 Date
>> : 2015-10-19
>>
>> Abstract: In some IPv6 environments the need has arisen for hosts
>> to be able to utilise a unique IPv6 prefix even though the link or
>> media may be shared.  Typically hosts (subscribers) on a shared
>> network, like Wi- Fi or Ethernet, will acquire unique IPv6
>> addresses from a common IPv6 prefix that is allocated or assigned
>> for use on a specific link. Benefits of a unique IPv6 prefix
>> compared to a unique IPv6 address from the service provider are
>> going from enhanced subscriber management to improved isolation
>> between subscribers.
>>
>> In most deployments today IPv6 address assignment from a single
>> IPv6 prefix on a shared network is done by either using IPv6
>> stateless address auto-configuration (SLAAC) and/or stateful
>> DHCPv6.  While this is still viable and operates as designed there
>> are some large scale environments where this concept introduces
>> significant performance challenges and implications, specifically
>> related to IPv6 router and neighbor discovery.  This document
>> outlines an approach utilising existing IPv6 protocols to allow
>> hosts to be assigned a unique IPv6 prefix (instead of a unique
>> IPv6 address from a shared IPv6 prefix).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per-host/
>>
>>
>>
>>
There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00
>>
>>
>>
>>
>>
Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ I-D-Announce
>> mailing list I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Oct 22 06:15:44 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402371A88CF for ; Thu, 22 Oct 2015 06:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUJe5Td1hgWL for ; Thu, 22 Oct 2015 06:15:32 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543AF1A88A5 for ; Thu, 22 Oct 2015 06:15:31 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-0d-5628e17164eb
Received: from pacdcexhub04.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 24.52.04607.171E8265; Thu, 22 Oct 2015 09:15:30 -0400 (EDT)
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by pacdcexhub04.cable.comcast.com (24.40.56.121) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 22 Oct 2015 09:15:27 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 22 Oct 2015 09:15:27 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Thu, 22 Oct 2015 09:15:26 -0400
From: "Brzozowski, John" 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwg==
Date: Thu, 22 Oct 2015 13:15:26 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>
In-Reply-To: <5628DAD7.1010203@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.7]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsXiEq4ko1v0UCPM4Mw6YYuTZ56wWZw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo48no/a8Eh+4p5SzqYGxg/2HYxcnJICJhI /PhwnBnCFpO4cG89WxcjF4eQwC4miQ2PDrODJIQE9jJKdF5XhUjsZpQ48/YiO4RzklFiT+8/ NpAqNgEbidcffjKC2CICURJ/LvSzgNjCAtESO7b0s0HEYyRmvWhkgrD1JL5N/Aa2mkVAVeLR t8dg23gF7CUmLpjNDLFgAqPEyV/LWEESnAKaEueXnABbwAh06/dTa8AGMQuIS9x6Mp8J4gcB iSV7zkP9Iyrx8vE/sF5RoGXtp/6zQcQNJLYu3ccCYctJzH19D8jmAJqjKbF+lz6E6SAx4aQA xHRFiSndD6FOE5Q4OfMJWLUQ0MR5D6QhhohLHD6yg3UCo8wsJPfMQpg5C2HmLCQzZyGZuYCR dRWjXEFickpybkZ+aYmBoV5yYlJOql5yfm5yYnEJiN7ECI56+eU7GO+9cDrEKMDBqMTDe+iK RpgQa2JZcWXuIUYJDmYlEd4t94BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeTff+xUqJJCeWJKa nZpakFoEk2Xi4JRqYMzcf3U1k/PJmJfmG76aCJ6OEl2ix3niT+rlFGO2K9srTNu1rvktl7oz 77zp32KJyZnXds+fLiGwdEKa3N651eWphzJ+bsne+H3pntN/2V8u/VxaEnau9mbVttNttdat cvMz24LzeLkXLJqn0vlfOa7xk/z8omcrWnMu/9lWu+q9ZvBlXrb7sVeUWIozEg21mIuKEwG9 vQ5a9gIAAA==
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 13:15:36 -0000

VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBiZWxvdy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs
ZiBvZiBBbGV4YW5kcmUgUGV0cmVzY3UNCjxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0K
RGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMTUgYXQgMDg6NDcNClRvOiB2Nm9wcyA8djZv
cHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246DQpkcmFm
dC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCg0KPkhlbGxv
LA0KPg0KPkFzc2lnbmluZyBhIHByZWZpeC1wZXItaG9zdCBpbiBhIFdpRmkgZGVwbG95bWVudCwg
cmF0aGVyIHRoYW4gYW4NCj5pbmRpdmlkdWFsIGFkZHJlc3NlcyB3aXRoaW4gYSBzYW1lIHByZWZp
eCwgaGFzIGFsc28gYmVlbiBjb25zaWRlcmVkIGluDQo+UHJveHkgTW9iaWxlIElQIGRlcGxveW1l
bnRzIGFuZCBpdCB3b3JrcyBvay4gIEl0IGhhcyBzb21lIGFkdmFudGFnZXMsDQo+YW5kIHNvbWUg
aW5jb252ZW5pZW50cywgZGVwZW5kaW5nIGhvdyBpdCdzIGRvbmUuDQo+DQo+SSBoYXZlIHNvbWUg
Y29tbWVudHMgb24gdGhlIGRyYWZ0Lg0KPg0KPmRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYt
cHJlZml4LXBlci1ob3N0LTAwLnR4dCBzYXlzOg0KPj4gSWYgcmFkaXVzIHNlcnZlciBkaXNjb3Zl
cnMgdGhhdCB0aGUgVUUvIHN1YnNjcmliZXIgaXMgYSBmcmVzaCBkZXZpY2UNCj4+IHRyeWluZyB0
byBnYWluIGFjY2VzcyBvbnRvIHRoZSBXaS1GaSBuZXR3b3JrIGl0IHdpbGwgaWRlbnRpZnkgc29t
ZQ0KPj4gcGFyYW1ldGVycyAoZS5nLiAgSVB2NiAvNjQgcHJlZml4KQ0KPlsuLi5dDQo+ID4gVGhp
cyBSQSBjb250YWlucyBhIGZldyBpbXBvcnRhbnQgcGFyYW1ldGVycyBmb3IgdGhlIEVVLyBzdWJz
Y3JpYmVyIHRvDQo+ID4gY29uc3VtZTogKDEpIGEgLzY0IHByZWZpeCBhbmQgKDIpIGZsYWdzLg0K
Pg0KPkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRvIHN1YnN0aXR1dGUgLzYzIGZvciAvNjQgdGhy
b3VnaG91dCB0aGUNCj5kb2N1bWVudC4gIEEgLzY0IHdpbGwgbm90IGFsbG93IHNtYXJ0cGhvbmVz
IHRvIHRldGhlciBjbGVhbmx5Lg0KW2pqbWJdIEkgYmVsaWV2ZSBhbiBSQSB3aXRoIGEgUElPIG9m
IGEgLzYzIHdpbGwgYmUgcHJvYmxlbWF0aWMsIHdlIGhhdmUNCmFscmVhZHkgdGVzdGVkIHRoZSB1
c2Ugb2YgYSAvNjQgYW5kIHdpbGwgbGlrZWx5IG1haW50YWluIHRoaXMgZm9yIG91cg0KZGVwbG95
bWVudCBvZiBJUHY2IGZvciBjb21tdW5pdHkgV2ktRmkuICBGb3IgdGV0aGVyaW5nIG92ZXIgV2kt
Rmkgb3VyDQpleHBlY3RhdGlvbiBpcyB0aGF0IERIQ1B2NiBQRCB3b3VsZCBiZSB1dGlsaXplZC4N
Cj4NCj5Gb3IgYSBkaXNjdXNzaW9uIG9mIHdoeSA2NCBvbmUgY2FuIHJlZmVyIHRvIFJGQzc1MjEg
IkFuYWx5c2lzIG9mIDY0DQo+Ym91bmRhcnkuLi4iDQo+DQo+Rm9yIGEgZGlzY3Vzc2lvbiBvZiB3
aHkgNjMgLSB3aGVyZSB0byBzdGFydD8NCj4NCj5kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2
LXByZWZpeC1wZXItaG9zdC0wMC50eHQgc2F5czoNCj4+ICAgIFRoZSBXTEFOLUdXIHdpbGwgdXNl
IHRoZSByZWNlaXZlZCBSYWRpdXMgaW5mb3JtYXRpb24gdG8gY29tcG9zZSB0aGUNCj4+ICAgIHJl
c3BvbnNlIHRvIHRoZSBVRS9zdWJzY3JpYmVyIG9yaWdpbmF0ZWQgUlMgbWVzc2FnZS4gIFRoZSBX
TEFOLUdXDQo+PiAgICB3aWxsIGFuc3dlciB1c2luZyBhIHVuaWNhc3QgUkEgKFJvdXRlciBBZHZl
cnRpc2VtZW50KSB0byB0aGUgVUUvDQo+PiAgICBzdWJzY3JpYmVyLiAgVGhpcyBSQSBjb250YWlu
cyBhIGZldyBpbXBvcnRhbnQgcGFyYW1ldGVycyBmb3IgdGhlIEVVLw0KPj4gICAgc3Vic2NyaWJl
ciB0byBjb25zdW1lOiAoMSkgYSAvNjQgcHJlZml4IGFuZCAoMikgZmxhZ3MuDQo+DQo+U2luY2Ug
YSBjYXB0aXZlIHBvcnRhbCBpcyB1c2VkLCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUg
Q2FwdGl2ZQ0KPlBvcnRhbCBJUHY2IFJBIE9wdGlvbiBhcyB3ZWxsIChkcmFmdC13a3VtYXJpLWRo
Yy1jYXBwb3J0LTE2IExDJ2VkDQo+dG93YXJkcyBSRkMgZW5kIG9mIFNlcHRlbWJlcikuDQpbampt
Yl0gd2Ugd2lsbCB0YWtlIGEgbG9vayBhdCB0aGlzIGRyYWZ0IHRvIGRldGVybWluZSBhcHBsaWNh
YmlsaXR5LiAgU3RheQ0KdHVuZWQuDQo+DQo+ZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1w
cmVmaXgtcGVyLWhvc3QtMDAudHh0IHNheXM6DQo+PiAgICBXaGVuIGEgbmV3IFVFIGNvbm5lY3Rz
IHRvIHRoZSBjb21tdW5pdHkgV2ktRmkgaXQgY29ubmVjdHMgdG8gdGhlIFdpLQ0KPj4gICAgRmkg
bmV0d29yayBieSBhdHRhY2hpbmcgdG8gdGhlIHJlbGV2YW50ICdvcGVuJyBTU0lEIGFkdmVydGlz
ZWQgZm9yDQo+PiAgICB1c2UgYXMgcGFydCBvZiB0aGUgY29tbXVuaXR5IFdpLUZpIG9mZmVyaW5n
Lg0KPg0KPkJ1dCBzb21lIGNvbW11bml0eSBuZXR3b3JrcyB1c2UgYSAnaGlkZGVuJyBTU0lELCBr
bm93biBvbmx5IGJ5IG1lbWJlcnMNCj5vZiB0aGF0IGNvbW11bml0eS4NCltqam1iXSBoaWRkZW4g
c2hvdWxkIHdvcmsgYXMgd2VsbCwgcHJvdmlkaW5nIHRoZSBlbmQgdXNlciBrbm93cyB0aGUgbmFt
ZQ0Kb2YgdGhlIFNTSUQuICBXZSB3aWxsIGxvb2sgdG8gc2VlIGlmIHRoZXJlIGFyZSBjbGFyaWZp
Y2F0aW9ucyB3ZSBjYW4gbWFrZQ0KdG8gYWRkcmVzcyB0aGlzLg0KPg0KPllvdXJzLA0KPg0KPkFs
ZXgNCj4NCj4NCj5MZSAyMC8xMC8yMDE1IDIwOjM1LCBGcmVkIEJha2VyIChmcmVkKSBhIMOpY3Jp
dCA6DQo+PiBQb3N0ZWQgeWVzdGVyZGF5LiBZb3VyIGNvbW1lbnQgc29saWNpdGVkLg0KPj4NCj4+
PiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+Pg0KPj4+IEZyb206IGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyBTdWJqZWN0OiBJLUQgQWN0aW9uOg0KPj4+IGRyYWZ0LWpqbWItdjZvcHMtdW5p
cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dCBEYXRlOiBPY3RvYmVyDQo+Pj4gMTksIDIw
MTUgYXQgMTI6NTA6MDEgUE0gUERUIFRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPiBSZXBseS1U
bzoNCj4+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pg0KPj4+DQo+Pj4gQSBOZXcgSW50
ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz
DQo+Pj4gZGlyZWN0b3JpZXMuDQo+Pj4NCj4+Pg0KPj4+IFRpdGxlICAgICAgICAgICA6IFVuaXF1
ZSBJUHY2IFByZWZpeCBQZXIgSG9zdCBBdXRob3JzICAgICAgICAgOg0KPj4+IEpvaG4gSmFzb24g
QnJ6b3pvd3NraSBHdW50ZXIgVmFuIERlIFZlbGRlIEZpbGVuYW1lICAgICAgICA6DQo+Pj4gZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0IFBhZ2VzIDog
MTQgRGF0ZQ0KPj4+IDogMjAxNS0xMC0xOQ0KPj4+DQo+Pj4gQWJzdHJhY3Q6IEluIHNvbWUgSVB2
NiBlbnZpcm9ubWVudHMgdGhlIG5lZWQgaGFzIGFyaXNlbiBmb3IgaG9zdHMNCj4+PiB0byBiZSBh
YmxlIHRvIHV0aWxpc2UgYSB1bmlxdWUgSVB2NiBwcmVmaXggZXZlbiB0aG91Z2ggdGhlIGxpbmsg
b3INCj4+PiBtZWRpYSBtYXkgYmUgc2hhcmVkLiAgVHlwaWNhbGx5IGhvc3RzIChzdWJzY3JpYmVy
cykgb24gYSBzaGFyZWQNCj4+PiBuZXR3b3JrLCBsaWtlIFdpLSBGaSBvciBFdGhlcm5ldCwgd2ls
bCBhY3F1aXJlIHVuaXF1ZSBJUHY2DQo+Pj4gYWRkcmVzc2VzIGZyb20gYSBjb21tb24gSVB2NiBw
cmVmaXggdGhhdCBpcyBhbGxvY2F0ZWQgb3IgYXNzaWduZWQNCj4+PiBmb3IgdXNlIG9uIGEgc3Bl
Y2lmaWMgbGluay4gQmVuZWZpdHMgb2YgYSB1bmlxdWUgSVB2NiBwcmVmaXgNCj4+PiBjb21wYXJl
ZCB0byBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBhcmUN
Cj4+PiBnb2luZyBmcm9tIGVuaGFuY2VkIHN1YnNjcmliZXIgbWFuYWdlbWVudCB0byBpbXByb3Zl
ZCBpc29sYXRpb24NCj4+PiBiZXR3ZWVuIHN1YnNjcmliZXJzLg0KPj4+DQo+Pj4gSW4gbW9zdCBk
ZXBsb3ltZW50cyB0b2RheSBJUHY2IGFkZHJlc3MgYXNzaWdubWVudCBmcm9tIGEgc2luZ2xlDQo+
Pj4gSVB2NiBwcmVmaXggb24gYSBzaGFyZWQgbmV0d29yayBpcyBkb25lIGJ5IGVpdGhlciB1c2lu
ZyBJUHY2DQo+Pj4gc3RhdGVsZXNzIGFkZHJlc3MgYXV0by1jb25maWd1cmF0aW9uIChTTEFBQykg
YW5kL29yIHN0YXRlZnVsDQo+Pj4gREhDUHY2LiAgV2hpbGUgdGhpcyBpcyBzdGlsbCB2aWFibGUg
YW5kIG9wZXJhdGVzIGFzIGRlc2lnbmVkIHRoZXJlDQo+Pj4gYXJlIHNvbWUgbGFyZ2Ugc2NhbGUg
ZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29uY2VwdCBpbnRyb2R1Y2VzDQo+Pj4gc2lnbmlmaWNh
bnQgcGVyZm9ybWFuY2UgY2hhbGxlbmdlcyBhbmQgaW1wbGljYXRpb25zLCBzcGVjaWZpY2FsbHkN
Cj4+PiByZWxhdGVkIHRvIElQdjYgcm91dGVyIGFuZCBuZWlnaGJvciBkaXNjb3ZlcnkuICBUaGlz
IGRvY3VtZW50DQo+Pj4gb3V0bGluZXMgYW4gYXBwcm9hY2ggdXRpbGlzaW5nIGV4aXN0aW5nIElQ
djYgcHJvdG9jb2xzIHRvIGFsbG93DQo+Pj4gaG9zdHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUg
SVB2NiBwcmVmaXggKGluc3RlYWQgb2YgYSB1bmlxdWUNCj4+PiBJUHY2IGFkZHJlc3MgZnJvbSBh
IHNoYXJlZCBJUHY2IHByZWZpeCkuDQo+Pj4NCj4+Pg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2Vy
IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IA0KPj4+aHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
DQo+Pj4taG9zdC8NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVk
IHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+IA0KPj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+Pj4tMDAN
Cj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+Pj4gdW50
aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPj4+IHRv
b2xzLmlldGYub3JnLg0KPj4+DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs
ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k
cmFmdHMvDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXyBJLUQtQW5ub3VuY2UNCj4+PiBtYWlsaW5nIGxpc3QgSS1ELUFubm91bmNlQGlldGYu
b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu
Y2UgSW50ZXJuZXQtRHJhZnQNCj4+PiBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9z
aGFkb3cuaHRtbCBvcg0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu
dHh0DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+DQo+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QN
Cj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
djZvcHMNCj4NCg0K


From nobody Thu Oct 22 06:25:58 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1751D1A8A71 for ; Thu, 22 Oct 2015 06:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKa-p68-iOO5 for ; Thu, 22 Oct 2015 06:25:53 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC721A87CB for ; Thu, 22 Oct 2015 06:25:52 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9MDPlil025607; Thu, 22 Oct 2015 15:25:47 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C73AC2024CD; Thu, 22 Oct 2015 15:31:28 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BAAEF2068D3; Thu, 22 Oct 2015 15:31:28 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9MDPk8t024705; Thu, 22 Oct 2015 15:25:47 +0200
To: "Brzozowski, John" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <5628E3DA.4010905@gmail.com>
Date: Thu, 22 Oct 2015 15:25:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 13:25:57 -0000

Le 22/10/2015 15:15, Brzozowski, John a écrit :
> Thanks for the comments, see below.
>
> -----Original Message-----
>
> From: v6ops  on behalf of Alexandre Petrescu
>   Date: Thursday, October 22, 2015 at
> 08:47 To: v6ops  Subject: Re: [v6ops] Fwd: I-D
> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>> Hello,
>>
>> Assigning a prefix-per-host in a WiFi deployment, rather than an
>> individual addresses within a same prefix, has also been
>> considered in Proxy Mobile IP deployments and it works ok.  It has
>> some advantages, and some inconvenients, depending how it's done.
>>
>> I have some comments on the draft.
>>
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>> If radius server discovers that the UE/ subscriber is a fresh
>>> device trying to gain access onto the Wi-Fi network it will
>>> identify some parameters (e.g.  IPv6 /64 prefix)
>> [...]
>>> This RA contains a few important parameters for the EU/
>>> subscriber to consume: (1) a /64 prefix and (2) flags.
>>
>> I would like to suggest to substitute /63 for /64 throughout the
>> document.  A /64 will not allow smartphones to tether cleanly.
>
> [jjmb] I believe an RA with a PIO of a /63 will be problematic,

Why?

> we have already tested the use of a /64 and will likely maintain
> this for our deployment of IPv6 for community Wi-Fi.

Well it is good for that community.

In this respect, I dont think what the community uses should be an
example for other communities (a BCP).

I use 63 and works fine.

> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
> utilized.

I hear Android not supporting DHCP at this time, so PD would be a pain.

On another hand, just change 64 to 63 will make tethering smartphones
work fine without needing DHCP, nor DHCP-PD.

>> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
>> boundary..."
>>
>> For a discussion of why 63 - where to start?
>>
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>> The WLAN-GW will use the received Radius information to compose
>>> the response to the UE/subscriber originated RS message.  The
>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>> the UE/ subscriber.  This RA contains a few important parameters
>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>> flags.
>>
>> Since a captive portal is used, it would make sense to use the
>> Captive Portal IPv6 RA Option as well
>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
> [jjmb] we will take a look at this draft to determine applicability.
> Stay tuned.
>>
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>> When a new UE connects to the community Wi-Fi it connects to the
>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>> advertised for use as part of the community Wi-Fi offering.
>>
>> But some community networks use a 'hidden' SSID, known only by
>> members of that community.
> [jjmb] hidden should work as well, providing the end user knows the
> name of the SSID.  We will look to see if there are clarifications
> we can make to address this.

Ok.

Alex

>>
>> Yours,
>>
>> Alex
>>
>>
>> Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>>> Posted yesterday. Your comment solicited.
>>>
>>>> Begin forwarded message:
>>>>
>>>> From: internet-drafts@ietf.org Subject: I-D Action:
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>>  Reply-To: internet-drafts@ietf.org
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories.
>>>>
>>>>
>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>> Date : 2015-10-19
>>>>
>>>> Abstract: In some IPv6 environments the need has arisen for
>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>> the link or media may be shared.  Typically hosts
>>>> (subscribers) on a shared network, like Wi- Fi or Ethernet,
>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>> that is allocated or assigned for use on a specific link.
>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>> address from the service provider are going from enhanced
>>>> subscriber management to improved isolation between
>>>> subscribers.
>>>>
>>>> In most deployments today IPv6 address assignment from a single
>>>> IPv6 prefix on a shared network is done by either using IPv6
>>>> stateless address auto-configuration (SLAAC) and/or stateful
>>>> DHCPv6.  While this is still viable and operates as designed
>>>> there are some large scale environments where this concept
>>>> introduces significant performance challenges and implications,
>>>> specifically related to IPv6 router and neighbor discovery.
>>>> This document outlines an approach utilising existing IPv6
>>>> protocols to allow hosts to be assigned a unique IPv6 prefix
>>>> (instead of a unique IPv6 address from a shared IPv6 prefix).
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-per
>>>>
>>>>
>>>>
-host/
>>>>
>>>>
>>>>
>>>>
>> There's also a htmlized version available at:
>>>>
>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host
>>>>
>>>>
>>>>
-00
>>>>
>>>>
>>>>
>>>>
>>>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>>>> until the htmlized version and diff are available at
>>>> tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________ I-D-Announce
>>>> mailing list I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>  ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________ v6ops mailing list
>>  v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>


From nobody Thu Oct 22 06:46:35 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A701A907D for ; Thu, 22 Oct 2015 06:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrl1yKIlZyp9 for ; Thu, 22 Oct 2015 06:46:32 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7146E1A9060 for ; Thu, 22 Oct 2015 06:46:32 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B9A98D7882; Thu, 22 Oct 2015 06:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=/F4Jl75WDE4NdjuxAMEdrNwI9ps=; b= i9p59TJ9ezIFZ2aNAbq9DcOSxue0k1d43uZZwh1rqTu0JRsMl15SfGfWjyTl4ncQ FgPoFVnE2hs80opJn3s2gWihi//PfPEHkC8lZ4V7fuOxNoLXc9KscVLt/xsJg8Vq rdj5g9Ubw2uGxdNVxHGeHFFh5WfKHMpGGvLVJHY1zLY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=oa8IvXpdOocAy+H4C1b4BMY2v1 Na1b9WdVSCVHZep+/miMgiJgnrlcWXoQ7rSjy3a9g94flm8Q79y8v9c53U4Nn3UQ 8HIgXSxS2UwgVftvmbRssSitwbkNwzEDzaskl4v2ov4Ox35+gZDDS2eq5z9vE92y pBstCYMt19BLlgUAc=
Received: from h.hanazo.no (unknown [173.38.220.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 87908D7890; Thu, 22 Oct 2015 06:46:30 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8FCF17B646E; Thu, 22 Oct 2015 15:46:28 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B467BF89-131E-452E-BD3B-C1E185FA5A66"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <5628E3DA.4010905@gmail.com>
Date: Thu, 22 Oct 2015 15:46:27 +0200
Message-Id: <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>
To: Alexandre Petrescu 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 13:46:34 -0000

--Apple-Mail=_B467BF89-131E-452E-BD3B-C1E185FA5A66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Alex,

>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>=20
> Why?

that would violate IPv6 standards. and common implementations don't =
support it either.

e.g.:
=
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_r=
tr.c?rev=3D1.125&content-type=3Dtext/plain

                        /* aggregatable unicast address, rfc2374 */
			if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) =3D=3D=
 0x20
			 && pi->nd_opt_pi_prefix_len !=3D 64) {
				nd6log((LOG_INFO,
				    "nd6_ra_input: invalid prefixlen "
				    "%d for rfc2374 prefix %s, =
ignored\n",
				    pi->nd_opt_pi_prefix_len,
				    inet_ntop(AF_INET6, =
&pi->nd_opt_pi_prefix,
					src, sizeof(src))));
				continue;
			}

cheers,
Ole


--Apple-Mail=_B467BF89-131E-452E-BD3B-C1E185FA5A66
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWKOi0AAoJEL7aWKiYQt92aE4P/0+Wl8bdmHIlMdZrC1Mn0nT6
qLskAjC/bOhZyRJ4jHwSXu2OiL4fwrOPaVxxxMkKhJgizWPAuB6oQ0W6z+3RiEZl
f3fKZGM3QrSG4adSVfDgMVVS93ppo5Xic7hgrsN3N2DU4x0eujoFi0MhdeVDy/WI
6o0PPN5XAK2I65DsawGGCxNQFjTk61D5Dox5vH/YQLi28KnbV3i6JKa8eN9g8L1D
nUOZ3GuaO+fWVQO0BhC3IkNV7yQNYLhMTq14LOrrnp7hEXNU4HsXwzpcWaN2E/rQ
gStgeD6Lr4ILaOfVYjOfKJryWLbZcnrazjhELLgNAxk7JtsWba5iuSlGncv/c0v5
7/OTzH+x/hoYcwiFUo4yg8fdxJgKg5ZqJXq2o2AK/gMAa4btklWKHen4thwkXNTM
Ii3/e/o8O1whrOa2O1ew3wLtUEjPFyNGOMULPxrVINHOX+dMb0JWz1iuE538sd8j
HUMCPXz8zC+sbv7UXLhSC19yIzUG8xgaEytn2LsGREhq+4+OxfZ7FPWTelGyGxk6
ZhrXGSvjXKPDsSlz3PjlrZbJf3i8twIVttOmJAOfBE3eFaS3WbeUby9okLP1+nep
576p9++CjYDyitIih91PTQNKxKnhKMZI12aQ9aKY9KDmyjpK3BCOmT2PlzhSKy6P
hS6vCJ8EnTv5JNLcF4Uc
=dIG2
-----END PGP SIGNATURE-----

--Apple-Mail=_B467BF89-131E-452E-BD3B-C1E185FA5A66--


From nobody Thu Oct 22 07:06:17 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A221ACDF7 for ; Thu, 22 Oct 2015 07:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkCGWu8ck_cr for ; Thu, 22 Oct 2015 07:06:14 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D401ACCFF for ; Thu, 22 Oct 2015 07:06:14 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-98-5628ed549a55
Received: from PACDCEXHUB03.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 0B.FD.04607.45DE8265; Thu, 22 Oct 2015 10:06:12 -0400 (EDT)
Received: from PACDCEX45.cable.comcast.com (24.40.2.144) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 22 Oct 2015 10:06:11 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by pacdcex45.cable.comcast.com (24.40.2.144) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 22 Oct 2015 10:06:10 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Thu, 22 Oct 2015 10:06:10 -0400
From: "Brzozowski, John" 
To: Alexandre Petrescu 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwp53w8cA///INoA=
Date: Thu, 22 Oct 2015 14:06:10 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>
In-Reply-To: <5628E3DA.4010905@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.10]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E77A75EE09DCB409EE9C9B23A469CD4@cable.comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsXiEq4koxvyViPM4MJrZYuTZ56wWZw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4c9ej4FFAxbKLDxgbGG/4dTFyckgImEgs fr+aFcIWk7hwbz1bFyMXh5DALiaJ00fXMEM4exkljmx7wQ7h7GaUeH/gCSOEc5JRYtLi44wg /WwCNhKvP/wEs0UETCV+7HrC0sXIwcEsoCox+w8/SFhYIFpix5Z+NoiSGIlZLxqZIGwrid9f 7rOA2CxA5XM72tlBbF4Be4nmTd1Qi58ySuyddwmsmVNAU+LJsWYwmxHo7u+n1oANYhYQl7j1 ZD4TxD8CEkv2nGeGsEUlXj7+B/anqICeRPup/2wQcQOJrUv3sUDY8hJHJvyDullTYv0ufYiR DhLnOlrYIWxFiSndD6FuE5Q4ORPiRSGgkfMeSENMEZc4fGQH6wRG2VlIDpqFMHQWkqGzkAyd hWToAkbWVYxyBYnJKcm5GfmlJQaGesmJSTmpesn5ucmJxSUgehMjOB3IL9/BeO+F0yFGAQ5G JR7e3681woRYE8uKK3MPMUpwMCuJ8PY/BQrxpiRWVqUW5ccXleakFh9ilOZgURLn3XzvV6iQ QHpiSWp2ampBahFMlomDU6qB8bDgt9v/WPcFfzYQ8K5a41lkuCakh2GL+ax4y9SJvN7TYsxZ hJNt3vBJX3XgWqMnVHwk2M7vquIzlu8vVio/e8B65HrkvnvfHnz7vtDL9mTNN+8NRZLzj2zO OsUwc57P63mnBGp++cj62P6rvmh/2MdS71PNqXbh6dOiF+Xv4OsXWixdU/eZW4mlOCPRUIu5 qDgRAJN57JkDAwAA
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 14:06:16 -0000

T2xlIHJlc3BvbmRlZCB0byB0aGUgdXNlIG9mIHRoZSAvNjMuDQoNClJlZ2FyZGluZyB5b3VyIHVz
ZSBvZiB0aGlzLCBJIGFtIGN1cmlvdXMgd2hpY2ggaW1wbGVtZW50YXRpb24gYW5kIGhvdyBtYW55
DQpkZXZpY2VzIGFyZSBvcGVyYXRpbmcgdXNpbmcgYSAvNjM/DQoNCkZpbmFsbHksIHNvbWVvbmUg
ZnJvbSBHb29nbGUvQW5kcm9pZCB3aWxsIGhhdmUgdG8gY29tbWVudCBvbiBBbmRyb2lkIGFuZA0K
REhDUHY2IGZvciBQRCBzdXBwb3J0LiAgSSBhbHNvIGJlbGlldmUgQXBwbGUgZG9lcyBub3Qgc3Vw
cG9ydCBQRCB5ZXQgb24NCnRoZWlyIGRldmljZXMgZWl0aGVyLiAgTGlrZSB0aGUgZHJhZnQgc2F5
cyB0aGlzIGlzIGZ1dHVyZSB3b3JrLCB3ZSB3aWxsDQpzZWUgd2hlcmUgdGhpcyBnb2VzLg0KDQpK
b2huDQorMS00ODQtOTYyLTAwNjANCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4N
CkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDE1IGF0IDA5OjI1DQpUbzogSm9obiBKYXNv
biBCcnpvem93c2tpIDxqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20+DQpDYzogdjZv
cHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9u
Og0KZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoN
Cj4NCj4NCj5MZSAyMi8xMC8yMDE1IDE1OjE1LCBCcnpvem93c2tpLCBKb2huIGEgw6ljcml0IDoN
Cj4+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBzZWUgYmVsb3cuDQo+Pg0KPj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4+DQo+PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRm
Lm9yZz4gb24gYmVoYWxmIG9mIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPj4gIDxhbGV4YW5kcmUucGV0
cmVzY3VAZ21haWwuY29tPiBEYXRlOiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSBhdA0KPj4g
MDg6NDcgVG86IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFt2Nm9wc10gRndk
OiBJLUQNCj4+IEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
LWhvc3QtMDAudHh0DQo+Pg0KPj4+IEhlbGxvLA0KPj4+DQo+Pj4gQXNzaWduaW5nIGEgcHJlZml4
LXBlci1ob3N0IGluIGEgV2lGaSBkZXBsb3ltZW50LCByYXRoZXIgdGhhbiBhbg0KPj4+IGluZGl2
aWR1YWwgYWRkcmVzc2VzIHdpdGhpbiBhIHNhbWUgcHJlZml4LCBoYXMgYWxzbyBiZWVuDQo+Pj4g
Y29uc2lkZXJlZCBpbiBQcm94eSBNb2JpbGUgSVAgZGVwbG95bWVudHMgYW5kIGl0IHdvcmtzIG9r
LiAgSXQgaGFzDQo+Pj4gc29tZSBhZHZhbnRhZ2VzLCBhbmQgc29tZSBpbmNvbnZlbmllbnRzLCBk
ZXBlbmRpbmcgaG93IGl0J3MgZG9uZS4NCj4+Pg0KPj4+IEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9u
IHRoZSBkcmFmdC4NCj4+Pg0KPj4+IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4
LXBlci1ob3N0LTAwLnR4dCBzYXlzOg0KPj4+PiBJZiByYWRpdXMgc2VydmVyIGRpc2NvdmVycyB0
aGF0IHRoZSBVRS8gc3Vic2NyaWJlciBpcyBhIGZyZXNoDQo+Pj4+IGRldmljZSB0cnlpbmcgdG8g
Z2FpbiBhY2Nlc3Mgb250byB0aGUgV2ktRmkgbmV0d29yayBpdCB3aWxsDQo+Pj4+IGlkZW50aWZ5
IHNvbWUgcGFyYW1ldGVycyAoZS5nLiAgSVB2NiAvNjQgcHJlZml4KQ0KPj4+IFsuLi5dDQo+Pj4+
IFRoaXMgUkEgY29udGFpbnMgYSBmZXcgaW1wb3J0YW50IHBhcmFtZXRlcnMgZm9yIHRoZSBFVS8N
Cj4+Pj4gc3Vic2NyaWJlciB0byBjb25zdW1lOiAoMSkgYSAvNjQgcHJlZml4IGFuZCAoMikgZmxh
Z3MuDQo+Pj4NCj4+PiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0byBzdWJzdGl0dXRlIC82MyBm
b3IgLzY0IHRocm91Z2hvdXQgdGhlDQo+Pj4gZG9jdW1lbnQuICBBIC82NCB3aWxsIG5vdCBhbGxv
dyBzbWFydHBob25lcyB0byB0ZXRoZXIgY2xlYW5seS4NCj4+DQo+PiBbamptYl0gSSBiZWxpZXZl
IGFuIFJBIHdpdGggYSBQSU8gb2YgYSAvNjMgd2lsbCBiZSBwcm9ibGVtYXRpYywNCj4NCj5XaHk/
DQo+DQo+PiB3ZSBoYXZlIGFscmVhZHkgdGVzdGVkIHRoZSB1c2Ugb2YgYSAvNjQgYW5kIHdpbGwg
bGlrZWx5IG1haW50YWluDQo+PiB0aGlzIGZvciBvdXIgZGVwbG95bWVudCBvZiBJUHY2IGZvciBj
b21tdW5pdHkgV2ktRmkuDQo+DQo+V2VsbCBpdCBpcyBnb29kIGZvciB0aGF0IGNvbW11bml0eS4N
Cj4NCj5JbiB0aGlzIHJlc3BlY3QsIEkgZG9udCB0aGluayB3aGF0IHRoZSBjb21tdW5pdHkgdXNl
cyBzaG91bGQgYmUgYW4NCj5leGFtcGxlIGZvciBvdGhlciBjb21tdW5pdGllcyAoYSBCQ1ApLg0K
Pg0KPkkgdXNlIDYzIGFuZCB3b3JrcyBmaW5lLg0KPg0KPj4gRm9yIHRldGhlcmluZyBvdmVyIFdp
LUZpIG91ciBleHBlY3RhdGlvbiBpcyB0aGF0IERIQ1B2NiBQRCB3b3VsZCBiZQ0KPj4gdXRpbGl6
ZWQuDQo+DQo+SSBoZWFyIEFuZHJvaWQgbm90IHN1cHBvcnRpbmcgREhDUCBhdCB0aGlzIHRpbWUs
IHNvIFBEIHdvdWxkIGJlIGEgcGFpbi4NCj4NCj5PbiBhbm90aGVyIGhhbmQsIGp1c3QgY2hhbmdl
IDY0IHRvIDYzIHdpbGwgbWFrZSB0ZXRoZXJpbmcgc21hcnRwaG9uZXMNCj53b3JrIGZpbmUgd2l0
aG91dCBuZWVkaW5nIERIQ1AsIG5vciBESENQLVBELg0KPg0KPj4+IEZvciBhIGRpc2N1c3Npb24g
b2Ygd2h5IDY0IG9uZSBjYW4gcmVmZXIgdG8gUkZDNzUyMSAiQW5hbHlzaXMgb2YgNjQNCj4+PiBi
b3VuZGFyeS4uLiINCj4+Pg0KPj4+IEZvciBhIGRpc2N1c3Npb24gb2Ygd2h5IDYzIC0gd2hlcmUg
dG8gc3RhcnQ/DQo+Pj4NCj4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w
ZXItaG9zdC0wMC50eHQgc2F5czoNCj4+Pj4gVGhlIFdMQU4tR1cgd2lsbCB1c2UgdGhlIHJlY2Vp
dmVkIFJhZGl1cyBpbmZvcm1hdGlvbiB0byBjb21wb3NlDQo+Pj4+IHRoZSByZXNwb25zZSB0byB0
aGUgVUUvc3Vic2NyaWJlciBvcmlnaW5hdGVkIFJTIG1lc3NhZ2UuICBUaGUNCj4+Pj4gV0xBTi1H
VyB3aWxsIGFuc3dlciB1c2luZyBhIHVuaWNhc3QgUkEgKFJvdXRlciBBZHZlcnRpc2VtZW50KSB0
bw0KPj4+PiB0aGUgVUUvIHN1YnNjcmliZXIuICBUaGlzIFJBIGNvbnRhaW5zIGEgZmV3IGltcG9y
dGFudCBwYXJhbWV0ZXJzDQo+Pj4+IGZvciB0aGUgRVUvIHN1YnNjcmliZXIgdG8gY29uc3VtZTog
KDEpIGEgLzY0IHByZWZpeCBhbmQgKDIpDQo+Pj4+IGZsYWdzLg0KPj4+DQo+Pj4gU2luY2UgYSBj
YXB0aXZlIHBvcnRhbCBpcyB1c2VkLCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUNCj4+
PiBDYXB0aXZlIFBvcnRhbCBJUHY2IFJBIE9wdGlvbiBhcyB3ZWxsDQo+Pj4gKGRyYWZ0LXdrdW1h
cmktZGhjLWNhcHBvcnQtMTYgTEMnZWQgdG93YXJkcyBSRkMgZW5kIG9mIFNlcHRlbWJlcikuDQo+
PiBbamptYl0gd2Ugd2lsbCB0YWtlIGEgbG9vayBhdCB0aGlzIGRyYWZ0IHRvIGRldGVybWluZSBh
cHBsaWNhYmlsaXR5Lg0KPj4gU3RheSB0dW5lZC4NCj4+Pg0KPj4+IGRyYWZ0LWpqbWItdjZvcHMt
dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dCBzYXlzOg0KPj4+PiBXaGVuIGEgbmV3
IFVFIGNvbm5lY3RzIHRvIHRoZSBjb21tdW5pdHkgV2ktRmkgaXQgY29ubmVjdHMgdG8gdGhlDQo+
Pj4+IFdpLSBGaSBuZXR3b3JrIGJ5IGF0dGFjaGluZyB0byB0aGUgcmVsZXZhbnQgJ29wZW4nIFNT
SUQNCj4+Pj4gYWR2ZXJ0aXNlZCBmb3IgdXNlIGFzIHBhcnQgb2YgdGhlIGNvbW11bml0eSBXaS1G
aSBvZmZlcmluZy4NCj4+Pg0KPj4+IEJ1dCBzb21lIGNvbW11bml0eSBuZXR3b3JrcyB1c2UgYSAn
aGlkZGVuJyBTU0lELCBrbm93biBvbmx5IGJ5DQo+Pj4gbWVtYmVycyBvZiB0aGF0IGNvbW11bml0
eS4NCj4+IFtqam1iXSBoaWRkZW4gc2hvdWxkIHdvcmsgYXMgd2VsbCwgcHJvdmlkaW5nIHRoZSBl
bmQgdXNlciBrbm93cyB0aGUNCj4+IG5hbWUgb2YgdGhlIFNTSUQuICBXZSB3aWxsIGxvb2sgdG8g
c2VlIGlmIHRoZXJlIGFyZSBjbGFyaWZpY2F0aW9ucw0KPj4gd2UgY2FuIG1ha2UgdG8gYWRkcmVz
cyB0aGlzLg0KPg0KPk9rLg0KPg0KPkFsZXgNCj4NCj4+Pg0KPj4+IFlvdXJzLA0KPj4+DQo+Pj4g
QWxleA0KPj4+DQo+Pj4NCj4+PiBMZSAyMC8xMC8yMDE1IDIwOjM1LCBGcmVkIEJha2VyIChmcmVk
KSBhIMOpY3JpdCA6DQo+Pj4+IFBvc3RlZCB5ZXN0ZXJkYXkuIFlvdXIgY29tbWVudCBzb2xpY2l0
ZWQuDQo+Pj4+DQo+Pj4+PiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+Pj4+DQo+Pj4+PiBG
cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgU3ViamVjdDogSS1EIEFjdGlvbjoNCj4+Pj4+
IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dCBEYXRl
Og0KPj4+Pj4gT2N0b2JlciAxOSwgMjAxNSBhdCAxMjo1MDowMSBQTSBQRFQgVG86DQo+Pj4+PiA8
aS1kLWFubm91bmNlQGlldGYub3JnPiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm
cm9tIHRoZSBvbi1saW5lDQo+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4+
Pg0KPj4+Pj4NCj4+Pj4+IFRpdGxlICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIg
SG9zdCBBdXRob3JzIDogSm9obg0KPj4+Pj4gSmFzb24gQnJ6b3pvd3NraSBHdW50ZXIgVmFuIERl
IFZlbGRlIEZpbGVuYW1lICAgICAgICA6DQo+Pj4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p
cHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgUGFnZXMgOiAxNA0KPj4+Pj4gRGF0ZSA6IDIwMTUt
MTAtMTkNCj4+Pj4+DQo+Pj4+PiBBYnN0cmFjdDogSW4gc29tZSBJUHY2IGVudmlyb25tZW50cyB0
aGUgbmVlZCBoYXMgYXJpc2VuIGZvcg0KPj4+Pj4gaG9zdHMgdG8gYmUgYWJsZSB0byB1dGlsaXNl
IGEgdW5pcXVlIElQdjYgcHJlZml4IGV2ZW4gdGhvdWdoDQo+Pj4+PiB0aGUgbGluayBvciBtZWRp
YSBtYXkgYmUgc2hhcmVkLiAgVHlwaWNhbGx5IGhvc3RzDQo+Pj4+PiAoc3Vic2NyaWJlcnMpIG9u
IGEgc2hhcmVkIG5ldHdvcmssIGxpa2UgV2ktIEZpIG9yIEV0aGVybmV0LA0KPj4+Pj4gd2lsbCBh
Y3F1aXJlIHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBmcm9tIGEgY29tbW9uIElQdjYgcHJlZml4DQo+
Pj4+PiB0aGF0IGlzIGFsbG9jYXRlZCBvciBhc3NpZ25lZCBmb3IgdXNlIG9uIGEgc3BlY2lmaWMg
bGluay4NCj4+Pj4+IEJlbmVmaXRzIG9mIGEgdW5pcXVlIElQdjYgcHJlZml4IGNvbXBhcmVkIHRv
IGEgdW5pcXVlIElQdjYNCj4+Pj4+IGFkZHJlc3MgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBh
cmUgZ29pbmcgZnJvbSBlbmhhbmNlZA0KPj4+Pj4gc3Vic2NyaWJlciBtYW5hZ2VtZW50IHRvIGlt
cHJvdmVkIGlzb2xhdGlvbiBiZXR3ZWVuDQo+Pj4+PiBzdWJzY3JpYmVycy4NCj4+Pj4+DQo+Pj4+
PiBJbiBtb3N0IGRlcGxveW1lbnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20g
YSBzaW5nbGUNCj4+Pj4+IElQdjYgcHJlZml4IG9uIGEgc2hhcmVkIG5ldHdvcmsgaXMgZG9uZSBi
eSBlaXRoZXIgdXNpbmcgSVB2Ng0KPj4+Pj4gc3RhdGVsZXNzIGFkZHJlc3MgYXV0by1jb25maWd1
cmF0aW9uIChTTEFBQykgYW5kL29yIHN0YXRlZnVsDQo+Pj4+PiBESENQdjYuICBXaGlsZSB0aGlz
IGlzIHN0aWxsIHZpYWJsZSBhbmQgb3BlcmF0ZXMgYXMgZGVzaWduZWQNCj4+Pj4+IHRoZXJlIGFy
ZSBzb21lIGxhcmdlIHNjYWxlIGVudmlyb25tZW50cyB3aGVyZSB0aGlzIGNvbmNlcHQNCj4+Pj4+
IGludHJvZHVjZXMgc2lnbmlmaWNhbnQgcGVyZm9ybWFuY2UgY2hhbGxlbmdlcyBhbmQgaW1wbGlj
YXRpb25zLA0KPj4+Pj4gc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2NiByb3V0ZXIgYW5kIG5l
aWdoYm9yIGRpc2NvdmVyeS4NCj4+Pj4+IFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9h
Y2ggdXRpbGlzaW5nIGV4aXN0aW5nIElQdjYNCj4+Pj4+IHByb3RvY29scyB0byBhbGxvdyBob3N0
cyB0byBiZSBhc3NpZ25lZCBhIHVuaXF1ZSBJUHY2IHByZWZpeA0KPj4+Pj4gKGluc3RlYWQgb2Yg
YSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLg0KPj4+Pj4N
Cj4+Pj4+DQo+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk
cmFmdCBpczoNCj4+Pj4+DQo+Pj4+PiANCj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcA0KPj4+Pj5lcg0KPj4+
Pj4NCj4+Pj4+DQo+Pj4+Pg0KPi1ob3N0Lw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+
PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4+DQo+
Pj4+PiANCj4+Pj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMt
dW5pcXVlLWlwdjYtcHJlZml4LXBlci1obw0KPj4+Pj5zdA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0K
Pi0wMA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4gUGxlYXNlIG5vdGUg
dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+
PiBzdWJtaXNzaW9uDQo+Pj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh
cmUgYXZhaWxhYmxlIGF0DQo+Pj4+PiB0b29scy5pZXRmLm9yZy4NCj4+Pj4+DQo+Pj4+PiBJbnRl
cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+
PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4NCj4+Pj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEktRC1Bbm5vdW5jZQ0K
Pj4+Pj4gbWFpbGluZyBsaXN0IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+Pj4+IEludGVybmV0
LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+
Pj4+PiAgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+Pj4NCj4+
Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18gdjZvcHMgbWFpbGluZw0KPj4+PiBsaXN0IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+Pj4NCj4+Pg0KPj4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlz
dA0KPj4+ICB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3Y2b3BzDQo+Pj4NCj4+DQo+DQo+DQoNCg==


From nobody Thu Oct 22 08:48:39 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBCF1A896D for ; Thu, 22 Oct 2015 08:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTms2q5NpcsH for ; Thu, 22 Oct 2015 08:48:24 -0700 (PDT)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E971A6F84 for ; Thu, 22 Oct 2015 08:48:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9MFmQfx026348; Thu, 22 Oct 2015 08:48:26 -0700
Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9MFmMJN026321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 22 Oct 2015 08:48:22 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.147]) with mapi id 14.03.0235.001;  Thu, 22 Oct 2015 08:48:19 -0700
From: "Templin, Fred L" 
To: "Brzozowski, John" , Alexandre Petrescu 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMfJ/+MZsnq7pUCTitCxpFGwKp538zcAgAAC4wCAAAtKAP//pbGA
Date: Thu, 22 Oct 2015 15:48:19 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2C4A3@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 15:48:30 -0000

SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21h
aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJ6b3pvd3NraSwgSm9o
bg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSA3OjA2IEFNDQo+IFRvOiBBbGV4
YW5kcmUgUGV0cmVzY3UNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZv
cHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt
cGVyLWhvc3QtMDAudHh0DQo+IA0KPiBPbGUgcmVzcG9uZGVkIHRvIHRoZSB1c2Ugb2YgdGhlIC82
My4NCj4gDQo+IFJlZ2FyZGluZyB5b3VyIHVzZSBvZiB0aGlzLCBJIGFtIGN1cmlvdXMgd2hpY2gg
aW1wbGVtZW50YXRpb24gYW5kIGhvdyBtYW55DQo+IGRldmljZXMgYXJlIG9wZXJhdGluZyB1c2lu
ZyBhIC82Mz8NCj4gDQo+IEZpbmFsbHksIHNvbWVvbmUgZnJvbSBHb29nbGUvQW5kcm9pZCB3aWxs
IGhhdmUgdG8gY29tbWVudCBvbiBBbmRyb2lkIGFuZA0KPiBESENQdjYgZm9yIFBEIHN1cHBvcnQu
ICBJIGFsc28gYmVsaWV2ZSBBcHBsZSBkb2VzIG5vdCBzdXBwb3J0IFBEIHlldCBvbg0KPiB0aGVp
ciBkZXZpY2VzIGVpdGhlci4gIExpa2UgdGhlIGRyYWZ0IHNheXMgdGhpcyBpcyBmdXR1cmUgd29y
aywgd2Ugd2lsbA0KPiBzZWUgd2hlcmUgdGhpcyBnb2VzLg0KDQpJIGhhdmUgREhDUHY2IFBEIGNs
aWVudCB3b3JraW5nIG9uIEFuZHJvaWQuIEl0IGlzIGp1c3QgYSBmZXcgbWVzc2FnZXMNCmluIHRo
ZSBBRVJPIGNsaWVudCBhcHAsIGFuZCB2ZXJ5IHNpbXBsZS4gWW91IGRvbid0IGV2ZW4gbmVlZCB0
byBpbnN0YWxsDQphIERIQ1B2NiBjbGllbnQgcGFja2FnZSBsaWtlIHdoYXQgeW91IGdldCBmcm9t
IElTQyAtIHRoZSBBRVJPIGNsaWVudA0KYXBwIGRvZXMgYWxsIHRoYXQgaXMgbmVlZGVkLg0KDQpU
aGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gSm9obg0KPiArMS00
ODQtOTYyLTAwNjANCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNv
bT4NCj4gRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMTUgYXQgMDk6MjUNCj4gVG86IEpv
aG4gSmFzb24gQnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPg0K
PiBDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6
IEktRCBBY3Rpb246DQo+IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o
b3N0LTAwLnR4dA0KPiANCj4gPg0KPiA+DQo+ID5MZSAyMi8xMC8yMDE1IDE1OjE1LCBCcnpvem93
c2tpLCBKb2huIGEgw6ljcml0IDoNCj4gPj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBi
ZWxvdy4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4NCj4gPj4g
RnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbGV4YW5k
cmUgUGV0cmVzY3UNCj4gPj4gIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiBEYXRlOiBU
aHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSBhdA0KPiA+PiAwODo0NyBUbzogdjZvcHMgPHY2b3Bz
QGlldGYub3JnPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRA0KPiA+PiBBY3Rpb246IGRy
YWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KPiA+Pg0K
PiA+Pj4gSGVsbG8sDQo+ID4+Pg0KPiA+Pj4gQXNzaWduaW5nIGEgcHJlZml4LXBlci1ob3N0IGlu
IGEgV2lGaSBkZXBsb3ltZW50LCByYXRoZXIgdGhhbiBhbg0KPiA+Pj4gaW5kaXZpZHVhbCBhZGRy
ZXNzZXMgd2l0aGluIGEgc2FtZSBwcmVmaXgsIGhhcyBhbHNvIGJlZW4NCj4gPj4+IGNvbnNpZGVy
ZWQgaW4gUHJveHkgTW9iaWxlIElQIGRlcGxveW1lbnRzIGFuZCBpdCB3b3JrcyBvay4gIEl0IGhh
cw0KPiA+Pj4gc29tZSBhZHZhbnRhZ2VzLCBhbmQgc29tZSBpbmNvbnZlbmllbnRzLCBkZXBlbmRp
bmcgaG93IGl0J3MgZG9uZS4NCj4gPj4+DQo+ID4+PiBJIGhhdmUgc29tZSBjb21tZW50cyBvbiB0
aGUgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm
aXgtcGVyLWhvc3QtMDAudHh0IHNheXM6DQo+ID4+Pj4gSWYgcmFkaXVzIHNlcnZlciBkaXNjb3Zl
cnMgdGhhdCB0aGUgVUUvIHN1YnNjcmliZXIgaXMgYSBmcmVzaA0KPiA+Pj4+IGRldmljZSB0cnlp
bmcgdG8gZ2FpbiBhY2Nlc3Mgb250byB0aGUgV2ktRmkgbmV0d29yayBpdCB3aWxsDQo+ID4+Pj4g
aWRlbnRpZnkgc29tZSBwYXJhbWV0ZXJzIChlLmcuICBJUHY2IC82NCBwcmVmaXgpDQo+ID4+PiBb
Li4uXQ0KPiA+Pj4+IFRoaXMgUkEgY29udGFpbnMgYSBmZXcgaW1wb3J0YW50IHBhcmFtZXRlcnMg
Zm9yIHRoZSBFVS8NCj4gPj4+PiBzdWJzY3JpYmVyIHRvIGNvbnN1bWU6ICgxKSBhIC82NCBwcmVm
aXggYW5kICgyKSBmbGFncy4NCj4gPj4+DQo+ID4+PiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0
byBzdWJzdGl0dXRlIC82MyBmb3IgLzY0IHRocm91Z2hvdXQgdGhlDQo+ID4+PiBkb2N1bWVudC4g
IEEgLzY0IHdpbGwgbm90IGFsbG93IHNtYXJ0cGhvbmVzIHRvIHRldGhlciBjbGVhbmx5Lg0KPiA+
Pg0KPiA+PiBbamptYl0gSSBiZWxpZXZlIGFuIFJBIHdpdGggYSBQSU8gb2YgYSAvNjMgd2lsbCBi
ZSBwcm9ibGVtYXRpYywNCj4gPg0KPiA+V2h5Pw0KPiA+DQo+ID4+IHdlIGhhdmUgYWxyZWFkeSB0
ZXN0ZWQgdGhlIHVzZSBvZiBhIC82NCBhbmQgd2lsbCBsaWtlbHkgbWFpbnRhaW4NCj4gPj4gdGhp
cyBmb3Igb3VyIGRlcGxveW1lbnQgb2YgSVB2NiBmb3IgY29tbXVuaXR5IFdpLUZpLg0KPiA+DQo+
ID5XZWxsIGl0IGlzIGdvb2QgZm9yIHRoYXQgY29tbXVuaXR5Lg0KPiA+DQo+ID5JbiB0aGlzIHJl
c3BlY3QsIEkgZG9udCB0aGluayB3aGF0IHRoZSBjb21tdW5pdHkgdXNlcyBzaG91bGQgYmUgYW4N
Cj4gPmV4YW1wbGUgZm9yIG90aGVyIGNvbW11bml0aWVzIChhIEJDUCkuDQo+ID4NCj4gPkkgdXNl
IDYzIGFuZCB3b3JrcyBmaW5lLg0KPiA+DQo+ID4+IEZvciB0ZXRoZXJpbmcgb3ZlciBXaS1GaSBv
dXIgZXhwZWN0YXRpb24gaXMgdGhhdCBESENQdjYgUEQgd291bGQgYmUNCj4gPj4gdXRpbGl6ZWQu
DQo+ID4NCj4gPkkgaGVhciBBbmRyb2lkIG5vdCBzdXBwb3J0aW5nIERIQ1AgYXQgdGhpcyB0aW1l
LCBzbyBQRCB3b3VsZCBiZSBhIHBhaW4uDQo+ID4NCj4gPk9uIGFub3RoZXIgaGFuZCwganVzdCBj
aGFuZ2UgNjQgdG8gNjMgd2lsbCBtYWtlIHRldGhlcmluZyBzbWFydHBob25lcw0KPiA+d29yayBm
aW5lIHdpdGhvdXQgbmVlZGluZyBESENQLCBub3IgREhDUC1QRC4NCj4gPg0KPiA+Pj4gRm9yIGEg
ZGlzY3Vzc2lvbiBvZiB3aHkgNjQgb25lIGNhbiByZWZlciB0byBSRkM3NTIxICJBbmFseXNpcyBv
ZiA2NA0KPiA+Pj4gYm91bmRhcnkuLi4iDQo+ID4+Pg0KPiA+Pj4gRm9yIGEgZGlzY3Vzc2lvbiBv
ZiB3aHkgNjMgLSB3aGVyZSB0byBzdGFydD8NCj4gPj4+DQo+ID4+PiBkcmFmdC1qam1iLXY2b3Bz
LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgc2F5czoNCj4gPj4+PiBUaGUgV0xB
Ti1HVyB3aWxsIHVzZSB0aGUgcmVjZWl2ZWQgUmFkaXVzIGluZm9ybWF0aW9uIHRvIGNvbXBvc2UN
Cj4gPj4+PiB0aGUgcmVzcG9uc2UgdG8gdGhlIFVFL3N1YnNjcmliZXIgb3JpZ2luYXRlZCBSUyBt
ZXNzYWdlLiAgVGhlDQo+ID4+Pj4gV0xBTi1HVyB3aWxsIGFuc3dlciB1c2luZyBhIHVuaWNhc3Qg
UkEgKFJvdXRlciBBZHZlcnRpc2VtZW50KSB0bw0KPiA+Pj4+IHRoZSBVRS8gc3Vic2NyaWJlci4g
IFRoaXMgUkEgY29udGFpbnMgYSBmZXcgaW1wb3J0YW50IHBhcmFtZXRlcnMNCj4gPj4+PiBmb3Ig
dGhlIEVVLyBzdWJzY3JpYmVyIHRvIGNvbnN1bWU6ICgxKSBhIC82NCBwcmVmaXggYW5kICgyKQ0K
PiA+Pj4+IGZsYWdzLg0KPiA+Pj4NCj4gPj4+IFNpbmNlIGEgY2FwdGl2ZSBwb3J0YWwgaXMgdXNl
ZCwgaXQgd291bGQgbWFrZSBzZW5zZSB0byB1c2UgdGhlDQo+ID4+PiBDYXB0aXZlIFBvcnRhbCBJ
UHY2IFJBIE9wdGlvbiBhcyB3ZWxsDQo+ID4+PiAoZHJhZnQtd2t1bWFyaS1kaGMtY2FwcG9ydC0x
NiBMQydlZCB0b3dhcmRzIFJGQyBlbmQgb2YgU2VwdGVtYmVyKS4NCj4gPj4gW2pqbWJdIHdlIHdp
bGwgdGFrZSBhIGxvb2sgYXQgdGhpcyBkcmFmdCB0byBkZXRlcm1pbmUgYXBwbGljYWJpbGl0eS4N
Cj4gPj4gU3RheSB0dW5lZC4NCj4gPj4+DQo+ID4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p
cHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgc2F5czoNCj4gPj4+PiBXaGVuIGEgbmV3IFVFIGNv
bm5lY3RzIHRvIHRoZSBjb21tdW5pdHkgV2ktRmkgaXQgY29ubmVjdHMgdG8gdGhlDQo+ID4+Pj4g
V2ktIEZpIG5ldHdvcmsgYnkgYXR0YWNoaW5nIHRvIHRoZSByZWxldmFudCAnb3BlbicgU1NJRA0K
PiA+Pj4+IGFkdmVydGlzZWQgZm9yIHVzZSBhcyBwYXJ0IG9mIHRoZSBjb21tdW5pdHkgV2ktRmkg
b2ZmZXJpbmcuDQo+ID4+Pg0KPiA+Pj4gQnV0IHNvbWUgY29tbXVuaXR5IG5ldHdvcmtzIHVzZSBh
ICdoaWRkZW4nIFNTSUQsIGtub3duIG9ubHkgYnkNCj4gPj4+IG1lbWJlcnMgb2YgdGhhdCBjb21t
dW5pdHkuDQo+ID4+IFtqam1iXSBoaWRkZW4gc2hvdWxkIHdvcmsgYXMgd2VsbCwgcHJvdmlkaW5n
IHRoZSBlbmQgdXNlciBrbm93cyB0aGUNCj4gPj4gbmFtZSBvZiB0aGUgU1NJRC4gIFdlIHdpbGwg
bG9vayB0byBzZWUgaWYgdGhlcmUgYXJlIGNsYXJpZmljYXRpb25zDQo+ID4+IHdlIGNhbiBtYWtl
IHRvIGFkZHJlc3MgdGhpcy4NCj4gPg0KPiA+T2suDQo+ID4NCj4gPkFsZXgNCj4gPg0KPiA+Pj4N
Cj4gPj4+IFlvdXJzLA0KPiA+Pj4NCj4gPj4+IEFsZXgNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gTGUg
MjAvMTAvMjAxNSAyMDozNSwgRnJlZCBCYWtlciAoZnJlZCkgYSDDqWNyaXQgOg0KPiA+Pj4+IFBv
c3RlZCB5ZXN0ZXJkYXkuIFlvdXIgY29tbWVudCBzb2xpY2l0ZWQuDQo+ID4+Pj4NCj4gPj4+Pj4g
QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+ID4+Pj4+DQo+ID4+Pj4+IEZyb206IGludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZyBTdWJqZWN0OiBJLUQgQWN0aW9uOg0KPiA+Pj4+PiBkcmFmdC1qam1i
LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgRGF0ZToNCj4gPj4+Pj4g
T2N0b2JlciAxOSwgMjAxNSBhdCAxMjo1MDowMSBQTSBQRFQgVG86DQo+ID4+Pj4+IDxpLWQtYW5u
b3VuY2VAaWV0Zi5vcmc+IFJlcGx5LVRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPj4+
Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy
b20gdGhlIG9uLWxpbmUNCj4gPj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+
Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaXRsZSAgICAgICAgICAgOiBVbmlxdWUgSVB2NiBQcmVm
aXggUGVyIEhvc3QgQXV0aG9ycyA6IEpvaG4NCj4gPj4+Pj4gSmFzb24gQnJ6b3pvd3NraSBHdW50
ZXIgVmFuIERlIFZlbGRlIEZpbGVuYW1lICAgICAgICA6DQo+ID4+Pj4+IGRyYWZ0LWpqbWItdjZv
cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dCBQYWdlcyA6IDE0DQo+ID4+Pj4+
IERhdGUgOiAyMDE1LTEwLTE5DQo+ID4+Pj4+DQo+ID4+Pj4+IEFic3RyYWN0OiBJbiBzb21lIElQ
djYgZW52aXJvbm1lbnRzIHRoZSBuZWVkIGhhcyBhcmlzZW4gZm9yDQo+ID4+Pj4+IGhvc3RzIHRv
IGJlIGFibGUgdG8gdXRpbGlzZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBldmVuIHRob3VnaA0KPiA+
Pj4+PiB0aGUgbGluayBvciBtZWRpYSBtYXkgYmUgc2hhcmVkLiAgVHlwaWNhbGx5IGhvc3RzDQo+
ID4+Pj4+IChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29yaywgbGlrZSBXaS0gRmkgb3Ig
RXRoZXJuZXQsDQo+ID4+Pj4+IHdpbGwgYWNxdWlyZSB1bmlxdWUgSVB2NiBhZGRyZXNzZXMgZnJv
bSBhIGNvbW1vbiBJUHY2IHByZWZpeA0KPiA+Pj4+PiB0aGF0IGlzIGFsbG9jYXRlZCBvciBhc3Np
Z25lZCBmb3IgdXNlIG9uIGEgc3BlY2lmaWMgbGluay4NCj4gPj4+Pj4gQmVuZWZpdHMgb2YgYSB1
bmlxdWUgSVB2NiBwcmVmaXggY29tcGFyZWQgdG8gYSB1bmlxdWUgSVB2Ng0KPiA+Pj4+PiBhZGRy
ZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgYXJlIGdvaW5nIGZyb20gZW5oYW5jZWQNCj4g
Pj4+Pj4gc3Vic2NyaWJlciBtYW5hZ2VtZW50IHRvIGltcHJvdmVkIGlzb2xhdGlvbiBiZXR3ZWVu
DQo+ID4+Pj4+IHN1YnNjcmliZXJzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJbiBtb3N0IGRlcGxveW1l
bnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBzaW5nbGUNCj4gPj4+Pj4g
SVB2NiBwcmVmaXggb24gYSBzaGFyZWQgbmV0d29yayBpcyBkb25lIGJ5IGVpdGhlciB1c2luZyBJ
UHY2DQo+ID4+Pj4+IHN0YXRlbGVzcyBhZGRyZXNzIGF1dG8tY29uZmlndXJhdGlvbiAoU0xBQUMp
IGFuZC9vciBzdGF0ZWZ1bA0KPiA+Pj4+PiBESENQdjYuICBXaGlsZSB0aGlzIGlzIHN0aWxsIHZp
YWJsZSBhbmQgb3BlcmF0ZXMgYXMgZGVzaWduZWQNCj4gPj4+Pj4gdGhlcmUgYXJlIHNvbWUgbGFy
Z2Ugc2NhbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29uY2VwdA0KPiA+Pj4+PiBpbnRyb2R1
Y2VzIHNpZ25pZmljYW50IHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywN
Cj4gPj4+Pj4gc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2NiByb3V0ZXIgYW5kIG5laWdoYm9y
IGRpc2NvdmVyeS4NCj4gPj4+Pj4gVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1
dGlsaXNpbmcgZXhpc3RpbmcgSVB2Ng0KPiA+Pj4+PiBwcm90b2NvbHMgdG8gYWxsb3cgaG9zdHMg
dG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXgNCj4gPj4+Pj4gKGluc3RlYWQgb2Yg
YSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLg0KPiA+Pj4+
Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig
dGhpcyBkcmFmdCBpczoNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj5odHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wDQo+
ID4+Pj4+ZXINCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPi1ob3N0Lw0KPiA+Pj4+Pg0K
PiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg
dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl
ci1obw0KPiA+Pj4+PnN0DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4tMDANCj4gPj4+
Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+IFBsZWFzZSBub3Rl
IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+
ID4+PiBzdWJtaXNzaW9uDQo+ID4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk
aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPj4+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4+Pj4+DQo+
ID4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU
UCBhdDoNCj4gPj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4+
Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18gSS1ELUFubm91bmNlDQo+ID4+Pj4+IG1haWxpbmcgbGlzdCBJLUQtQW5ub3VuY2VAaWV0Zi5v
cmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5u
b3VuY2UNCj4gPj4+Pj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0
Zi5vcmcvc2hhZG93Lmh0bWwgb3INCj4gPj4+Pj4gIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz
aGFkb3ctc2l0ZXMudHh0DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZw0KPiA+
Pj4+IGxpc3QgdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby92Nm9wcw0KPiA+Pj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+PiAgdjZvcHNA
aWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+
Pj4NCj4gPj4NCj4gPg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K


From nobody Thu Oct 22 09:12:31 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007C11A1AB5 for ; Thu, 22 Oct 2015 09:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgcn2pRXCUQA for ; Thu, 22 Oct 2015 09:12:28 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72B41A1AFC for ; Thu, 22 Oct 2015 09:12:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9MGCQNK029718; Thu, 22 Oct 2015 09:12:26 -0700
Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9MGCO9c029324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 22 Oct 2015 09:12:24 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.49]) with mapi id 14.03.0235.001; Thu, 22 Oct 2015 09:12:23 -0700
From: "Templin, Fred L" 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMfJ/+MZsnq7pUCTitCxpFGwKp53rqtQ
Date: Thu, 22 Oct 2015 16:12:23 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2C542@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>
In-Reply-To: <5628DAD7.1010203@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 16:12:30 -0000

Hello,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres=
cu
> Sent: Thursday, October 22, 2015 5:47 AM
> To: v6ops@ietf.org
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix=
-per-host-00.txt
>=20
> Hello,
>=20
> Assigning a prefix-per-host in a WiFi deployment, rather than an
> individual addresses within a same prefix, has also been considered in
> Proxy Mobile IP deployments and it works ok.  It has some advantages,
> and some inconvenients, depending how it's done.
>=20
> I have some comments on the draft.
>=20
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
> > If radius server discovers that the UE/ subscriber is a fresh device
> > trying to gain access onto the Wi-Fi network it will identify some
> > parameters (e.g.  IPv6 /64 prefix)
> [...]
>  > This RA contains a few important parameters for the EU/ subscriber to
>  > consume: (1) a /64 prefix and (2) flags.
>=20
> I would like to suggest to substitute /63 for /64 throughout the
> document.  A /64 will not allow smartphones to tether cleanly.

AERO can delegate any prefix length /64 or shorter. If the client is a host=
,
then /64 may be all that is necessary. If the client is a router, it might =
want
to get something shorter (e.g., /60, /56, etc.).

Thanks - Fred
fred.l.templin@boeing.com

> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
> boundary..."
>=20
> For a discussion of why 63 - where to start?
>=20
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
> >    The WLAN-GW will use the received Radius information to compose the
> >    response to the UE/subscriber originated RS message.  The WLAN-GW
> >    will answer using a unicast RA (Router Advertisement) to the UE/
> >    subscriber.  This RA contains a few important parameters for the EU/
> >    subscriber to consume: (1) a /64 prefix and (2) flags.
>=20
> Since a captive portal is used, it would make sense to use the Captive
> Portal IPv6 RA Option as well (draft-wkumari-dhc-capport-16 LC'ed
> towards RFC end of September).
>=20
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
> >    When a new UE connects to the community Wi-Fi it connects to the Wi-
> >    Fi network by attaching to the relevant 'open' SSID advertised for
> >    use as part of the community Wi-Fi offering.
>=20
> But some community networks use a 'hidden' SSID, known only by members
> of that community.
>=20
> Yours,
>=20
> Alex
>=20
>=20
> Le 20/10/2015 20:35, Fred Baker (fred) a =E9crit :
> > Posted yesterday. Your comment solicited.
> >
> >> Begin forwarded message:
> >>
> >> From: internet-drafts@ietf.org Subject: I-D Action:
> >> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date: October
> >> 19, 2015 at 12:50:01 PM PDT To:  Reply-To:
> >> internet-drafts@ietf.org
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >>
> >> Title           : Unique IPv6 Prefix Per Host Authors         :
> >> John Jason Brzozowski Gunter Van De Velde Filename        :
> >> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14 Date
> >> : 2015-10-19
> >>
> >> Abstract: In some IPv6 environments the need has arisen for hosts
> >> to be able to utilise a unique IPv6 prefix even though the link or
> >> media may be shared.  Typically hosts (subscribers) on a shared
> >> network, like Wi- Fi or Ethernet, will acquire unique IPv6
> >> addresses from a common IPv6 prefix that is allocated or assigned
> >> for use on a specific link. Benefits of a unique IPv6 prefix
> >> compared to a unique IPv6 address from the service provider are
> >> going from enhanced subscriber management to improved isolation
> >> between subscribers.
> >>
> >> In most deployments today IPv6 address assignment from a single
> >> IPv6 prefix on a shared network is done by either using IPv6
> >> stateless address auto-configuration (SLAAC) and/or stateful
> >> DHCPv6.  While this is still viable and operates as designed there
> >> are some large scale environments where this concept introduces
> >> significant performance challenges and implications, specifically
> >> related to IPv6 router and neighbor discovery.  This document
> >> outlines an approach utilising existing IPv6 protocols to allow
> >> hosts to be assigned a unique IPv6 prefix (instead of a unique
> >> IPv6 address from a shared IPv6 prefix).
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-p=
er-host/
> >>
> >>
> >>
> >>
> There's also a htmlized version available at:
> >> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-ho=
st-00
> >>
> >>
> >>
> >>
> >>
> Please note that it may take a couple of minutes from the time of submiss=
ion
> >> until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________ I-D-Announce
> >> mailing list I-D-Announce@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
> >> directories: http://www.ietf.org/shadow.html or
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >
> > _______________________________________________ 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


From nobody Thu Oct 22 09:15:25 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66D1B3965 for ; Thu, 22 Oct 2015 09:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYGZLQpS4X0I for ; Thu, 22 Oct 2015 09:15:21 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE671B38FE for ; Thu, 22 Oct 2015 09:15:21 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9MGFEdP023765; Thu, 22 Oct 2015 18:15:14 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D3D862069DE; Thu, 22 Oct 2015 18:20:55 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C70E52069BA; Thu, 22 Oct 2015 18:20:55 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9MGFCvC007797; Thu, 22 Oct 2015 18:15:13 +0200
To: "Brzozowski, John" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56290B90.8000400@gmail.com>
Date: Thu, 22 Oct 2015 18:15:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 16:15:24 -0000

Le 22/10/2015 16:06, Brzozowski, John a écrit :
> Ole responded to the use of the /63.

Well.

> Regarding your use of this, I am curious which implementation and how many
> devices are operating using a /63?

If the goal is to minimize the importance of a small number of devices 
then the goal is reached.

The implementation is with linux, radvd software and a PMIP implementation.

The question of 63 is little dependent on PMIP.

If the question is about whether a Host can use SLAAC to self-configure 
an address out of a /63 then the answer is yes.  The implementation 
inserts a 0 at the 64th position.  Everybody does that, nobody inserts a 1.

Am I answering?

> Finally, someone from Google/Android will have to comment on Android and
> DHCPv6 for PD support.  I also believe Apple does not support PD yet on
> their devices either.  Like the draft says this is future work, we will
> see where this goes.

Instead of further work we can just modify a number (64 to 63).

Alex

>
> John
> +1-484-962-0060
>
>
>
>
> -----Original Message-----
> From: Alexandre Petrescu 
> Date: Thursday, October 22, 2015 at 09:25
> To: John Jason Brzozowski 
> Cc: v6ops 
> Subject: Re: [v6ops] Fwd: I-D Action:
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>>
>>
>> Le 22/10/2015 15:15, Brzozowski, John a écrit :
>>> Thanks for the comments, see below.
>>>
>>> -----Original Message-----
>>>
>>> From: v6ops  on behalf of Alexandre Petrescu
>>>    Date: Thursday, October 22, 2015 at
>>> 08:47 To: v6ops  Subject: Re: [v6ops] Fwd: I-D
>>> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>
>>>> Hello,
>>>>
>>>> Assigning a prefix-per-host in a WiFi deployment, rather than an
>>>> individual addresses within a same prefix, has also been
>>>> considered in Proxy Mobile IP deployments and it works ok.  It has
>>>> some advantages, and some inconvenients, depending how it's done.
>>>>
>>>> I have some comments on the draft.
>>>>
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>> If radius server discovers that the UE/ subscriber is a fresh
>>>>> device trying to gain access onto the Wi-Fi network it will
>>>>> identify some parameters (e.g.  IPv6 /64 prefix)
>>>> [...]
>>>>> This RA contains a few important parameters for the EU/
>>>>> subscriber to consume: (1) a /64 prefix and (2) flags.
>>>>
>>>> I would like to suggest to substitute /63 for /64 throughout the
>>>> document.  A /64 will not allow smartphones to tether cleanly.
>>>
>>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>>
>> Why?
>>
>>> we have already tested the use of a /64 and will likely maintain
>>> this for our deployment of IPv6 for community Wi-Fi.
>>
>> Well it is good for that community.
>>
>> In this respect, I dont think what the community uses should be an
>> example for other communities (a BCP).
>>
>> I use 63 and works fine.
>>
>>> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
>>> utilized.
>>
>> I hear Android not supporting DHCP at this time, so PD would be a pain.
>>
>> On another hand, just change 64 to 63 will make tethering smartphones
>> work fine without needing DHCP, nor DHCP-PD.
>>
>>>> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
>>>> boundary..."
>>>>
>>>> For a discussion of why 63 - where to start?
>>>>
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>> The WLAN-GW will use the received Radius information to compose
>>>>> the response to the UE/subscriber originated RS message.  The
>>>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>>>> the UE/ subscriber.  This RA contains a few important parameters
>>>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>>>> flags.
>>>>
>>>> Since a captive portal is used, it would make sense to use the
>>>> Captive Portal IPv6 RA Option as well
>>>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
>>> [jjmb] we will take a look at this draft to determine applicability.
>>> Stay tuned.
>>>>
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>> When a new UE connects to the community Wi-Fi it connects to the
>>>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>>>> advertised for use as part of the community Wi-Fi offering.
>>>>
>>>> But some community networks use a 'hidden' SSID, known only by
>>>> members of that community.
>>> [jjmb] hidden should work as well, providing the end user knows the
>>> name of the SSID.  We will look to see if there are clarifications
>>> we can make to address this.
>>
>> Ok.
>>
>> Alex
>>
>>>>
>>>> Yours,
>>>>
>>>> Alex
>>>>
>>>>
>>>> Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>>>>> Posted yesterday. Your comment solicited.
>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>> From: internet-drafts@ietf.org Subject: I-D Action:
>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>>>>  Reply-To: internet-drafts@ietf.org
>>>>>>
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line
>>>>>> Internet-Drafts directories.
>>>>>>
>>>>>>
>>>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>>>> Date : 2015-10-19
>>>>>>
>>>>>> Abstract: In some IPv6 environments the need has arisen for
>>>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>>>> the link or media may be shared.  Typically hosts
>>>>>> (subscribers) on a shared network, like Wi- Fi or Ethernet,
>>>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>>>> that is allocated or assigned for use on a specific link.
>>>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>>>> address from the service provider are going from enhanced
>>>>>> subscriber management to improved isolation between
>>>>>> subscribers.
>>>>>>
>>>>>> In most deployments today IPv6 address assignment from a single
>>>>>> IPv6 prefix on a shared network is done by either using IPv6
>>>>>> stateless address auto-configuration (SLAAC) and/or stateful
>>>>>> DHCPv6.  While this is still viable and operates as designed
>>>>>> there are some large scale environments where this concept
>>>>>> introduces significant performance challenges and implications,
>>>>>> specifically related to IPv6 router and neighbor discovery.
>>>>>> This document outlines an approach utilising existing IPv6
>>>>>> protocols to allow hosts to be assigned a unique IPv6 prefix
>>>>>> (instead of a unique IPv6 address from a shared IPv6 prefix).
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>>
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix-p
>>>>>> er
>>>>>>
>>>>>>
>>>>>>
>> -host/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> There's also a htmlized version available at:
>>>>>>
>>>>>>
>>>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-ho
>>>>>> st
>>>>>>
>>>>>>
>>>>>>
>> -00
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>>>> until the htmlized version and diff are available at
>>>>>> tools.ietf.org.
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>> _______________________________________________ I-D-Announce
>>>>>> mailing list I-D-Announce@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>>>   ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ v6ops mailing
>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing list
>>>>   v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>
>>
>


From nobody Thu Oct 22 09:30:16 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975D1A1A7E for ; Thu, 22 Oct 2015 09:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWj-VIaD2ojv for ; Thu, 22 Oct 2015 09:30:12 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579F51A90A4 for ; Thu, 22 Oct 2015 09:30:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9MGU4tA031410; Thu, 22 Oct 2015 18:30:04 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 78FF4206B45; Thu, 22 Oct 2015 18:35:46 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 70463206847; Thu, 22 Oct 2015 18:35:46 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9MGU3cs031371; Thu, 22 Oct 2015 18:30:04 +0200
To: otroan@employees.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org>
From: Alexandre Petrescu 
Message-ID: <56290F0B.5090702@gmail.com>
Date: Thu, 22 Oct 2015 18:30:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 16:30:14 -0000

Le 22/10/2015 15:46, otroan@employees.org a écrit :
> Alex,
>
>>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>>
>> Why?
>
> that would violate IPv6 standards. and common implementations don't support it either.
>
> e.g.:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_rtr.c?rev=1.125&content-type=text/plain
>
>                          /* aggregatable unicast address, rfc2374 */
> 			if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
> 			 && pi->nd_opt_pi_prefix_len != 64) {

That's a bug.  It should err on > 64 rather than on != 64.  It should 
not err on 63.

> 				nd6log((LOG_INFO,
> 				    "nd6_ra_input: invalid prefixlen "
> 				    "%d for rfc2374 prefix %s, ignored\n",

RFC 2374 has some errors, or maybe people take it too much as a too good 
example.  For example, it gives an example of TLA and SLA ID lengths. 
But some people think they should be taken as such.  It is wrong, they 
are just examples.  They should not be hardcoded as we see in the code 
above.

The length of the TLA IDs and SLA IDs are subject of agreements between 
provider and consumer, they are far from being hardcoded.

I have been recently been allocated a /56 - that's not on a RFC2374 
boundary.  It is the boundary that I negotiated with the provider.  We 
could have agreed on 57 if we wanted to, but 56 sounded nicer.

> 				    pi->nd_opt_pi_prefix_len,

Why do we have a variable for prefix len if it errs on anything 
different than 64?

> 				    inet_ntop(AF_INET6, &pi->nd_opt_pi_prefix,
> 					src, sizeof(src))));
> 				continue;

Instead of continuing it should fill 0s between the prefix len and 64. 
0s and not 1s.

Alex

> 			}
>
> cheers,
> Ole
>


From nobody Thu Oct 22 09:49:33 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23AB1B29C1 for ; Thu, 22 Oct 2015 09:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7yeGnrvRA1H for ; Thu, 22 Oct 2015 09:49:28 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841AF1B29C8 for ; Thu, 22 Oct 2015 09:49:27 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9A9EA62DC1 for ; Thu, 22 Oct 2015 18:49:25 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6E34560395 for ; Thu, 22 Oct 2015 18:49:25 +0200 (CEST)
Received: (qmail 81376 invoked by uid 1007); 22 Oct 2015 18:49:25 +0200
Date: Thu, 22 Oct 2015 18:49:25 +0200
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151022164925.GU70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56290F0B.5090702@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 16:49:31 -0000

Hi,

On Thu, Oct 22, 2015 at 06:30:03PM +0200, Alexandre Petrescu wrote:
> > that would violate IPv6 standards. and common implementations don't support it either.
> >
> > e.g.:
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_rtr.c?rev=1.125&content-type=text/plain
> >
> >                          /* aggregatable unicast address, rfc2374 */
> > 			if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
> > 			 && pi->nd_opt_pi_prefix_len != 64) {
> 
> That's a bug.  It should err on > 64 rather than on != 64.  It should 
> not err on 63.

No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
nothing else.

If you believe a /63 is legal, show the relevant RFC that explains how
SLAAC is done for non-/64 cases.


[..]
> The length of the TLA IDs and SLA IDs are subject of agreements between 
> provider and consumer, they are far from being hardcoded.
> 
> I have been recently been allocated a /56 - that's not on a RFC2374 
> boundary.  It is the boundary that I negotiated with the provider.  We 
> could have agreed on 57 if we wanted to, but 56 sounded nicer.

PD size and on-link *prefix* size are totally different things.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Thu Oct 22 09:57:08 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906F91B39A6 for ; Thu, 22 Oct 2015 09:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDsphOz3m4ic for ; Thu, 22 Oct 2015 09:57:05 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF831B39A3 for ; Thu, 22 Oct 2015 09:57:05 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9MGuuV6018496; Thu, 22 Oct 2015 18:56:56 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDC5D206ABC; Thu, 22 Oct 2015 19:02:37 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CCC4D2067C8; Thu, 22 Oct 2015 19:02:37 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9MGusrl017937; Thu, 22 Oct 2015 18:56:55 +0200
To: Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <56291556.2010907@gmail.com>
Date: Thu, 22 Oct 2015 18:56:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151022164925.GU70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 16:57:07 -0000

Le 22/10/2015 18:49, Gert Doering a écrit :
> Hi,
>
> On Thu, Oct 22, 2015 at 06:30:03PM +0200, Alexandre Petrescu wrote:
>>> that would violate IPv6 standards. and common implementations don't support it either.
>>>
>>> e.g.:
>>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_rtr.c?rev=1.125&content-type=text/plain
>>>
>>>                           /* aggregatable unicast address, rfc2374 */
>>> 			if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
>>> 			 && pi->nd_opt_pi_prefix_len != 64) {
>>
>> That's a bug.  It should err on > 64 rather than on != 64.  It should
>> not err on 63.
>
> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
> nothing else.

No no, SLAAC RFC is not defined for any particular length.

_Ethernet_ IID length in RFC2464 is defined to be 64.

> If you believe a /63 is legal, show the relevant RFC that explains how
> SLAAC is done for non-/64 cases.

I believe /63 prefixlength is legal yes.

SLAAC is done for any  length, the doc does not say 64.

The question that can be made is when SLAACing an Ethernet Interface ID 
with a /63 prefix - what to put at position 64?  0 or 1?  There is no 
specification for that.  The implementations I have seen put 0.  Do you 
believe there should be 1 instead?  Why?

> [..]
>> The length of the TLA IDs and SLA IDs are subject of agreements between
>> provider and consumer, they are far from being hardcoded.
>>
>> I have been recently been allocated a /56 - that's not on a RFC2374
>> boundary.  It is the boundary that I negotiated with the provider.  We
>> could have agreed on 57 if we wanted to, but 56 sounded nicer.
>
> PD size and on-link *prefix* size are totally different things.

I agree.  But neither RFC2374 nor my /56 allocation is an on-link prefix.

RFC 2374 says that the SLA-ID has a particular length, as much as it 
says the Interface ID has a particular length.

The SLA-ID is wrong compared to my /56 allocation.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Oct 22 10:08:40 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE11B39C4 for ; Thu, 22 Oct 2015 10:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jArmoe_SyzaD for ; Thu, 22 Oct 2015 10:08:29 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C691B2A14 for ; Thu, 22 Oct 2015 10:08:29 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-2b-5629180b652f
Received: from PACDCEXHUB03.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 69.DA.04607.B0819265; Thu, 22 Oct 2015 13:08:28 -0400 (EDT)
Received: from PACDCEX42.cable.comcast.com (24.40.2.141) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 22 Oct 2015 13:08:27 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX42.cable.comcast.com (24.40.2.141) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 22 Oct 2015 13:08:26 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Thu, 22 Oct 2015 13:08:26 -0400
From: "Brzozowski, John" 
To: Alexandre Petrescu 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwg==
Date: Thu, 22 Oct 2015 17:08:26 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>
In-Reply-To: <56290B90.8000400@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.7]
Content-Type: text/plain; charset="utf-8"
Content-ID: <03590BA976DCF445A63C3AF30F866953@cable.comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsXiEq4ko8sjoRlmMOkYq8XJM0/YLE4f28vs wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVMfnyHpWBVSkXbp1amBsYHiV2MnBwSAiYS P9fOYIOwxSQu3FsPZHNxCAnsYpK4dnQPM0hCSGAvo8Te9WwQ9m5GiTMn+CCKTjJKvPn9EyzB JmAj8frDT0YQW0TAVOLHricsXYwcHMwCqhKz//CDhIUFoiV2bOlngyiJkZj1opEJwtaT+Dbx G9guFqDyXd2HWUFsXgF7iY///jLDHTSruYsdJMEpoCmxaM4ysEGMQFd/P7UGbBCzgLjErSfz mSC+EZBYsuc8M4QtKvHy8T+woaJAy9pP/Yf62EBi69J9LBC2nMTc1/egbtaUWL9LH2Kkg8S/ DzeYIWxFiSndD9khbhOUODkT4kUhoJHzHkhDTBGXOHxkB+sERtlZSA6ahTB0FpKhs5AMnYVk 6AJG1lWMcgWJySnJuRn5pSUGhnrJiUk5qXrJ+bnJicUlIHoTIzgZyC/fwXjvhdMhRgEORiUe 3mVimmFCrIllxZW5hxglOJiVRHj7n2qECfGmJFZWpRblxxeV5qQWH2KU5mBREufdfO9XqJBA emJJanZqakFqEUyWiYNTqoHR8eXM7n/KO12Sll3eIx3xyk2jtf7eGwvmx7w2TNmqDG1q4pc+ zui+dKxR977T9eZjW08WvTjhxfvWYu2CC4ln+6KYBWKP1d4o8q2SnJClpH6+cMG/sHwDD57q /yWqrAbJGxYKdftpHrTVr/pqPnvpfZd5lpsENPKyJlgxHHm3q/R44sl//4OVWIozEg21mIuK EwHxTWQBAgMAAA==
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 17:08:38 -0000

V2UgY2FuIGNvbnNpZGVyIHRoaXMgZm9yIGZ1dHVyZSB3b3JrLg0KDQpUbyBkYXRlIHdlIGhhdmUg
dGVzdGVkIHdpdGggYSB3aWRlIHJhbmdlIG9mIEFuZHJvaWQsIEFwcGxlLCBhbmQgV2luZG93cw0K
V2ktRmkgZW5hYmxlZCBkZXZpY2VzLiAgQWxsIGhhdmUgYmVlbiB2ZXJpZmllZCBhbmQgd29yayBw
cm9wZXJseSwgYXMgc3VjaA0Kd2UgaGF2ZSBub3QgZXhjbHVkZWQgYW55IGRldmljZXMuICBPdXIg
Z29hbCBoYXMgYmVlbiB0byBiZSBhcyBpbmNsdXNpdmUgYXMNCnBvc3NpYmxlLiAgV2hhdCBpcyBk
b2N1bWVudGVkIGlzLCBpbiBnZW5lcmFsLCB3aGF0IHdpbGwgYmUgcm9sbGVkIG91dC4NCg0KSm9o
bg0KKzEtNDg0LTk2Mi0wMDYwDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+DQpE
YXRlOiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSBhdCAxMjoxNQ0KVG86IEpvaG4gSmFzb24g
QnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPg0KQ2M6IHY2b3Bz
IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1EIEFjdGlvbjoN
CmRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KDQo+
DQo+DQo+TGUgMjIvMTAvMjAxNSAxNjowNiwgQnJ6b3pvd3NraSwgSm9obiBhIMOpY3JpdCA6DQo+
PiBPbGUgcmVzcG9uZGVkIHRvIHRoZSB1c2Ugb2YgdGhlIC82My4NCj4NCj5XZWxsLg0KPg0KPj4g
UmVnYXJkaW5nIHlvdXIgdXNlIG9mIHRoaXMsIEkgYW0gY3VyaW91cyB3aGljaCBpbXBsZW1lbnRh
dGlvbiBhbmQgaG93DQo+Pm1hbnkNCj4+IGRldmljZXMgYXJlIG9wZXJhdGluZyB1c2luZyBhIC82
Mz8NCj4NCj5JZiB0aGUgZ29hbCBpcyB0byBtaW5pbWl6ZSB0aGUgaW1wb3J0YW5jZSBvZiBhIHNt
YWxsIG51bWJlciBvZiBkZXZpY2VzDQo+dGhlbiB0aGUgZ29hbCBpcyByZWFjaGVkLg0KPg0KPlRo
ZSBpbXBsZW1lbnRhdGlvbiBpcyB3aXRoIGxpbnV4LCByYWR2ZCBzb2Z0d2FyZSBhbmQgYSBQTUlQ
DQo+aW1wbGVtZW50YXRpb24uDQo+DQo+VGhlIHF1ZXN0aW9uIG9mIDYzIGlzIGxpdHRsZSBkZXBl
bmRlbnQgb24gUE1JUC4NCj4NCj5JZiB0aGUgcXVlc3Rpb24gaXMgYWJvdXQgd2hldGhlciBhIEhv
c3QgY2FuIHVzZSBTTEFBQyB0byBzZWxmLWNvbmZpZ3VyZQ0KPmFuIGFkZHJlc3Mgb3V0IG9mIGEg
LzYzIHRoZW4gdGhlIGFuc3dlciBpcyB5ZXMuICBUaGUgaW1wbGVtZW50YXRpb24NCj5pbnNlcnRz
IGEgMCBhdCB0aGUgNjR0aCBwb3NpdGlvbi4gIEV2ZXJ5Ym9keSBkb2VzIHRoYXQsIG5vYm9keSBp
bnNlcnRzIGENCj4xLg0KPg0KPkFtIEkgYW5zd2VyaW5nPw0KPg0KPj4gRmluYWxseSwgc29tZW9u
ZSBmcm9tIEdvb2dsZS9BbmRyb2lkIHdpbGwgaGF2ZSB0byBjb21tZW50IG9uIEFuZHJvaWQgYW5k
DQo+PiBESENQdjYgZm9yIFBEIHN1cHBvcnQuICBJIGFsc28gYmVsaWV2ZSBBcHBsZSBkb2VzIG5v
dCBzdXBwb3J0IFBEIHlldCBvbg0KPj4gdGhlaXIgZGV2aWNlcyBlaXRoZXIuICBMaWtlIHRoZSBk
cmFmdCBzYXlzIHRoaXMgaXMgZnV0dXJlIHdvcmssIHdlIHdpbGwNCj4+IHNlZSB3aGVyZSB0aGlz
IGdvZXMuDQo+DQo+SW5zdGVhZCBvZiBmdXJ0aGVyIHdvcmsgd2UgY2FuIGp1c3QgbW9kaWZ5IGEg
bnVtYmVyICg2NCB0byA2MykuDQo+DQo+QWxleA0KPg0KPj4NCj4+IEpvaG4NCj4+ICsxLTQ4NC05
NjItMDA2MA0KPj4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
PiBGcm9tOiBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+
DQo+PiBEYXRlOiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSBhdCAwOToyNQ0KPj4gVG86IEpv
aG4gSmFzb24gQnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPg0K
Pj4gQ2M6IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3
ZDogSS1EIEFjdGlvbjoNCj4+IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl
ci1ob3N0LTAwLnR4dA0KPj4NCj4+Pg0KPj4+DQo+Pj4gTGUgMjIvMTAvMjAxNSAxNToxNSwgQnJ6
b3pvd3NraSwgSm9obiBhIMOpY3JpdCA6DQo+Pj4+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBz
ZWUgYmVsb3cuDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+DQo+
Pj4+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQWxl
eGFuZHJlIFBldHJlc2N1DQo+Pj4+ICAgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+IERh
dGU6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDE1IGF0DQo+Pj4+IDA4OjQ3IFRvOiB2Nm9wcyA8
djZvcHNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1EDQo+Pj4+IEFjdGlv
bjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQo+
Pj4+DQo+Pj4+PiBIZWxsbywNCj4+Pj4+DQo+Pj4+PiBBc3NpZ25pbmcgYSBwcmVmaXgtcGVyLWhv
c3QgaW4gYSBXaUZpIGRlcGxveW1lbnQsIHJhdGhlciB0aGFuIGFuDQo+Pj4+PiBpbmRpdmlkdWFs
IGFkZHJlc3NlcyB3aXRoaW4gYSBzYW1lIHByZWZpeCwgaGFzIGFsc28gYmVlbg0KPj4+Pj4gY29u
c2lkZXJlZCBpbiBQcm94eSBNb2JpbGUgSVAgZGVwbG95bWVudHMgYW5kIGl0IHdvcmtzIG9rLiAg
SXQgaGFzDQo+Pj4+PiBzb21lIGFkdmFudGFnZXMsIGFuZCBzb21lIGluY29udmVuaWVudHMsIGRl
cGVuZGluZyBob3cgaXQncyBkb25lLg0KPj4+Pj4NCj4+Pj4+IEkgaGF2ZSBzb21lIGNvbW1lbnRz
IG9uIHRoZSBkcmFmdC4NCj4+Pj4+DQo+Pj4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2
LXByZWZpeC1wZXItaG9zdC0wMC50eHQgc2F5czoNCj4+Pj4+PiBJZiByYWRpdXMgc2VydmVyIGRp
c2NvdmVycyB0aGF0IHRoZSBVRS8gc3Vic2NyaWJlciBpcyBhIGZyZXNoDQo+Pj4+Pj4gZGV2aWNl
IHRyeWluZyB0byBnYWluIGFjY2VzcyBvbnRvIHRoZSBXaS1GaSBuZXR3b3JrIGl0IHdpbGwNCj4+
Pj4+PiBpZGVudGlmeSBzb21lIHBhcmFtZXRlcnMgKGUuZy4gIElQdjYgLzY0IHByZWZpeCkNCj4+
Pj4+IFsuLi5dDQo+Pj4+Pj4gVGhpcyBSQSBjb250YWlucyBhIGZldyBpbXBvcnRhbnQgcGFyYW1l
dGVycyBmb3IgdGhlIEVVLw0KPj4+Pj4+IHN1YnNjcmliZXIgdG8gY29uc3VtZTogKDEpIGEgLzY0
IHByZWZpeCBhbmQgKDIpIGZsYWdzLg0KPj4+Pj4NCj4+Pj4+IEkgd291bGQgbGlrZSB0byBzdWdn
ZXN0IHRvIHN1YnN0aXR1dGUgLzYzIGZvciAvNjQgdGhyb3VnaG91dCB0aGUNCj4+Pj4+IGRvY3Vt
ZW50LiAgQSAvNjQgd2lsbCBub3QgYWxsb3cgc21hcnRwaG9uZXMgdG8gdGV0aGVyIGNsZWFubHku
DQo+Pj4+DQo+Pj4+IFtqam1iXSBJIGJlbGlldmUgYW4gUkEgd2l0aCBhIFBJTyBvZiBhIC82MyB3
aWxsIGJlIHByb2JsZW1hdGljLA0KPj4+DQo+Pj4gV2h5Pw0KPj4+DQo+Pj4+IHdlIGhhdmUgYWxy
ZWFkeSB0ZXN0ZWQgdGhlIHVzZSBvZiBhIC82NCBhbmQgd2lsbCBsaWtlbHkgbWFpbnRhaW4NCj4+
Pj4gdGhpcyBmb3Igb3VyIGRlcGxveW1lbnQgb2YgSVB2NiBmb3IgY29tbXVuaXR5IFdpLUZpLg0K
Pj4+DQo+Pj4gV2VsbCBpdCBpcyBnb29kIGZvciB0aGF0IGNvbW11bml0eS4NCj4+Pg0KPj4+IElu
IHRoaXMgcmVzcGVjdCwgSSBkb250IHRoaW5rIHdoYXQgdGhlIGNvbW11bml0eSB1c2VzIHNob3Vs
ZCBiZSBhbg0KPj4+IGV4YW1wbGUgZm9yIG90aGVyIGNvbW11bml0aWVzIChhIEJDUCkuDQo+Pj4N
Cj4+PiBJIHVzZSA2MyBhbmQgd29ya3MgZmluZS4NCj4+Pg0KPj4+PiBGb3IgdGV0aGVyaW5nIG92
ZXIgV2ktRmkgb3VyIGV4cGVjdGF0aW9uIGlzIHRoYXQgREhDUHY2IFBEIHdvdWxkIGJlDQo+Pj4+
IHV0aWxpemVkLg0KPj4+DQo+Pj4gSSBoZWFyIEFuZHJvaWQgbm90IHN1cHBvcnRpbmcgREhDUCBh
dCB0aGlzIHRpbWUsIHNvIFBEIHdvdWxkIGJlIGEgcGFpbi4NCj4+Pg0KPj4+IE9uIGFub3RoZXIg
aGFuZCwganVzdCBjaGFuZ2UgNjQgdG8gNjMgd2lsbCBtYWtlIHRldGhlcmluZyBzbWFydHBob25l
cw0KPj4+IHdvcmsgZmluZSB3aXRob3V0IG5lZWRpbmcgREhDUCwgbm9yIERIQ1AtUEQuDQo+Pj4N
Cj4+Pj4+IEZvciBhIGRpc2N1c3Npb24gb2Ygd2h5IDY0IG9uZSBjYW4gcmVmZXIgdG8gUkZDNzUy
MSAiQW5hbHlzaXMgb2YgNjQNCj4+Pj4+IGJvdW5kYXJ5Li4uIg0KPj4+Pj4NCj4+Pj4+IEZvciBh
IGRpc2N1c3Npb24gb2Ygd2h5IDYzIC0gd2hlcmUgdG8gc3RhcnQ/DQo+Pj4+Pg0KPj4+Pj4gZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0IHNheXM6DQo+
Pj4+Pj4gVGhlIFdMQU4tR1cgd2lsbCB1c2UgdGhlIHJlY2VpdmVkIFJhZGl1cyBpbmZvcm1hdGlv
biB0byBjb21wb3NlDQo+Pj4+Pj4gdGhlIHJlc3BvbnNlIHRvIHRoZSBVRS9zdWJzY3JpYmVyIG9y
aWdpbmF0ZWQgUlMgbWVzc2FnZS4gIFRoZQ0KPj4+Pj4+IFdMQU4tR1cgd2lsbCBhbnN3ZXIgdXNp
bmcgYSB1bmljYXN0IFJBIChSb3V0ZXIgQWR2ZXJ0aXNlbWVudCkgdG8NCj4+Pj4+PiB0aGUgVUUv
IHN1YnNjcmliZXIuICBUaGlzIFJBIGNvbnRhaW5zIGEgZmV3IGltcG9ydGFudCBwYXJhbWV0ZXJz
DQo+Pj4+Pj4gZm9yIHRoZSBFVS8gc3Vic2NyaWJlciB0byBjb25zdW1lOiAoMSkgYSAvNjQgcHJl
Zml4IGFuZCAoMikNCj4+Pj4+PiBmbGFncy4NCj4+Pj4+DQo+Pj4+PiBTaW5jZSBhIGNhcHRpdmUg
cG9ydGFsIGlzIHVzZWQsIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gdXNlIHRoZQ0KPj4+Pj4gQ2Fw
dGl2ZSBQb3J0YWwgSVB2NiBSQSBPcHRpb24gYXMgd2VsbA0KPj4+Pj4gKGRyYWZ0LXdrdW1hcmkt
ZGhjLWNhcHBvcnQtMTYgTEMnZWQgdG93YXJkcyBSRkMgZW5kIG9mIFNlcHRlbWJlcikuDQo+Pj4+
IFtqam1iXSB3ZSB3aWxsIHRha2UgYSBsb29rIGF0IHRoaXMgZHJhZnQgdG8gZGV0ZXJtaW5lIGFw
cGxpY2FiaWxpdHkuDQo+Pj4+IFN0YXkgdHVuZWQuDQo+Pj4+Pg0KPj4+Pj4gZHJhZnQtamptYi12
Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0IHNheXM6DQo+Pj4+Pj4gV2hl
biBhIG5ldyBVRSBjb25uZWN0cyB0byB0aGUgY29tbXVuaXR5IFdpLUZpIGl0IGNvbm5lY3RzIHRv
IHRoZQ0KPj4+Pj4+IFdpLSBGaSBuZXR3b3JrIGJ5IGF0dGFjaGluZyB0byB0aGUgcmVsZXZhbnQg
J29wZW4nIFNTSUQNCj4+Pj4+PiBhZHZlcnRpc2VkIGZvciB1c2UgYXMgcGFydCBvZiB0aGUgY29t
bXVuaXR5IFdpLUZpIG9mZmVyaW5nLg0KPj4+Pj4NCj4+Pj4+IEJ1dCBzb21lIGNvbW11bml0eSBu
ZXR3b3JrcyB1c2UgYSAnaGlkZGVuJyBTU0lELCBrbm93biBvbmx5IGJ5DQo+Pj4+PiBtZW1iZXJz
IG9mIHRoYXQgY29tbXVuaXR5Lg0KPj4+PiBbamptYl0gaGlkZGVuIHNob3VsZCB3b3JrIGFzIHdl
bGwsIHByb3ZpZGluZyB0aGUgZW5kIHVzZXIga25vd3MgdGhlDQo+Pj4+IG5hbWUgb2YgdGhlIFNT
SUQuICBXZSB3aWxsIGxvb2sgdG8gc2VlIGlmIHRoZXJlIGFyZSBjbGFyaWZpY2F0aW9ucw0KPj4+
PiB3ZSBjYW4gbWFrZSB0byBhZGRyZXNzIHRoaXMuDQo+Pj4NCj4+PiBPay4NCj4+Pg0KPj4+IEFs
ZXgNCj4+Pg0KPj4+Pj4NCj4+Pj4+IFlvdXJzLA0KPj4+Pj4NCj4+Pj4+IEFsZXgNCj4+Pj4+DQo+
Pj4+Pg0KPj4+Pj4gTGUgMjAvMTAvMjAxNSAyMDozNSwgRnJlZCBCYWtlciAoZnJlZCkgYSDDqWNy
aXQgOg0KPj4+Pj4+IFBvc3RlZCB5ZXN0ZXJkYXkuIFlvdXIgY29tbWVudCBzb2xpY2l0ZWQuDQo+
Pj4+Pj4NCj4+Pj4+Pj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+Pj4+Pj4+DQo+Pj4+Pj4+
IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBTdWJqZWN0OiBJLUQgQWN0aW9uOg0KPj4+
Pj4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQg
RGF0ZToNCj4+Pj4+Pj4gT2N0b2JlciAxOSwgMjAxNSBhdCAxMjo1MDowMSBQTSBQRFQgVG86DQo+
Pj4+Pj4+IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+IFJlcGx5LVRvOiBpbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmcNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg
aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGRp
cmVjdG9yaWVzLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaXRsZSAgICAgICAgICAgOiBV
bmlxdWUgSVB2NiBQcmVmaXggUGVyIEhvc3QgQXV0aG9ycyA6IEpvaG4NCj4+Pj4+Pj4gSmFzb24g
QnJ6b3pvd3NraSBHdW50ZXIgVmFuIERlIFZlbGRlIEZpbGVuYW1lICAgICAgICA6DQo+Pj4+Pj4+
IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dCBQYWdl
cyA6IDE0DQo+Pj4+Pj4+IERhdGUgOiAyMDE1LTEwLTE5DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFic3Ry
YWN0OiBJbiBzb21lIElQdjYgZW52aXJvbm1lbnRzIHRoZSBuZWVkIGhhcyBhcmlzZW4gZm9yDQo+
Pj4+Pj4+IGhvc3RzIHRvIGJlIGFibGUgdG8gdXRpbGlzZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBl
dmVuIHRob3VnaA0KPj4+Pj4+PiB0aGUgbGluayBvciBtZWRpYSBtYXkgYmUgc2hhcmVkLiAgVHlw
aWNhbGx5IGhvc3RzDQo+Pj4+Pj4+IChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29yaywg
bGlrZSBXaS0gRmkgb3IgRXRoZXJuZXQsDQo+Pj4+Pj4+IHdpbGwgYWNxdWlyZSB1bmlxdWUgSVB2
NiBhZGRyZXNzZXMgZnJvbSBhIGNvbW1vbiBJUHY2IHByZWZpeA0KPj4+Pj4+PiB0aGF0IGlzIGFs
bG9jYXRlZCBvciBhc3NpZ25lZCBmb3IgdXNlIG9uIGEgc3BlY2lmaWMgbGluay4NCj4+Pj4+Pj4g
QmVuZWZpdHMgb2YgYSB1bmlxdWUgSVB2NiBwcmVmaXggY29tcGFyZWQgdG8gYSB1bmlxdWUgSVB2
Ng0KPj4+Pj4+PiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgYXJlIGdvaW5nIGZy
b20gZW5oYW5jZWQNCj4+Pj4+Pj4gc3Vic2NyaWJlciBtYW5hZ2VtZW50IHRvIGltcHJvdmVkIGlz
b2xhdGlvbiBiZXR3ZWVuDQo+Pj4+Pj4+IHN1YnNjcmliZXJzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJ
biBtb3N0IGRlcGxveW1lbnRzIHRvZGF5IElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBz
aW5nbGUNCj4+Pj4+Pj4gSVB2NiBwcmVmaXggb24gYSBzaGFyZWQgbmV0d29yayBpcyBkb25lIGJ5
IGVpdGhlciB1c2luZyBJUHY2DQo+Pj4+Pj4+IHN0YXRlbGVzcyBhZGRyZXNzIGF1dG8tY29uZmln
dXJhdGlvbiAoU0xBQUMpIGFuZC9vciBzdGF0ZWZ1bA0KPj4+Pj4+PiBESENQdjYuICBXaGlsZSB0
aGlzIGlzIHN0aWxsIHZpYWJsZSBhbmQgb3BlcmF0ZXMgYXMgZGVzaWduZWQNCj4+Pj4+Pj4gdGhl
cmUgYXJlIHNvbWUgbGFyZ2Ugc2NhbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29uY2VwdA0K
Pj4+Pj4+PiBpbnRyb2R1Y2VzIHNpZ25pZmljYW50IHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5k
IGltcGxpY2F0aW9ucywNCj4+Pj4+Pj4gc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2NiByb3V0
ZXIgYW5kIG5laWdoYm9yIGRpc2NvdmVyeS4NCj4+Pj4+Pj4gVGhpcyBkb2N1bWVudCBvdXRsaW5l
cyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2Ng0KPj4+Pj4+PiBwcm90b2NvbHMg
dG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXgNCj4+Pj4+
Pj4gKGluc3RlYWQgb2YgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBw
cmVmaXgpLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBz
dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g
DQo+Pj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamptYi12Nm9w
cy11bmlxdWUtaXB2Ni1wcmVmaXgNCj4+Pj4+Pj4tcA0KPj4+Pj4+PiBlcg0KPj4+Pj4+Pg0KPj4+
Pj4+Pg0KPj4+Pj4+Pg0KPj4+IC1ob3N0Lw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+
Pj4+Pg0KPj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6
DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IA0KPj4+Pj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItDQo+Pj4+Pj4+
aG8NCj4+Pj4+Pj4gc3QNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+PiAtMDANCj4+Pj4+
Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+IFBsZWFzZSBub3Rl
IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+
Pj4+PiBzdWJtaXNzaW9uDQo+Pj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk
aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU
UCBhdDoNCj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+
Pj4NCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18gSS1ELUFubm91bmNlDQo+Pj4+Pj4+IG1haWxpbmcgbGlzdCBJLUQtQW5ub3VuY2VAaWV0Zi5v
cmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5u
b3VuY2UNCj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0
Zi5vcmcvc2hhZG93Lmh0bWwgb3INCj4+Pj4+Pj4gICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8x
c2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcNCj4+
Pj4+PiBsaXN0IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdjZvcHMNCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPj4+Pj4gICB2Nm9w
c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+
Pj4+Pg0KPj4+Pg0KPj4+DQo+Pj4NCj4+DQo+DQo+DQoNCg==


From nobody Thu Oct 22 10:12:40 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A5F1B39FD for ; Thu, 22 Oct 2015 10:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-dS-KhuDh90 for ; Thu, 22 Oct 2015 10:12:33 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D171B39ED for ; Thu, 22 Oct 2015 10:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=655; q=dns/txt; s=iport; t=1445533949; x=1446743549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0f3lmsKF4KYm3rKG+wT71E0AnzfQ7SN+2yEN4DB2gR8=; b=KRQvlRnuaTojTFsC5OWZ6vOSsW4LytWAxqx1vXDHNbptk3PZcEv+2WgV lSpV+E9Z+ixl6vkhllwPzQY6S4YOI/xhhkkw0RcqekGFitv4WZW0Y2Hp2 6AEA4wULklrhFymdzP27agbJe4RwgOCaEFX6rEy/Jt4vbv4sHcjX/nrt+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D0AQDtFylW/4cNJK1egzaBQwa+GgENgVmGHQKBRTgUAQEBAQEBAYEKhC4BAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQBDQUIiCjFTwEBAQEBAQEBAQEBAQEBAQEBAQEBARiLdYUNBwaEKAEElisBjRacLAEfAQFCghEdFoE/coU9gQYBAQE
X-IronPort-AV: E=Sophos;i="5.20,183,1444694400"; d="scan'208";a="39977232"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2015 17:12:28 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9MHCSE6013785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 17:12:28 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 12:12:08 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 12:12:08 -0500
From: "Hemant Singh (shemant)" 
To: Alexandre Petrescu , Gert Doering 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMfPxpIl25fhCEeMCSxqTjSb+Z530bAAgAAC4wCAAAXHgIAALbaAgAAFaYCAAAIXAP//rnRA
Date: Thu, 22 Oct 2015 17:12:08 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>
In-Reply-To: <56291556.2010907@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.71.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 17:12:38 -0000

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Thursday, October 22, 2015 12:57 PM
To: Gert Doering
Cc: v6ops@ietf.org; Brzozowski, John
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-p=
er-host-00.txt

>No no, SLAAC RFC is not defined for any particular length.
>
> _Ethernet_ IID length in RFC2464 is defined to be 64.


>From RFC 4291, there is this text.

[For all unicast addresses, except those that start with the binary
 value 000, Interface IDs are required to be 64 bits long and to be
 constructed in Modified EUI-64 format.]

Hemant


From nobody Thu Oct 22 10:28:35 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AB11B3A4F for ; Thu, 22 Oct 2015 10:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpb_DKq27SQw for ; Thu, 22 Oct 2015 10:28:22 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE3A1B3A4C for ; Thu, 22 Oct 2015 10:28:21 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 75ABD60934 for ; Thu, 22 Oct 2015 19:28:19 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2AE6060BBD for ; Thu, 22 Oct 2015 19:28:19 +0200 (CEST)
Received: (qmail 82934 invoked by uid 1007); 22 Oct 2015 19:28:19 +0200
Date: Thu, 22 Oct 2015 19:28:19 +0200
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151022172819.GV70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QYbTd+PSDu6P6/0L"
Content-Disposition: inline
In-Reply-To: <56291556.2010907@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "Brzozowski, John" , "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 17:28:27 -0000

--QYbTd+PSDu6P6/0L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Oct 22, 2015 at 06:56:54PM +0200, Alexandre Petrescu wrote:
> >> That's a bug.  It should err on > 64 rather than on !=3D 64.  It should
> >> not err on 63.
> >
> > No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
> > nothing else.
>=20
> No no, SLAAC RFC is not defined for any particular length.

That is the point: for any particular length, SLAAC is *not defined*.

> _Ethernet_ IID length in RFC2464 is defined to be 64.

=2E.. and for ethernet, with /64, it is.

> > If you believe a /63 is legal, show the relevant RFC that explains how
> > SLAAC is done for non-/64 cases.
>=20
> I believe /63 prefixlength is legal yes.

*show* the RFC that explains how it is done for non-/64 cases.

What you do in private is good for your amusement, but we do not want=20
to know.

> SLAAC is done for any  length, the doc does not say 64.
>=20
> The question that can be made is when SLAACing an Ethernet Interface ID=
=20
> with a /63 prefix - what to put at position 64?  0 or 1?  There is no=20
> specification for that.  The implementations I have seen put 0.  Do you=
=20
> believe there should be 1 instead?  Why?

It is not defined.  You can do whatever you want.  But a RFC-compliant
implementation will correctly refuse anything that is not a /64 unless
there is a documented standard to handle /63.

Not that it would make any sense at all to use anything larger (shorter
prefix) than a /64 on any sort of link, so this whole discussion is
totally moot in the first place.

[..]
> The SLA-ID is wrong compared to my /56 allocation.

Your allocation is an allocation, and not an on-link prefix.  So it does
not have any meaning for this discussion.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--QYbTd+PSDu6P6/0L
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVikcst9WwGXkzn/FAQK21A//WKWzB3d7ikOuila9g0fv0AmAJlW/5YZc
w/59karc01CPR42Ej+BZnyPC6Rz6wXpE1N48a/bTwqdwZHqmqdUfr10hcdAH8Fcr
Tm92PPItEOCVqM+psk3Xf5TZfxvwR1v+Z+OTK6K+48ZGsY5eBrZbnqe92zkCDHqE
Ih9GaalVpr9U+2+kYpkfsLqEG18XpEzhfanxQx9G/kNc3Q8rcBCP6dCGDgqKjBzK
Zcbfhk8g4aA2n3AiX5lChQ2hOtBkZ9yHhlxN8WHzbEunfoZC3/W4hkY8Br3fpRq8
gaBrTLWsZ12OGx+W2WNuMyQFqz8Su6jlUL7AIQahZQJLb7TDKMoKvbw2NmQfLLiy
QdJmbu+uJ9SZlMeldsit1CKHfzk70cGU0GOCjsceFeNVzSf96U6Gk98LQiZWTaIC
ChNYB1NtSqEhefR7v7oN0G58vmiIQk5+iukdrW6MbBPn1btuhVRiZa0axl5DP+xd
dMFwQWysp7jNLUuFGNB7cztQX4FaRTFwPIWGJOSJx/9EI1VwmKo0VynAu2FseOWA
W6dzfrmdQ2hrmEQUNvceNEgPPNaWdxW+bAKQdPfoSdBCaUXn5MQTm1NVVB1CYUxB
9w/B/7GfwFVZvK/VxhQJIrsZUK/nRorksZMDWTof1lTsbh8xcLDQ6cTp0a3SJ+oV
J4NbjiXShhQ=
=cpVl
-----END PGP SIGNATURE-----

--QYbTd+PSDu6P6/0L--


From nobody Thu Oct 22 10:43:40 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2D1B2A92 for ; Thu, 22 Oct 2015 10:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.022
X-Spam-Level: 
X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_SUMOF=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET2R3tjhuEv5 for ; Thu, 22 Oct 2015 10:43:36 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9794B1B2A8D for ; Thu, 22 Oct 2015 10:43:36 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so126376406igb.0 for ; Thu, 22 Oct 2015 10:43:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zFBiQNOIy4jg/jt2YahBkmVquLEHgLyf63eDlDaF5wA=; b=Zruv6uS64IQw4n+Fx7VcjAtLdujcVWXZhqr1cTpyJSX4B2RB2GLPcaRlfmMXN1URAc iAVlMeN7RRkN4vTnw4BR+UmUWM0xGDO/WIbAGoVPLYa9ghX3Ux4gYC/qDHkeWI1YU3u9 MKPuYmAf8O5foZeoRDpHMmG/6TbAgBaEKNnO+iBjX916UgvtKCmOKzPEL2H06Vz5DRqA NfMricuZmp+TIj6aNAS+OiS/kRjhkoQiSpM92aE6NnZ66X4vW8CsvqLAQRUAyUipKy5Y F7BTtJCsvx0MjbF02DM/CiBh7SmgDQhgd36FuvR9QCxH+lzG5j62UWG4vFmkXZ7Qnpgx HgCQ==
MIME-Version: 1.0
X-Received: by 10.50.41.10 with SMTP id b10mr17313367igl.41.1445535815925; Thu, 22 Oct 2015 10:43:35 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Thu, 22 Oct 2015 10:43:35 -0700 (PDT)
In-Reply-To: <20151022164925.GU70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>
Date: Thu, 22 Oct 2015 10:43:35 -0700
X-Google-Sender-Auth: DD4y-I4FewT2lFiecRI53l6DcRc
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Gert Doering 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 17:43:38 -0000

At Thu, 22 Oct 2015 18:49:25 +0200,
Gert Doering  wrote:

> > > that would violate IPv6 standards. and common implementations don't support it either.
> > >
> > > e.g.:
> > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet6/nd6_rtr.c?rev=1.125&content-type=text/plain
> > >
> > >                          /* aggregatable unicast address, rfc2374 */
> > >             if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
> > >              && pi->nd_opt_pi_prefix_len != 64) {
> >
> > That's a bug.  It should err on > 64 rather than on != 64.  It should
> > not err on 63.
>
> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
> nothing else.

(maybe an off-topic in the main context but)

This is indeed a bug (or at the very least non-compliant), but I guess
we are conflating different subtle things here.

This OpenBSD implementation is buggy in that it rejects a prefix with
a length other than 64 bits both for SLAAC and for on-link
determination.  The latter is a violation against RFC4861 (or at least
something beyond RFC4861 describes).

Rejecting it for SLAAC is not necessarily incorrect, but hardcoding 64
in this context is probably not very clean, since, in theory, this can
be different for different types of links (btw RFC4862 clarifies the
relationship and possible "inconsistency" between SLAAC and address
architecture regarding the expected IID length).

A better reference of BSD variants on this point would be FreeBSD:
https://raw.githubusercontent.com/freebsd/freebsd/master/sys/netinet6/nd6_rtr.c

It doesn't have the above check in this function (nd6_ra_input()).  It
validates the prefix length only in the context of SLAAC, and in a
more generic way by avoiding hardcoding the magic number:

    /*
     * Address autoconfiguration based on Section 5.5.3 of RFC 2462.
     * Note that pr must be non NULL at this point.
     */
..
        /*
         * Prefix Length check:
         * If the sum of the prefix length and interface identifier
         * length does not equal 128 bits, the Prefix Information
         * option MUST be ignored.  The length of the interface
         * identifier is defined in a separate link-type specific
         * document.
         */
        ifidlen = in6_if2idlen(ifp);
...
        if (ifidlen + pr->ndpr_plen != 128) {
            nd6log((LOG_INFO,
                "prelist_update: invalid prefixlen "
                "%d for %s, ignored\n",
                pr->ndpr_plen, if_name(ifp)));
            goto end;
        }

Regarding the main context, I don't know how advertising /63 helps the
tethering scenario, btw.

--
JINMEI, Tatuya


From nobody Thu Oct 22 10:54:12 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9261A19F2 for ; Thu, 22 Oct 2015 10:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.022
X-Spam-Level: 
X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_SUMOF=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN4c1kCFaaDH for ; Thu, 22 Oct 2015 10:54:10 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EF41A016C for ; Thu, 22 Oct 2015 10:54:09 -0700 (PDT)
Received: by iow1 with SMTP id 1so99588141iow.1 for ; Thu, 22 Oct 2015 10:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=adyTrzZTQcSyhSfpL7Eu8Up/xndXR5QP4ND8W5wMP5M=; b=XR++5X2VxDlf/AoUn4rqSWaklsqwBpH///ZG6KVj04XLrRcFoThLx0OtUf6iZ+hBjn bX74Y/9GxLy2Wmy44EpYCFNvmFHSadI2pVk+hj3+vG3pvj4D0N+jeTqYLQjM8O5SAcW4 BMrLMEHOncxJB/pTZiBtNnfrSvjR4lod3QOvspMQeebr6ACURTZ5sFFIqLiSCW6MMD+p f8OU5P4LOhq2zzvxx9fvTOyMVu8JhWrE6oObZUeWvCc1OO/0KEetJ6+JUwgI9mbqARGv sG4GxuKJsJRraidorQwl5U5UWdxETLiJ4OCmED/VizeqZn7gXS0360gtz2gU5/mV7pJe F2Tw==
MIME-Version: 1.0
X-Received: by 10.107.132.217 with SMTP id o86mr19355045ioi.172.1445536449340;  Thu, 22 Oct 2015 10:54:09 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Thu, 22 Oct 2015 10:54:09 -0700 (PDT)
In-Reply-To: <56291556.2010907@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>
Date: Thu, 22 Oct 2015 10:54:09 -0700
X-Google-Sender-Auth: DnFQLKgxczWpvf6Djmni4cmvV3I
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 17:54:11 -0000

At Thu, 22 Oct 2015 18:56:54 +0200,
Alexandre Petrescu  wrote:

> > No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and for
> > nothing else.
>
> No no, SLAAC RFC is not defined for any particular length.
>
> _Ethernet_ IID length in RFC2464 is defined to be 64.

So you are assuming the 64-bit IID in your scenario, right?  Then,

> > If you believe a /63 is legal, show the relevant RFC that explains how
> > SLAAC is done for non-/64 cases.
>
> I believe /63 prefixlength is legal yes.
>
> SLAAC is done for any  length, the doc does not say 64.

no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
length is 64 on a link whose IID is supposed to be 64 bits violates
Section 5.5.3 d of RFC 4862:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

--
JINMEI, Tatuya


From nobody Thu Oct 22 11:06:10 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8829B1AC3BC for ; Thu, 22 Oct 2015 11:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxAJLQD9LFZd for ; Thu, 22 Oct 2015 11:06:08 -0700 (PDT)
Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877911AC3AD for ; Thu, 22 Oct 2015 11:06:08 -0700 (PDT)
Received: by iofz202 with SMTP id z202so9664409iof.2 for ; Thu, 22 Oct 2015 11:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ykPP/JQF7/d/A+/+A1feD9/ekAGn86PCAenHp0+56vg=; b=lORHEiWgj4I0gt5PfupaqNArpTeL/tosmRyrVe+Hrzq14OH5J/F3FyV4EKda6FSSB+ j1zqKellUpkD/43fjXECnrj0CZ0Mh1ygtIHOBJ6F4y/i5Dax1pf5ueyHvKz5CQ7eyEZw Vju3Thjw0ZlsdCmB//9hEpr92X/1QQYv1SzE4FG2EctDIMavpFrrm9lt5RIrS7Q0Evfb NIv2PWUTaztZBvKn8zGDmEn0Wh4LKFvOFJ4+FsDozQngfJ3pvBSoMvhKPGyw2HrYUA6X iIkZhJtULNBDzCghVS+1s5/a7kLOJd2fHtL3KNtYbYJC2C5VbnrIGbYSfmpBrX5L13xD nxGg==
MIME-Version: 1.0
X-Received: by 10.107.168.4 with SMTP id r4mr20045079ioe.4.1445537168003; Thu, 22 Oct 2015 11:06:08 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Thu, 22 Oct 2015 11:06:07 -0700 (PDT)
In-Reply-To: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com> 
Date: Thu, 22 Oct 2015 11:06:07 -0700
X-Google-Sender-Auth: t46T-dPgx9LBlP0BKrIkjeddIdQ
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 18:06:09 -0000

On Thu, Oct 22, 2015 at 10:54 AM,  wrote:

> no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
> length is 64 on a link whose IID is supposed to be 64 bits violates
> Section 5.5.3 d of RFC 4862:

Oops, sorry, there was a very confusing typo: this should have been
"...and length is 63...".

--
JINMEI, Tatuya


From nobody Thu Oct 22 14:40:39 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F92C1B42BC for ; Thu, 22 Oct 2015 14:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL5M5fCsrqLx for ; Thu, 22 Oct 2015 14:40:36 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A921B3055 for ; Thu, 22 Oct 2015 14:40:36 -0700 (PDT)
Received: by pabrc13 with SMTP id rc13so96978542pab.0 for ; Thu, 22 Oct 2015 14:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ddo9w08ELlVf+zm8HEvK2KmcYYdeZEMYiBr4iUjOE2Y=; b=br43WtHvyV6CxyTVLKcZVzxW/PGbTKXKHGwmFYug2S+OzIxxCcdWe/CEbOFeZeC898 144npx5ZgCK5WE3Rvj37yLtcuSrXEOrEAbGIMIECGckQaDRAuuZ57n7mqfDc7JB2Ytu8 W8l8ERRQYaMKpbKiksq0hpCNE7cjFMpZ6liORmF03mZI4pKuPZA9nGZLpOg2TvxcUeRn u1QZNGIa5o/vDRQzZm4WP5Oeuhh/YnChMnAuQKPLG7GLwHK+tQj67nFdqN2HYczZWfH2 y+lfSzCxAWK2F/SzcuaOaEBEf0+JmEV1by8HIoOI9dS1e3XCOA9BSw7SoTWKqS8/xey8 1Mug==
X-Received: by 10.68.193.231 with SMTP id hr7mr705016pbc.111.1445550036329; Thu, 22 Oct 2015 14:40:36 -0700 (PDT)
Received: from ?IPv6:2406:e007:572b:1:28cc:dc4c:9703:6781? ([2406:e007:572b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id pw7sm15442307pbc.4.2015.10.22.14.40.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2015 14:40:35 -0700 (PDT)
To: "Hemant Singh (shemant)" , Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <562957D8.4040001@gmail.com>
Date: Fri, 23 Oct 2015 10:40:40 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Oct 2015 21:40:38 -0000

On 23/10/2015 06:12, Hemant Singh (shemant) wrote:
> 
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Thursday, October 22, 2015 12:57 PM
> To: Gert Doering
> Cc: v6ops@ietf.org; Brzozowski, John
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> 
>> No no, SLAAC RFC is not defined for any particular length.
>>
>> _Ethernet_ IID length in RFC2464 is defined to be 64.
> 
> 
>>From RFC 4291, there is this text.
> 
> [For all unicast addresses, except those that start with the binary
>  value 000, Interface IDs are required to be 64 bits long and to be
>  constructed in Modified EUI-64 format.]

To be precise, that text is obsoleted by RFC 7136 (and rfc4291bis):
http://tools.ietf.org/html/rfc7136#section-5

Neverthless, the 64 bit length is *not* required by SLAAC. Rather, it's
a parameter for SLAAC. Any SLAAC code that treats it as a constant is faulty:
http://tools.ietf.org/html/rfc7421#section-1

But in reality, it's a parameter that's always set to 64. So for anything to
actually work, if you assign a /63 to a host, it will have to contain
extra logic to assign the two halves of that as two /64s, and to decide
which one to use.

    Brian


From nobody Thu Oct 22 18:12:55 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB31ACD0A for ; Thu, 22 Oct 2015 18:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX9oe2Bt6LIj for ; Thu, 22 Oct 2015 18:12:49 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 57B531ACCEB for ; Thu, 22 Oct 2015 18:12:43 -0700 (PDT)
Received: from [181.46.190.53] (helo=[172.16.17.13]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZpQuG-000114-Ex; Fri, 23 Oct 2015 03:12:33 +0200
To: Brian E Carpenter , "Hemant Singh (shemant)" , Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <562985AA.7030202@gont.com.ar>
Date: Thu, 22 Oct 2015 21:56:10 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562957D8.4040001@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 01:12:54 -0000

Hi, Brian,

On 10/22/2015 06:40 PM, Brian E Carpenter wrote:
>> [For all unicast addresses, except those that start with the binary
>>  value 000, Interface IDs are required to be 64 bits long and to be
>>  constructed in Modified EUI-64 format.]
> 
> To be precise, that text is obsoleted by RFC 7136 (and rfc4291bis):
> http://tools.ietf.org/html/rfc7136#section-5
> 
> Neverthless, the 64 bit length is *not* required by SLAAC. Rather, it's
> a parameter for SLAAC.

Well...this is kind of an artifact of the fact that SLAAC currently
requires that IIDs must be derived of an IEEE LAN MAC address.. hence
they have to be in MOdified EUI-64 format, and hence they must be 64
bit. -- I guess your argument was that it's not SLAAC but RFC4291 that
requires this?


> Any SLAAC code that treats it as a constant is faulty:
> http://tools.ietf.org/html/rfc7421#section-1
> 
> But in reality, it's a parameter that's always set to 64. So for anything to
> actually work, if you assign a /63 to a host, it will have to contain
> extra logic to assign the two halves of that as two /64s, and to decide
> which one to use.

Well, If they do RFC7217, they do not need any extra logic ;-)

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 Oct 22 19:11:46 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0284A1B30AD for ; Thu, 22 Oct 2015 19:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMBTZFc3dhhu for ; Thu, 22 Oct 2015 19:11:39 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091341B30AB for ; Thu, 22 Oct 2015 19:11:38 -0700 (PDT)
Received: by pasz6 with SMTP id z6so103079327pas.2 for ; Thu, 22 Oct 2015 19:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4/diE55j/+V3h9R7UIOXT8DoQEBAd6Y/A3gpQqkxYl8=; b=qjLvrJwbtGxBT3c/OkH5vE19c2GjHGDOcWuCPSy2qnZ0dTLl15xHqqh/xS/OTCcTJ4 UBH2bdWx5+iX630gHlg7Ph91O/lJOgML+ECEyBuJtte2MBLslwHzmHpAgbP8DqyhGrt9 p91y9WNweQ1GPY1Mx4YFbPR7WCWkd+cK0ScaY05b2dOgqzwg+PMXwG+2nrvE0/pjnbB8 RHMoc5OApoPIwSU3UZ+H+TqfjGKaIUw83RYOLaH/vqKpztAMM12aDh/17iat1W2IftO8 h0YVwCGcNgyD3OSwCbG6cEvLzEzX4oweCo86+eW/NggupeO9QApUWQuX/lyTBbvQvrwX 9+yg==
X-Received: by 10.66.193.134 with SMTP id ho6mr1819998pac.52.1445566298587; Thu, 22 Oct 2015 19:11:38 -0700 (PDT)
Received: from ?IPv6:2406:e007:572b:1:28cc:dc4c:9703:6781? ([2406:e007:572b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id im9sm16045401pbc.1.2015.10.22.19.11.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2015 19:11:36 -0700 (PDT)
To: Fernando Gont , "Hemant Singh (shemant)" , Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5629975E.6040702@gmail.com>
Date: Fri, 23 Oct 2015 15:11:42 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562985AA.7030202@gont.com.ar>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 02:11:45 -0000

On 23/10/2015 13:56, Fernando Gont wrote:
> Hi, Brian,
> 
> On 10/22/2015 06:40 PM, Brian E Carpenter wrote:
>>> [For all unicast addresses, except those that start with the binary
>>>  value 000, Interface IDs are required to be 64 bits long and to be
>>>  constructed in Modified EUI-64 format.]
>>
>> To be precise, that text is obsoleted by RFC 7136 (and rfc4291bis):
>> http://tools.ietf.org/html/rfc7136#section-5
>>
>> Neverthless, the 64 bit length is *not* required by SLAAC. Rather, it's
>> a parameter for SLAAC.
> 
> Well...this is kind of an artifact of the fact that SLAAC currently
> requires that IIDs must be derived of an IEEE LAN MAC address.. hence
> they have to be in MOdified EUI-64 format, and hence they must be 64
> bit. -- I guess your argument was that it's not SLAAC but RFC4291 that
> requires this?

Yes. So if you are writing "correct" SLAAC code it definitely needs to be a
variable that's initialised separately for each interface, and as it happens
will always be initialised to 64.

> 
> 
>> Any SLAAC code that treats it as a constant is faulty:
>> http://tools.ietf.org/html/rfc7421#section-1
>>
>> But in reality, it's a parameter that's always set to 64. So for anything to
>> actually work, if you assign a /63 to a host, it will have to contain
>> extra logic to assign the two halves of that as two /64s, and to decide
>> which one to use.
> 
> Well, If they do RFC7217, they do not need any extra logic ;-)

Correct. There's a sneaky little "at least 64" in there which would
allow for generation of 65 bit IIDs, if anybody really tried to implement
a /63 subnet ;-)

    Brian


From nobody Thu Oct 22 23:55:49 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6D1B2D2B for ; Thu, 22 Oct 2015 23:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ7TNRMTxu5J for ; Thu, 22 Oct 2015 23:55:46 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7381B2D28 for ; Thu, 22 Oct 2015 23:55:45 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8A7F36325A for ; Fri, 23 Oct 2015 08:55:43 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3F41960A5A for ; Fri, 23 Oct 2015 08:55:43 +0200 (CEST)
Received: (qmail 21287 invoked by uid 1007); 23 Oct 2015 08:55:43 +0200
Date: Fri, 23 Oct 2015 08:55:43 +0200
From: Gert Doering 
To: Brian E Carpenter 
Message-ID: <20151023065543.GA70452@Space.Net>
References:  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNY+9Zst+/98ADCY"
Content-Disposition: inline
In-Reply-To: <5629975E.6040702@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" , Fernando Gont 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 06:55:48 -0000

--PNY+9Zst+/98ADCY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Oct 23, 2015 at 03:11:42PM +1300, Brian E Carpenter wrote:
> Correct. There's a sneaky little "at least 64" in there which would
> allow for generation of 65 bit IIDs, if anybody really tried to implement
> a /63 subnet ;-)

Interesting RFC and code interpretations aside - could someone remind me
why a /63 would have any advances over a /64, like "the /64 is not big
enough"?

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--PNY+9Zst+/98ADCY
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVinZ799WwGXkzn/FAQJOwg/8Dc3X7G0cXTrgKF/xlj50wURquaBaEtrZ
JUSrLXBIei3QMSqDc+fyMoePu/FDXCKEq/RmLpx0P8gJu4WZ6BKpXl7BMbwLWzRj
FLB5LRg3ifTW+U9kD2HCsfyHYrydktz0RfkrVRhOkew3ANwE2mHSviPaGP+5gi4I
Hjgt2aWy05s3CN8Nj0h4rd2RFNe6NDf0DsrRfZ5hU3/Qm+P3n2JWEnYfIcJjlmJm
Vp38WJrgGnyb6x+thM+hoDc9foO7+KR10gJjCDTN5zr+yGU+2u45J8Ik/MH7IZt5
8Y8wGCw6qkADqBIyOyzoOzDWJX0+wAWqK8jJ0shpbPOJMJkjEeoQcDebZRlR9q6L
kivHO5lFKXyvzxYEmVrFPZs6b36N/O4DHXwu3DIzNHFoi2eJCqZ/LVPPKePNmWnx
r7RtVpPLDcvBgl722bEq2GueSa2FAQrT0XNqcxkR7dwwhSjSzVSD+gTjamq110Uq
f8DuNtgHONaZow777lSZFDobrMYs1wYoNjq7KbBuz0z5ztGIQ0Z01oYZuMjx7uSb
TzApG94l8n7VACWdAfaWFiPXevZnJci/JrTw3CYfFRhQt+v/V0sfRTwZad/lKcHT
2raQ4IoWaVpG6k3QTeeywEi+7BwQZtjttIQuV1U8RO9f2nimFf9BgXsW1dR9/Tb7
4fE84knhI9g=
=Gl1L
-----END PGP SIGNATURE-----

--PNY+9Zst+/98ADCY--


From nobody Fri Oct 23 00:49:00 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7491B2F3D for ; Fri, 23 Oct 2015 00:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oernu7WmplwA for ; Fri, 23 Oct 2015 00:48:54 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD9A1B2FB7 for ; Fri, 23 Oct 2015 00:48:52 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=48006 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZpX5i-00058V-Kv; Fri, 23 Oct 2015 09:48:46 +0200
Date: Fri, 23 Oct 2015 09:48:44 +0200
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20151023094844.1d596787@envy.fud.no>
In-Reply-To: <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 07:48:58 -0000

* otroan@employees.org

> Alex,
> 
> >> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
> > 
> > Why?
> 
> that would violate IPv6 standards. and common implementations don't
> support it either.
> 
> e.g.:

FWIW, Linux is the same:

if (pinfo->prefix_len == 64) {
	/* SLAAC stuff here */
	goto ok;
}
net_dbg_ratelimited("IPv6 addrconf: prefix with wrong length %d\n",
		    pinfo->prefix_len);

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c#n2418

Tore


From nobody Fri Oct 23 01:03:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1EE1B32E9 for ; Fri, 23 Oct 2015 01:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwpBVU5sUkNv for ; Fri, 23 Oct 2015 01:03:43 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CF61B32E8 for ; Fri, 23 Oct 2015 01:03:43 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 627BBD7895; Fri, 23 Oct 2015 01:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=AVMOpkF2AHpQ2AVrZH6jYBwroXg=; b= driSghDznIpzk2OTj1qMvt8+4zsaekFavxnQrTavXKt+K1aQDrf0Qfs6OQsuwj+J 75EFJT5KwsBUDqs/hlrA3Hx6ZYk6hwyxjct9d77b3PpfxZIFLxX7aRZ6OanieZp/ oisBXuGBZbd3PcFe+H0JD2K3DlJE9WlTkbc3xjh4ZUk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=TWAo7JdTIBd2TwefKLW3UVEYMT MbSYqnGPU7AOF3rg1Q1hVdRd1tOTZFS9ytBkWaPDxRtU/8EA6hT7Sfw2RoJEyKzM vf7Rc6qxOFhtG7BqVqUQrBCBmibF5kCM+3wj2J6YVbBH4cqb/lCJELdhzgGkB/9r NDvVMX3wW2OZeN4sA=
Received: from h.hanazo.no (unknown [173.38.220.56]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 30FF1D7893; Fri, 23 Oct 2015 01:03:42 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 593AF7C9D7B; Fri, 23 Oct 2015 10:03:41 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E8FDA1B8-4CF7-4AA1-BB0E-A02AC11C67AC"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <20151023065543.GA70452@Space.Net>
Date: Fri, 23 Oct 2015 10:03:40 +0200
Message-Id: <140BD8C3-8FF1-4229-8EBB-DB96C17B273B@employees.org>
References:  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "v6ops@ietf.org" , Fernando Gont , "Brzozowski, John" 
Subject: [v6ops] Adding links [was: draft-jjmb...]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:03:44 -0000

--Apple-Mail=_E8FDA1B8-4CF7-4AA1-BB0E-A02AC11C67AC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Gert,

[changed subject]

>> Correct. There's a sneaky little "at least 64" in there which would
>> allow for generation of 65 bit IIDs, if anybody really tried to =
implement
>> a /63 subnet ;-)
>=20
> Interesting RFC and code interpretations aside - could someone remind =
me
> why a /63 would have any advances over a /64, like "the /64 is not big
> enough"?

I think people are trying to solve the problem of extending an existing =
network ad-hoc with more links. if that's for tethering or VMs.
possibly with or without the consent of the network operator. the latter =
case obviously being a tricky arms race.

I don't see how /63 in an RA would be any part of a solution to that =
problem obviously.

DHCP-PD, HNCP, bridging, NAT, sub-netting /64/proxy-ND/multilink subnets
anything I've forgotten from the potential solution space?

Best regards,
Ole

--Apple-Mail=_E8FDA1B8-4CF7-4AA1-BB0E-A02AC11C67AC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWKendAAoJEL7aWKiYQt924IgP/jLcFRS7YH26sA6rJGqcYIKw
CsvhykfkPqe0H1Kq7FHK324lTpOjPlFfnM+McIx2iOU7bKTwFG8IFN/YhRpnd7i1
kJqv60dThShERyh7Rj4J0/tID1X4MCmQvSfN9N/748nk5V+69KNKtTP40GAuay8a
02hoEORdVNCqZDjRZ7HRzTbVHh1IWJIXxcTXI2XV51ta5F3fj3MyyZa1VklkASbx
515npjGaWuWKD6gwlr/yVHHda7lqQHKZ0xiCWW90UWWzVLdLwnQTBldnQqMI6Odq
/peBF+uPx0Njj/+5uQlG87fRinKWcFw+/DZHT8dvEmSqb2MVaNHWyCOCY1lu7gAn
AAc91YwPLfaCZRfpbz0fR8jIbMK1D9JiqRfZ5BFEY7Amt8PgjoReCiVxYx2nGFxH
rhjgrOdGpcTo+yoU/M2DfhaTHdOr1SSim56UX3VMZSYvR2bludo73urixc8gbS61
oVezFsMv/PjL445otWw97/HOmV67b+4oc93Ncr9bpFTIr77AgHzBoKn31fUoWccG
nEi6VcJyfCTnX2lT9PegilAnb5kN9nN/Tp0C3s6MGA9RMFJcMmjMYCk8dXZIItas
I47IifqGfv9szJIAvqkIdRLc+2nj3WlcA5uIsScB7xmLt482Lk4ahkA9mxEsNapj
MdKTv5tVCc6nibj7Ky6J
=zbfz
-----END PGP SIGNATURE-----

--Apple-Mail=_E8FDA1B8-4CF7-4AA1-BB0E-A02AC11C67AC--


From nobody Fri Oct 23 01:23:24 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927EB1B3303 for ; Fri, 23 Oct 2015 01:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7zTvQp3IsLm for ; Fri, 23 Oct 2015 01:23:07 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EB21B314F for ; Fri, 23 Oct 2015 01:23:07 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N8N2rp024078; Fri, 23 Oct 2015 10:23:02 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89A73203B3C; Fri, 23 Oct 2015 10:28:45 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 74EF1203AE9; Fri, 23 Oct 2015 10:28:45 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.236]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N8N07s006870; Fri, 23 Oct 2015 10:23:02 +0200
To: "Brzozowski, John" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <5629EE64.1060402@gmail.com>
Date: Fri, 23 Oct 2015 10:23:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:23:11 -0000

Yes, thanks.

As a network operator it is good to accommodate as many devices as 
possible and that goes way beyond the current smartphones like the ones 
you cite.

Alex

Le 22/10/2015 19:08, Brzozowski, John a écrit :
> We can consider this for future work.
>
> To date we have tested with a wide range of Android, Apple, and Windows
> Wi-Fi enabled devices.  All have been verified and work properly, as such
> we have not excluded any devices.  Our goal has been to be as inclusive as
> possible.  What is documented is, in general, what will be rolled out.
>
> John
> +1-484-962-0060
>
>
>
>
> -----Original Message-----
> From: Alexandre Petrescu 
> Date: Thursday, October 22, 2015 at 12:15
> To: John Jason Brzozowski 
> Cc: v6ops 
> Subject: Re: [v6ops] Fwd: I-D Action:
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>>
>>
>> Le 22/10/2015 16:06, Brzozowski, John a écrit :
>>> Ole responded to the use of the /63.
>>
>> Well.
>>
>>> Regarding your use of this, I am curious which implementation and how
>>> many
>>> devices are operating using a /63?
>>
>> If the goal is to minimize the importance of a small number of devices
>> then the goal is reached.
>>
>> The implementation is with linux, radvd software and a PMIP
>> implementation.
>>
>> The question of 63 is little dependent on PMIP.
>>
>> If the question is about whether a Host can use SLAAC to self-configure
>> an address out of a /63 then the answer is yes.  The implementation
>> inserts a 0 at the 64th position.  Everybody does that, nobody inserts a
>> 1.
>>
>> Am I answering?
>>
>>> Finally, someone from Google/Android will have to comment on Android and
>>> DHCPv6 for PD support.  I also believe Apple does not support PD yet on
>>> their devices either.  Like the draft says this is future work, we will
>>> see where this goes.
>>
>> Instead of further work we can just modify a number (64 to 63).
>>
>> Alex
>>
>>>
>>> John
>>> +1-484-962-0060
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Alexandre Petrescu 
>>> Date: Thursday, October 22, 2015 at 09:25
>>> To: John Jason Brzozowski 
>>> Cc: v6ops 
>>> Subject: Re: [v6ops] Fwd: I-D Action:
>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>
>>>>
>>>>
>>>> Le 22/10/2015 15:15, Brzozowski, John a écrit :
>>>>> Thanks for the comments, see below.
>>>>>
>>>>> -----Original Message-----
>>>>>
>>>>> From: v6ops  on behalf of Alexandre Petrescu
>>>>>     Date: Thursday, October 22, 2015 at
>>>>> 08:47 To: v6ops  Subject: Re: [v6ops] Fwd: I-D
>>>>> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Assigning a prefix-per-host in a WiFi deployment, rather than an
>>>>>> individual addresses within a same prefix, has also been
>>>>>> considered in Proxy Mobile IP deployments and it works ok.  It has
>>>>>> some advantages, and some inconvenients, depending how it's done.
>>>>>>
>>>>>> I have some comments on the draft.
>>>>>>
>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>> If radius server discovers that the UE/ subscriber is a fresh
>>>>>>> device trying to gain access onto the Wi-Fi network it will
>>>>>>> identify some parameters (e.g.  IPv6 /64 prefix)
>>>>>> [...]
>>>>>>> This RA contains a few important parameters for the EU/
>>>>>>> subscriber to consume: (1) a /64 prefix and (2) flags.
>>>>>>
>>>>>> I would like to suggest to substitute /63 for /64 throughout the
>>>>>> document.  A /64 will not allow smartphones to tether cleanly.
>>>>>
>>>>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>>>>
>>>> Why?
>>>>
>>>>> we have already tested the use of a /64 and will likely maintain
>>>>> this for our deployment of IPv6 for community Wi-Fi.
>>>>
>>>> Well it is good for that community.
>>>>
>>>> In this respect, I dont think what the community uses should be an
>>>> example for other communities (a BCP).
>>>>
>>>> I use 63 and works fine.
>>>>
>>>>> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
>>>>> utilized.
>>>>
>>>> I hear Android not supporting DHCP at this time, so PD would be a pain.
>>>>
>>>> On another hand, just change 64 to 63 will make tethering smartphones
>>>> work fine without needing DHCP, nor DHCP-PD.
>>>>
>>>>>> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
>>>>>> boundary..."
>>>>>>
>>>>>> For a discussion of why 63 - where to start?
>>>>>>
>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>> The WLAN-GW will use the received Radius information to compose
>>>>>>> the response to the UE/subscriber originated RS message.  The
>>>>>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>>>>>> the UE/ subscriber.  This RA contains a few important parameters
>>>>>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>>>>>> flags.
>>>>>>
>>>>>> Since a captive portal is used, it would make sense to use the
>>>>>> Captive Portal IPv6 RA Option as well
>>>>>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
>>>>> [jjmb] we will take a look at this draft to determine applicability.
>>>>> Stay tuned.
>>>>>>
>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>> When a new UE connects to the community Wi-Fi it connects to the
>>>>>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>>>>>> advertised for use as part of the community Wi-Fi offering.
>>>>>>
>>>>>> But some community networks use a 'hidden' SSID, known only by
>>>>>> members of that community.
>>>>> [jjmb] hidden should work as well, providing the end user knows the
>>>>> name of the SSID.  We will look to see if there are clarifications
>>>>> we can make to address this.
>>>>
>>>> Ok.
>>>>
>>>> Alex
>>>>
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>>>>>>> Posted yesterday. Your comment solicited.
>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org Subject: I-D Action:
>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>>>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>>>>>>  Reply-To: internet-drafts@ietf.org
>>>>>>>>
>>>>>>>>
>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>> Internet-Drafts directories.
>>>>>>>>
>>>>>>>>
>>>>>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>>>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>>>>>> Date : 2015-10-19
>>>>>>>>
>>>>>>>> Abstract: In some IPv6 environments the need has arisen for
>>>>>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>>>>>> the link or media may be shared.  Typically hosts
>>>>>>>> (subscribers) on a shared network, like Wi- Fi or Ethernet,
>>>>>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>>>>>> that is allocated or assigned for use on a specific link.
>>>>>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>>>>>> address from the service provider are going from enhanced
>>>>>>>> subscriber management to improved isolation between
>>>>>>>> subscribers.
>>>>>>>>
>>>>>>>> In most deployments today IPv6 address assignment from a single
>>>>>>>> IPv6 prefix on a shared network is done by either using IPv6
>>>>>>>> stateless address auto-configuration (SLAAC) and/or stateful
>>>>>>>> DHCPv6.  While this is still viable and operates as designed
>>>>>>>> there are some large scale environments where this concept
>>>>>>>> introduces significant performance challenges and implications,
>>>>>>>> specifically related to IPv6 router and neighbor discovery.
>>>>>>>> This document outlines an approach utilising existing IPv6
>>>>>>>> protocols to allow hosts to be assigned a unique IPv6 prefix
>>>>>>>> (instead of a unique IPv6 address from a shared IPv6 prefix).
>>>>>>>>
>>>>>>>>
>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-prefix
>>>>>>>> -p
>>>>>>>> er
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> -host/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> There's also a htmlized version available at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-
>>>>>>>> ho
>>>>>>>> st
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> -00
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission
>>>>>>>> until the htmlized version and diff are available at
>>>>>>>> tools.ietf.org.
>>>>>>>>
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>
>>>>>>>> _______________________________________________ I-D-Announce
>>>>>>>> mailing list I-D-Announce@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>>>>>    ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ v6ops mailing
>>>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ v6ops mailing list
>>>>>>    v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From nobody Fri Oct 23 01:23:26 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1F1B314F for ; Fri, 23 Oct 2015 01:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgEYWEpPlhvx for ; Fri, 23 Oct 2015 01:23:11 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2C31B32FF for ; Fri, 23 Oct 2015 01:23:10 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N8N8tT024123 for ; Fri, 23 Oct 2015 10:23:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A42C1203B16 for ; Fri, 23 Oct 2015 10:28:51 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9C0CC202AC7 for ; Fri, 23 Oct 2015 10:28:51 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.236]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N8N8gH007099 for ; Fri, 23 Oct 2015 10:23:08 +0200
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com>
From: Alexandre Petrescu 
Message-ID: <5629EE6C.1050904@gmail.com>
Date: Fri, 23 Oct 2015 10:23:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562957D8.4040001@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:23:15 -0000

Le 22/10/2015 23:40, Brian E Carpenter a écrit :
> On 23/10/2015 06:12, Hemant Singh (shemant) wrote:
>>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
>> Sent: Thursday, October 22, 2015 12:57 PM
>> To: Gert Doering
>> Cc: v6ops@ietf.org; Brzozowski, John
>> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>
>>> No no, SLAAC RFC is not defined for any particular length.
>>>
>>> _Ethernet_ IID length in RFC2464 is defined to be 64.
>>
>>
>> >From RFC 4291, there is this text.
>>
>> [For all unicast addresses, except those that start with the binary
>>   value 000, Interface IDs are required to be 64 bits long and to be
>>   constructed in Modified EUI-64 format.]
>
> To be precise, that text is obsoleted by RFC 7136 (and rfc4291bis):
> http://tools.ietf.org/html/rfc7136#section-5
>
> Neverthless, the 64 bit length is *not* required by SLAAC. Rather, it's
> a parameter for SLAAC. Any SLAAC code that treats it as a constant is faulty:
> http://tools.ietf.org/html/rfc7421#section-1
>
> But in reality, it's a parameter that's always set to 64. So for anything to
> actually work, if you assign a /63 to a host, it will have to contain
> extra logic to assign the two halves of that as two /64s, and to decide
> which one to use.

YEs, that is possible.

IT may also decide to not use any, but make two 65s out of it and use 
them in its LAN subnets.

Alex

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


From nobody Fri Oct 23 01:24:40 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B61B3300 for ; Fri, 23 Oct 2015 01:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.683
X-Spam-Level: 
X-Spam-Status: No, score=-3.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_SUMOF=1, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OIab1Qxhrh5 for ; Fri, 23 Oct 2015 01:24:37 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B64D1B32FF for ; Fri, 23 Oct 2015 01:24:36 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N8OWiF019592; Fri, 23 Oct 2015 10:24:32 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3489B202B5F; Fri, 23 Oct 2015 10:30:15 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 242EC202AC7; Fri, 23 Oct 2015 10:30:15 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.240]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N8OVCf008131; Fri, 23 Oct 2015 10:24:32 +0200
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <5629EEBE.7010908@gmail.com>
Date: Fri, 23 Oct 2015 10:24:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:24:40 -0000

Le 22/10/2015 19:54, 神明é”哉 a écrit :
> At Thu, 22 Oct 2015 18:56:54 +0200, Alexandre Petrescu
>  wrote:
>
>>> No, it shouldn't.  SLAAC is well-defined *exactly* for /64, and
>>> for nothing else.
>>
>> No no, SLAAC RFC is not defined for any particular length.
>>
>> _Ethernet_ IID length in RFC2464 is defined to be 64.
>
> So you are assuming the 64-bit IID in your scenario, right?  Then,
>
>>> If you believe a /63 is legal, show the relevant RFC that
>>> explains how SLAAC is done for non-/64 cases.
>>
>> I believe /63 prefixlength is legal yes.
>>
>> SLAAC is done for any  length, the doc does not say 64.
>
> no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
> length is 64 on a link whose IID is supposed to be 64 bits violates
> Section 5.5.3 d of RFC 4862:
>
> If the sum of the prefix length and interface identifier length does
> not equal 128 bits, the Prefix Information option MUST be ignored.

That is what the SLAAC RFC says, yes.

But more precisely, that is a requirement on the sum, not on the value
of _any_ of its parts.

Given a 63 prefix len to that sum, the IID length must be 65.  And that
IID len 65 is wrong compared to RFC2464/4191 requiring the IID len to be 64.

Can we conclude that because of that wrongness, the SLAAC RFC is wrong
with respect to RFC2464-RFC4191?  I dont think so.  Again because the
requirement in SLAAC RFC is on the _sum_ not on the value of the parts.

So, if we can't think that the SLAAC RFC is wrong with respect to
RFC4191-2464 for the IID length being 65, then we can think that is
wrong with respect to a prefix length being 63.  It's just the sum that
must be respected.

Alex


>
> -- JINMEI, Tatuya
>


From nobody Fri Oct 23 01:24:59 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829101B32FF for ; Fri, 23 Oct 2015 01:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye44TEG40WJy for ; Fri, 23 Oct 2015 01:24:53 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36891B32F9 for ; Fri, 23 Oct 2015 01:24:52 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N8OmOd019692 for ; Fri, 23 Oct 2015 10:24:51 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B341E203AD1 for ; Fri, 23 Oct 2015 10:30:33 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AAD24202B5F for ; Fri, 23 Oct 2015 10:30:33 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.240]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N8OogC008295 for ; Fri, 23 Oct 2015 10:24:50 +0200
To: v6ops@ietf.org
References:  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <5629EED2.8050000@gmail.com>
Date: Fri, 23 Oct 2015 10:24:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151023065543.GA70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:24:54 -0000

Le 23/10/2015 08:55, Gert Doering a écrit :
> Hi,
>
> On Fri, Oct 23, 2015 at 03:11:42PM +1300, Brian E Carpenter wrote:
>> Correct. There's a sneaky little "at least 64" in there which
>> would allow for generation of 65 bit IIDs, if anybody really tried
>> to implement a /63 subnet ;-)
>
> Interesting RFC and code interpretations aside - could someone remind
> me why a /63 would have any advances over a /64, like "the /64 is not
> big enough"?

Hi Gert,

Let me start by a negation, as much as I dont like them.  We saw in
other discussions, the number in "/64" is not relevant to size or number
of devices.  Even if 2^64 looks like a big number, it does not mean we
can put that many devices in a subnet, obstacled by link layer
characteristics.

Then, using a "/63" rather than a "/64" prefix assigned (for a certain
interpretation of the word 'assigned') to a device may allow it to
tether cleanly: a smartphone receiving a /63 will be able to create two
"/64"s out of it.  It will 'assign' one so created '/64' for its
bluetooth interface and another one deeper in its LAN.

On another hand, 'assigning' a /64 to a smartphone, even if it allows it
to create two /65s, these are useless for SLAAC in its LAN segments,
because of that Ethernet IID length being 64, and 64+65 being larger
than 128.

Alex

>
> Gert Doering -- NetMaster
>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Fri Oct 23 01:25:37 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A65A1B3317 for ; Fri, 23 Oct 2015 01:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level: 
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7KaXXFCcqHw for ; Fri, 23 Oct 2015 01:25:31 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80AA1B3315 for ; Fri, 23 Oct 2015 01:25:29 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N8PPva013523; Fri, 23 Oct 2015 10:25:26 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 939A6203B39; Fri, 23 Oct 2015 10:31:08 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 77A53203AA9; Fri, 23 Oct 2015 10:31:08 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.240]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N8PNn4008703; Fri, 23 Oct 2015 10:25:24 +0200
From: Alexandre Petrescu 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> 
Message-ID: <5629EEF3.3080404@gmail.com>
Date: Fri, 23 Oct 2015 10:25:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:25:33 -0000

Le 22/10/2015 19:43, 神明é”哉 a écrit :
[...]
> Regarding the main context, I don't know how advertising /63 helps
> the tethering scenario, btw.

Giving a '/63' to the smartphone allows it to create some '/64's out of
it.  They are useful for SLAAC in its LAN segments.  Giving it a '64'
allows it to create '65's which can not be used with SLAAC in its LAN
segments.

Alex

>
> -- JINMEI, Tatuya
>


From nobody Fri Oct 23 01:35:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396DA1B332C for ; Fri, 23 Oct 2015 01:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYTKb-ypAcI6 for ; Fri, 23 Oct 2015 01:34:59 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 88EE41B3332 for ; Fri, 23 Oct 2015 01:34:59 -0700 (PDT)
Received: from [181.165.127.203] (helo=[192.168.2.101]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZpXoM-0003VU-Ux; Fri, 23 Oct 2015 10:34:55 +0200
To: Gert Doering , Brian E Carpenter 
References:  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <5629DD19.7090001@si6networks.com>
Date: Fri, 23 Oct 2015 04:09:13 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151023065543.GA70452@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , Fernando Gont , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:35:03 -0000

On 10/23/2015 03:55 AM, Gert Doering wrote:
> Hi,
> 
> On Fri, Oct 23, 2015 at 03:11:42PM +1300, Brian E Carpenter wrote:
>> Correct. There's a sneaky little "at least 64" in there which would
>> allow for generation of 65 bit IIDs, if anybody really tried to implement
>> a /63 subnet ;-)
> 
> Interesting RFC and code interpretations aside - could someone remind me
> why a /63 would have any advances over a /64, like "the /64 is not big
> enough"?

Well, me, I never really thought of /63 but rather of longer prefixes
(e.g. /80 or whatever). If we start heading in the "/63 subnets"
direction, then the (eventual) need for IPv7 starts to look not so crazy...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Oct 23 01:56:11 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67221B335F for ; Fri, 23 Oct 2015 01:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdjcFgO2vAJR for ; Fri, 23 Oct 2015 01:56:09 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A891B3360 for ; Fri, 23 Oct 2015 01:56:06 -0700 (PDT)
Received: by vkgs66 with SMTP id s66so410224vkg.1 for ; Fri, 23 Oct 2015 01:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9tnh95SAnL0dAvObMJ8N3gSZJDuOebRO0L/lykhSHxk=; b=dczR8Vf7v5PAe1294ycRHC9Xdkw/GS798fxKGLhSgYALRaM2QXZLkSOkJkWG5xIgWb OOGTnz43rMQSIAP0eZSpJind7bIy32+xhB+iot7AyRd1Om2FG5JvsN+t5DXD4rSDskCP b4a6X5OnLjpuAFyxnoXS5dJjw5LKyfVKobLm84Yu8UvYaAXt/8U6bScWtIuaDWagcSN2 711stSCm7AidSzTWjEgD+655Nwe0W40GzSAA6+0tbPKs48BT7OziW02IkMjfgV0noSPM RaSHLculvLpo5gWJ70eiiRx7Jd6mBFRiUOkWRY0bAqb+4SwE37GdICBLVMKMygV6n5QH T73g==
X-Received: by 10.31.132.79 with SMTP id g76mr12559114vkd.40.1445590565516; Fri, 23 Oct 2015 01:56:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.67.194 with HTTP; Fri, 23 Oct 2015 01:55:36 -0700 (PDT)
In-Reply-To: <5629EEF3.3080404@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>
From: Mark Smith 
Date: Fri, 23 Oct 2015 19:55:36 +1100
Message-ID: 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 08:56:10 -0000

On 23 October 2015 at 19:25, Alexandre Petrescu
 wrote:
>
>
> Le 22/10/2015 19:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9crit :
> [...]
>>
>> Regarding the main context, I don't know how advertising /63 helps
>> the tethering scenario, btw.
>
>
> Giving a '/63' to the smartphone allows it to create some '/64's out of
> it.

Does code exist that already does this? If it doesn't, why wouldn't it
be better to implement DHCPv6-PD, the existing, tested and proven
mechanism to do this sort of thing?



>  They are useful for SLAAC in its LAN segments.  Giving it a '64'
> allows it to create '65's which can not be used with SLAAC in its LAN
> segments.
>
> Alex
>
>>
>> -- JINMEI, Tatuya
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Oct 23 02:03:58 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEEC1B3368 for ; Fri, 23 Oct 2015 02:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIUkmki6oG6h for ; Fri, 23 Oct 2015 02:03:55 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA63D1B3366 for ; Fri, 23 Oct 2015 02:03:54 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N93b5V030319; Fri, 23 Oct 2015 11:03:37 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C18F8203A43; Fri, 23 Oct 2015 11:09:19 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6F74203A83; Fri, 23 Oct 2015 11:09:19 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N93Zdk004272; Fri, 23 Oct 2015 11:03:36 +0200
From: Alexandre Petrescu 
To: Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com> <20151022172819.GV70452@Space.Net>
Message-ID: <5629F7E7.9040707@gmail.com>
Date: Fri, 23 Oct 2015 11:03:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151022172819.GV70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 09:03:56 -0000

Le 22/10/2015 19:28, Gert Doering a écrit :
> [..]
>> The SLA-ID is wrong compared to my /56 allocation.
>
> Your allocation is an allocation, and not an on-link prefix.  So it does
> not have any meaning for this discussion.

But it is the same: that RFC not only requires the IID length to be 64 
but requires other parts of the IPv6 address to have some particular 
length.  In particular, it requires the SLA-ID to have a particular 
length.  In practice, that length is ignored by everybody.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Fri Oct 23 02:04:04 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE321B336D for ; Fri, 23 Oct 2015 02:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPoVhauSilha for ; Fri, 23 Oct 2015 02:03:58 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4A31B3366 for ; Fri, 23 Oct 2015 02:03:57 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N93qrX030534; Fri, 23 Oct 2015 11:03:52 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 33D2A203B1A; Fri, 23 Oct 2015 11:09:35 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 19852203A83; Fri, 23 Oct 2015 11:09:35 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N93pGw004576; Fri, 23 Oct 2015 11:03:52 +0200
From: Alexandre Petrescu 
To: "Hemant Singh (shemant)" , Gert Doering 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com> 
Message-ID: <5629F7F8.5080000@gmail.com>
Date: Fri, 23 Oct 2015 11:03:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 09:04:00 -0000

Le 22/10/2015 19:12, Hemant Singh (shemant) a écrit :
>
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Thursday, October 22, 2015 12:57 PM
> To: Gert Doering
> Cc: v6ops@ietf.org; Brzozowski, John
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>> No no, SLAAC RFC is not defined for any particular length.
>>
>> _Ethernet_ IID length in RFC2464 is defined to be 64.
>
>
>>From RFC 4291, there is this text.
>
> [For all unicast addresses, except those that start with the binary
>   value 000, Interface IDs are required to be 64 bits long and to be
>   constructed in Modified EUI-64 format.]

Yes, I agree.  There are thus two places which require the IID length to 
be 64: one is the Ethernet IID (all IPv6 over foo) and the other is the 
Architecture RFC.

There is however no place which explicitely requires the prefix length 
in RA to be 64.

Alex

>
> Hemant
>


From nobody Fri Oct 23 02:14:03 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF561B3385 for ; Fri, 23 Oct 2015 02:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDIeY_1TYtW7 for ; Fri, 23 Oct 2015 02:14:01 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603C51B2D7B for ; Fri, 23 Oct 2015 02:14:00 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9N9Dssr009376; Fri, 23 Oct 2015 11:13:54 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D440203BDF; Fri, 23 Oct 2015 11:19:37 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17570203BB7; Fri, 23 Oct 2015 11:19:37 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9N9DrnR017408; Fri, 23 Oct 2015 11:13:54 +0200
To: Mark Smith 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <5629FA51.4000807@gmail.com>
Date: Fri, 23 Oct 2015 11:13:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 09:14:02 -0000

Le 23/10/2015 10:55, Mark Smith a écrit :
> On 23 October 2015 at 19:25, Alexandre Petrescu
>  wrote:
>>
>>
>> Le 22/10/2015 19:43, 神明é”哉 a écrit : [...]
>>>
>>> Regarding the main context, I don't know how advertising /63
>>> helps the tethering scenario, btw.
>>
>>
>> Giving a '/63' to the smartphone allows it to create some '/64's
>> out of it.
>
> Does code exist that already does this?

I dont know?

I know that in homenet they have this Prefix Assignment RFC-to-be which 
talks about 'portioning' a prefix.  The problem of automatically making 
sub-prefixes out of a prefix is well sensed in homenets.

> If it doesn't, why wouldn't it be better to implement DHCPv6-PD, the
> existing, tested and proven mechanism to do this sort of thing?

DHCPv6-PD - yes there is software available and it works ok on many 
platforms as I've tried it extensively.

But it looks simpler to make 64s out of a 63 - it's a local decision on
the device.

All the operators must do is not hardcode 64 prefixlengths, i.e. have it 
as a parameter.

Some operators moved from a 64-centric for end-user way of thinking - 
it's a parameter.

Alex

>
>
>
>> They are useful for SLAAC in its LAN segments.  Giving it a '64'
>> allows it to create '65's which can not be used with SLAAC in its
>> LAN segments.
>>
>> Alex
>>
>>>
>>> -- JINMEI, Tatuya
>>>
>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Fri Oct 23 02:47:20 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC11B341C for ; Fri, 23 Oct 2015 02:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHSGq_Oy_HW for ; Fri, 23 Oct 2015 02:47:17 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD991B341A for ; Fri, 23 Oct 2015 02:47:17 -0700 (PDT)
Received: by vkgs66 with SMTP id s66so982251vkg.1 for ; Fri, 23 Oct 2015 02:47:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5sApMM+M/ZbgW0pTVvJJhs06/V3opb8n6Db0dK7mzHA=; b=H17/q/4W0fnPLgWFDG7jrXObF2wdYvwKqSeCb9GEvS29rjqfbb7+a4TN6d82BgvPB3 o3Nf5A2HwrJsXCPJvG7hX3AKQ6w4He9t17oOXKcPa3AFGP3+52yxjhQh0sEBb3GNoOU1 fag8go/fsAjmJqfKsBJfBz0zpYOfTKneckAETReN3o/m+TkAse2DxN3NWB0NyxCu4klo RaitYcxrd0+kF2x0aoARk2w2P7YSgeUhMZhf+r+HiSIaLHDgoMTMblpjG49Pl0YP+kNe WSX/UVFpl1MMRqnzDXAfbYyI4RlPLaiYHD0TIDr8Seb6yi2AI9DerfPe8YqPE8UKAJbj mYnQ==
X-Received: by 10.31.171.142 with SMTP id u136mr12361017vke.132.1445593636886;  Fri, 23 Oct 2015 02:47:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.67.194 with HTTP; Fri, 23 Oct 2015 02:46:47 -0700 (PDT)
In-Reply-To: <5629FA51.4000807@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>  <5629FA51.4000807@gmail.com>
From: Mark Smith 
Date: Fri, 23 Oct 2015 20:46:47 +1100
Message-ID: 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 09:47:19 -0000

On 23 October 2015 at 20:13, Alexandre Petrescu
 wrote:
>
>
> Le 23/10/2015 10:55, Mark Smith a =C3=A9crit :
>>
>> On 23 October 2015 at 19:25, Alexandre Petrescu
>>  wrote:
>>>
>>>
>>>
>>> Le 22/10/2015 19:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9crit =
: [...]
>>>>
>>>>
>>>> Regarding the main context, I don't know how advertising /63
>>>> helps the tethering scenario, btw.
>>>
>>>
>>>
>>> Giving a '/63' to the smartphone allows it to create some '/64's
>>> out of it.
>>
>>
>> Does code exist that already does this?
>
>
> I dont know?
>
> I know that in homenet they have this Prefix Assignment RFC-to-be which
> talks about 'portioning' a prefix.  The problem of automatically making
> sub-prefixes out of a prefix is well sensed in homenets.
>
>> If it doesn't, why wouldn't it be better to implement DHCPv6-PD, the
>> existing, tested and proven mechanism to do this sort of thing?
>
>
> DHCPv6-PD - yes there is software available and it works ok on many
> platforms as I've tried it extensively.
>
> But it looks simpler to make 64s out of a 63 - it's a local decision on
> the device.
>

I don't think it is simpler.

It relies on only one device being on the link.

It relies on the upstream router knowing there is only one device on
the link, so that it doesn't ND NS for any addresses in the space it
is advertising, instead it sends all traffic to the device.

It relies on the link being point to point, because the above
conditions can only be true if the link is a point-to-point link
between a router and host that might want to act as a router if it
decides to.

We end up with:

If ConditionA, ConditionB and ConditionC, then

SolutionY (/63s)

else

SolutionX (DHCPv6-PD)



Where as,


If ConditionA, ConditionB and ConditionC, then

SolutionX (DHCPv6-PD)

else

SolutionX (DHCPv6-PD)


or just


SolutionX (DHCPv6-PD)


will also work for both situations.

The code in a smartphone to do /63s divided into /64s might be simpler
than the code to do DHCPv6-PD. However, there is also code overhead in
the upstream router, and there are also human mental, operational and
troubleshooting overheads, because now there are two solutions to the
same problems which have to be learned, operated, troubleshooted, and
a set of conditions to learn to know which solution will or might be
used when, which is also more human mental overhead.

(The existence of the "sharing /64" RFC shouldn't be seen as an
indication that multiple solutions to this sort of problem is ok - it
has a number of limitations, and is only a work around to 3GPP
freezing feature sets such that for certain devices it isn't possible
to deploy DHCPv6-PD, despite the devices really just being pocket
computers/hosts that just happen to be able to also make phone calls.)

Regards,
Mark.


> All the operators must do is not hardcode 64 prefixlengths, i.e. have it =
as
> a parameter.
>
> Some operators moved from a 64-centric for end-user way of thinking - it'=
s a
> parameter.
>
> Alex
>
>>
>>
>>
>>> They are useful for SLAAC in its LAN segments.  Giving it a '64'
>>> allows it to create '65's which can not be used with SLAAC in its
>>> LAN segments.
>>>
>>> Alex
>>>
>>>>
>>>> -- JINMEI, Tatuya
>>>>
>>>
>>> _______________________________________________ v6ops mailing list
>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>


From nobody Fri Oct 23 02:58:19 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444241B343B for ; Fri, 23 Oct 2015 02:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_slOoYoBv2m for ; Fri, 23 Oct 2015 02:58:15 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015531B3436 for ; Fri, 23 Oct 2015 02:58:15 -0700 (PDT)
Received: by lffv3 with SMTP id v3so77517568lff.0 for ; Fri, 23 Oct 2015 02:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=RbZJkO9pJZQXPbh0mem8vDdZOdrvR4/fTvfsfuabwYM=; b=UojlK6LdwuD2nr5jemginUN/ryGB3ycuhdekpN0dWDH03toTnjmFJhS9P706Df0W2t BBIn4eNY7jkwfxdFt5Kmn56Yl0uXQgU883RifxEKsug0nX1pxa8W0ZRE+zmeH+iWSn80 7DZHKJ66xGGKTJAxx2TThHAzpqokIaTvQ0aKzXc0NKVJWs0ZTP0ovA5zt/4AlhkJkFI4 faq4xRM/2ZjqSin425K7Op84RaJlc1q3VHtQMj0vOiEg41DQ/aMsO8NHoWVkNKUC5mxQ wsJoMQIzdEzu3d4tIVMtb/OfacSEcsLvaw9fEzAT4jV1OpQN9YptseQRDPgwuPRXapoI fzUg==
MIME-Version: 1.0
X-Received: by 10.112.13.136 with SMTP id h8mr10669734lbc.23.1445594293188; Fri, 23 Oct 2015 02:58:13 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.30.108 with HTTP; Fri, 23 Oct 2015 02:58:13 -0700 (PDT)
Date: Fri, 23 Oct 2015 11:58:13 +0200
X-Google-Sender-Auth: 290X2OVwEsuykm1vIBgEYmGg2mU
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: v6ops@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 09:58:16 -0000

[this was originally sent to saag list, and I'm resending it here as
this list is focused on IPv6]

I've been looking on ways to prevent denial of service on a server
application, and I stumbled on IPv6. By denial of service, I mean
exhaustion of resources, being memory or CPU.

Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries
may have 2^80 or even more addresses(*). That means that single IP
blacklisting to prevent DoS is not going to work; not even against a
single adversary who has 2^64 IPs. So one would expect software to
blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
violate some of its "detection properties".  Given recommendations
like RFC6164 which recommend /127 for PtP links (which can be a user
VPN link), any heuristic that will ban whole networks looks more like
a vessel to perform another denial of service (e.g., denying some user
access to a server), rather than a solution to the original denial of
service. This is further reinforced by the fact that smaller than /64 networks
are occasionally handed out by ISPs to their users.

Are there any recommendations for protecting servers from the IPv6
address proliferation? If not, are there any conventions for IPv6
address assignment to end-users?

regards,
Nikos

[0]. rfc6177 is supposed to describe the best current practice, but it
mostly focuses on what isn't the current best practice (i.e., /48 is
not recommended any more)


From nobody Fri Oct 23 04:20:28 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499371B34F3 for ; Fri, 23 Oct 2015 04:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVuQebYu5Lwg for ; Fri, 23 Oct 2015 04:20:24 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8E91B34F4 for ; Fri, 23 Oct 2015 04:20:23 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9NBKICM013541; Fri, 23 Oct 2015 13:20:18 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD4B4206E82; Fri, 23 Oct 2015 13:26:00 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC8A6202415; Fri, 23 Oct 2015 13:26:00 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9NBKGZj006095; Fri, 23 Oct 2015 13:20:17 +0200
To: Mark Smith 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>  <5629FA51.4000807@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <562A17F0.4040309@gmail.com>
Date: Fri, 23 Oct 2015 13:20:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 11:20:26 -0000

Le 23/10/2015 11:46, Mark Smith a écrit :
> On 23 October 2015 at 20:13, Alexandre Petrescu
>  wrote:
>>
>>
>> Le 23/10/2015 10:55, Mark Smith a écrit :
>>>
>>> On 23 October 2015 at 19:25, Alexandre Petrescu
>>>  wrote:
>>>>
>>>>
>>>>
>>>> Le 22/10/2015 19:43, 神明é”哉 a écrit : [...]
>>>>>
>>>>>
>>>>> Regarding the main context, I don't know how advertising /63
>>>>>  helps the tethering scenario, btw.
>>>>
>>>>
>>>>
>>>> Giving a '/63' to the smartphone allows it to create some
>>>> '/64's out of it.
>>>
>>>
>>> Does code exist that already does this?
>>
>>
>> I dont know?
>>
>> I know that in homenet they have this Prefix Assignment RFC-to-be
>> which talks about 'portioning' a prefix.  The problem of
>> automatically making sub-prefixes out of a prefix is well sensed
>> in homenets.
>>
>>> If it doesn't, why wouldn't it be better to implement DHCPv6-PD,
>>> the existing, tested and proven mechanism to do this sort of
>>> thing?
>>
>>
>> DHCPv6-PD - yes there is software available and it works ok on many
>> platforms as I've tried it extensively.
>>
>> But it looks simpler to make 64s out of a 63 - it's a local
>> decision on the device.
>>
>
> I don't think it is simpler.
>
> It relies on only one device being on the link.

Well yes and no.

A possibility is the /63 prefix would be advertised as not being
on-link, and the device would not form a global address out of it.

Also, the case described by the jjmb draft proposes each device a unique
prefix.  Not sure how that translates to subnets and links - maybe there
are several subnets present on a link already.

> It relies on the upstream router knowing there is only one device on
>  the link, so that it doesn't ND NS for any addresses in the space it
>  is advertising, instead it sends all traffic to the device.

That is true, provided the device configures an address within that /63
prefix.

> It relies on the link being point to point, because the above
> conditions can only be true if the link is a point-to-point link
> between a router and host that might want to act as a router if it
> decides to.

It may be that what the jjmb draft proposes looks as a point-to-point link.

> We end up with:
>
> If ConditionA, ConditionB and ConditionC, then
>
> SolutionY (/63s)
>
> else
>
> SolutionX (DHCPv6-PD)
>
>
>
> Where as,
>
>
> If ConditionA, ConditionB and ConditionC, then
>
> SolutionX (DHCPv6-PD)
>
> else
>
> SolutionX (DHCPv6-PD)
>
>
> or just
>
>
> SolutionX (DHCPv6-PD)
>
>
> will also work for both situations.

I can agree.  I just dont know how to persuade others to implement
DHCP-PD.  Especially operators.

> The code in a smartphone to do /63s divided into /64s might be
> simpler than the code to do DHCPv6-PD. However, there is also code
> overhead in the upstream router,

There is code overhead in the upstream router only if the device
configures an address for its egress interface out of that /63.
Otherwise there is not.

Remark the jjmb draft already proposes some changes in the upstream
router in order to realize the unique-prefix/device work on WiFi.  They
dont recomment DHCP-PD.  Should one advise to rather use DHCP-PD?

> and there are also human mental, operational and troubleshooting
> overheads, because now there are two solutions to the same problems
> which have to be learned, operated, troubleshooted, and a set of
> conditions to learn to know which solution will or might be used
> when, which is also more human mental overhead.

I can agree.

> (The existence of the "sharing /64" RFC shouldn't be seen as an
> indication that multiple solutions to this sort of problem is ok - it
> has a number of limitations, and is only a work around to 3GPP
> freezing feature sets such that for certain devices it isn't possible
> to deploy DHCPv6-PD, despite the devices really just being pocket
> computers/hosts that just happen to be able to also make phone
> calls.)

I can agree.  But I think it is hard to suggest operators of networks
supporting mobile devices to implement DHCP-PD.

Alex

>
> Regards, Mark.
>
>
>> All the operators must do is not hardcode 64 prefixlengths, i.e.
>> have it as a parameter.
>>
>> Some operators moved from a 64-centric for end-user way of
>> thinking - it's a parameter.
>>
>> Alex
>>
>>>
>>>
>>>
>>>> They are useful for SLAAC in its LAN segments.  Giving it a
>>>> '64' allows it to create '65's which can not be used with
>>>> SLAAC in its LAN segments.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> -- JINMEI, Tatuya
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>
>


From nobody Fri Oct 23 05:02:48 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC21B3562 for ; Fri, 23 Oct 2015 05:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlWYr_nCeJ_P for ; Fri, 23 Oct 2015 05:02:41 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143421B355E for ; Fri, 23 Oct 2015 05:02:40 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Oct 2015 14:02:18 +0200
X-IronPort-AV: E=Sophos;i="5.20,186,1444687200"; d="scan'208";a="762927834"
Received: from he111494.emea1.cds.t-internal.com ([10.206.92.97]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 23 Oct 2015 14:02:15 +0200
Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111494.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 23 Oct 2015 14:02:14 +0200
From: 
To: 
Date: Fri, 23 Oct 2015 14:02:14 +0200
Thread-Topic: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
Thread-Index: AdEL9vuHDF6UEnYvQjaQSXX4F1UQPwA4e7BQ
Message-ID: <88CAA5385EB5404392BF93106C8C53F8A2AB8F3E6A@HE111507.emea1.cds.t-internal.com>
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <5626FD84.1050101@bogus.com> <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
In-Reply-To: <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 12:02:46 -0000

3) Use ULA space internally (also for inter-location traffic) and distribut=
e the PA space of whatever provider you are using to the individual hosts f=
or Internet access (thus, each host has at least one ULA, one LLA, and one =
GUA). This however may cause some firewall rules issues, and in the server =
environment, autoconfiguration of addresses may be disabled because of secu=
rity risks.

Holger


-----Urspr=FCngliche Nachricht-----
Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Philip Matthews
Gesendet: Mittwoch, 21. Oktober 2015 13:52
An: joel jaeggli
Cc: v6ops@ietf.org
Betreff: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices=
 - NAT

I agree that a business with 1 - 5 employees is likely to go the homenet ro=
ute.

I was thinking of the somewhat larger business of say 70 - 200 employees, p=
erhaps 2 or 4 locations, and with internal infrastructure. They have a smal=
l IT department (perhaps just 1 person), firewalls, perhaps VoIP, perhaps a=
n extranet relationships with suppliers or partners, etc.

I am not an expert in the Enterprise area, so someone else may correct me, =
but I believe that such companies have not traditionally gotten PI space. T=
oday, they would instead get PA space, use private addresses internally, an=
d use NAT to avoid the renumbering issue when changing providers or to mult=
i-home.

If such a company came to me today and asked "How do I deploy IPv6", then I=
 would be reluctant to say "Get PA space from your provider and use it inte=
rnally".  I feel this would be doing them a dis-service.=20

It seems to me that the ideas that Brian mentions might become options in t=
he future, but they are still in development and are not something that one=
 could recommend to a company today.=20

So right now, i see two options that I could realistically recommend to the=
m:
1) Push them to get PI space.  (Would they qualify?  Perhaps someone more f=
amiliar with RIR policies can comment.)
2) Use ULA space internally and deploy NPT66.

Is there a viable 3rd option that a company could deploy today?

- Philip


On 2015-10-20, at 22:50 , joel jaeggli wrote:

> On 10/19/15 2:02 PM, Philip Matthews wrote:
>> Brian:
>>=20
>> What solution would you recommend today to a small-to-medium-sized=20
>> enterprise that cannot get PI space and wants the flexibility to=20
>> easily change providers and possibly multi-home?
>=20
> PI space usage is actually about attachment costs, not about the=20
> ability or inability to obtain it. it's obtainable but not usable if=20
> you favor low attachment cost.
>=20
> Enterprises that favor low attachment costs like my home business=20
> favor provider managed address ranges, low friction interaction with=20
> cloud providers, soas for basically applications  and so on);are not=20
> going to place a great deal of value on source ip addresses, because=20
> among other things they aren't very stable; I'm sending this email=20
> from a train, my pan currently has addressing from t-mobile, when I=20
> get home that will change to comcast, the devices at home, which  can=20
> reach from here are still on comcast.  for newly initiated connections=20
> source address selection will tend to favor the network that currently=20
> works or if more than one exists favor the lower cost/faster  one=20
> however you choose to weight that .
>=20
>> If the enterprise numbers their network internally with PA space,=20
>> then they need to renumber to change providers. Though this is=20
>> definitely easier in IPv6 than IPv4, it is still not "easy".  And=20
>> what about multi-homing?
>=20
> if you want a genuinly low attachment cost network al la homenet then=20
> renumbering for the purposes of useful source selection needs to be=20
> readily feasible, and fairly transparent. For destination based=20
> multihoming DNS based GTM, health-checking, low ttls  and other=20
> features commonly provided as applications are really the rule of the=20
> day today and that doesn't seem likely to change.
>=20
>> - Philip
>>=20
>>=20
>> On 2015-10-19, at 16:03 , Brian E Carpenter wrote:
>>=20
>>>> If ULAs are the only non-Link-Local address available the hosts,=20
>>>> the enterprise will need to use translation technologies such as=20
>>>> NPT[RFC6296] or NAT66 to reach the Internet.
>>>=20
>>> I think this is still the wrong message. Here's my suggestion:
>>>=20
>>> The best approach is to use ULAs for internal communications and=20
>>> normal IPv6 addresses for external communications. Running multiple=20
>>> addresses in this way is a standard feature of IPv6. If for some=20
>>> reason an enterprise decides to use ULAs as the only non-Link-Local=20
>>> address available to its hosts, the enterprise will also need to use=20
>>> the experimental address prefix technology translation known as=20
>>> NPTv6 [RFC6296] to reach the Internet. Full address translation=20
>>> (known as NAT66) is never needed for IPv6 since there is no address=20
>>> shortage.
>>>=20
>>> Regards Brian Carpenter
>>>=20
>>> _______________________________________________ v6ops mailing list=20
>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>=20
>>=20
>> _______________________________________________ v6ops mailing list=20
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>=20
>=20

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


From nobody Fri Oct 23 05:19:46 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774231B3586 for ; Fri, 23 Oct 2015 05:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSPghKsI_-cS for ; Fri, 23 Oct 2015 05:19:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D29851B3585 for ; Fri, 23 Oct 2015 05:19:42 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZpbJo-0000CZC; Fri, 23 Oct 2015 14:19:36 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
In-reply-to: Your message of "Fri, 23 Oct 2015 11:58:13 +0200 ."  
Date: Fri, 23 Oct 2015 14:19:31 +0200
Archived-At: 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 12:19:45 -0000

In your letter dated Fri, 23 Oct 2015 11:58:13 +0200 you wrote:
>Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries
>may have 2^80 or even more addresses(*). That means that single IP
>blacklisting to prevent DoS is not going to work; not even against a
>single adversary who has 2^64 IPs. So one would expect software to
>blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
>violate some of its "detection properties".  Given recommendations
>like RFC6164 which recommend /127 for PtP links (which can be a user
>VPN link), any heuristic that will ban whole networks looks more like
>a vessel to perform another denial of service (e.g., denying some user
>access to a server), rather than a solution to the original denial of
>service. This is further reinforced by the fact that smaller than /64 networks
>are occasionally handed out by ISPs to their users.
>
>Are there any recommendations for protecting servers from the IPv6
>address proliferation? If not, are there any conventions for IPv6
>address assignment to end-users?

I think the real problem is at a different level.

A first start is to define a policy on how many individual entries you
want to have before you escalate.

For example, you can have a policy that you can have block list entries for
256 /128s in a /64 and then decide to block the /64. Have 256 /64s and
block a /48, etc. (Typically also, have abuse from 256 different /64s in a /48
and block the /48).

Using BGP dumps you can efficiently find out what netblocks belong to a single
AS. So you can find out if a collection of /48s are part of a single /32 or not.
(Taking information from BGP is way easier than trying to parse whois)

This mostly requires real world experience. Create a policy, watch what works
or doesn't work and refine it.

There are two harder to solve issues:
- An ISP may have customers and its own infrastructure in a single prefix.
  For example, for spam you may want to block all customer prefixes but then
  that can result in blocking the ISP's smarthosts as well. 
- If you were to publish the block list in DNS as a DNSBL then you may hit
  (lack of) caching issues. There is a proposal for dealing with that, no
  idea how wide spread the implementation is.


From nobody Fri Oct 23 05:57:05 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96321B36ED for ; Fri, 23 Oct 2015 05:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLhxHb6nz8Mq for ; Fri, 23 Oct 2015 05:57:01 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCF61B36EE for ; Fri, 23 Oct 2015 05:57:01 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-27-562a2e9b0895
Received: from PACDCEXHUB01.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 72.D1.04607.B9E2A265; Fri, 23 Oct 2015 08:56:59 -0400 (EDT)
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 Oct 2015 08:56:59 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 23 Oct 2015 08:56:58 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Fri, 23 Oct 2015 08:56:58 -0400
From: "Brzozowski, John" 
To: Alexandre Petrescu 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwp55AYUAgAAJeoA=
Date: Fri, 23 Oct 2015 12:56:57 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com>
In-Reply-To: <5629EE64.1060402@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsXiEq4koztbTyvMYPIaa4uTZ56wWZw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo6jvEXnCisuLy6jmMDYw7yroYOTkkBEwk mpb1MkLYYhIX7q1n62Lk4hAS2MUk8WHrb0YIZy+jxMeuF+wQzm5GiR1fTzODtAgJnATKXM8A sdkEbCRef/gJNkpEwFTix64nLF2MHBzMAqoSs//wg4SFBaIldmzpZ4MoiZGY9aKRCaRERMBK YudcJZAwC1D1h3OHwEp4Bewl5jyYxgqxtp9ZYtvTT+wgCU4BTYn2yevBTmAEuvr7qTVMIDaz gLjErSfzmSC+EZBYsuc8M4QtKvHy8T9WEFtUQE+i/dR/Noi4gcTWpftYIGw5iZ4drYwQJ2tK rN+lDzHSQeLUnA42CFtRYkr3Q3aI2wQlTs6E+FAIaOS8B9IQU8QlDh/ZwTqBUXYWkoNmIQyd hWToLCRDZyEZuoCRdRWjXEFickpybkZ+aYmBoV5yYlJOql5yfm5yYnEJiN7ECE4G8st3MN57 4XSIUYCDUYmHV1leK0yINbGsuDL3EKMEB7OSCO9pHaAQb0piZVVqUX58UWlOavEhRmkOFiVx 3s33foUKCaQnlqRmp6YWpBbBZJk4OKUaGAUT85tO/Z5o3Gs2XfHTq5mMGRlNRaw7Omdtd3wy L3fKvt/ftdZbz/bukdrm5b+UYU0+p70Aw+m7Xw6nX520wcltX8q+Quc3XQI/jzbYTL2ccay9 rCDl6cWUKZyN8u1J+5ZddHgU93yDdSvnnr21FzRcSnmmiyQucNwhLvXz7CTrOt+UrX0vpyix FGckGmoxFxUnAgD/o5wdAgMAAA==
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 12:57:03 -0000

QWxleGFuZGVyLA0KDQpXZSBoYXZlIGJhc2VkIG91ciB3b3JrIG9uIGRhdGEgdGhhdCB0ZWxscyB1
cyB3aGF0IHNvcnQgb2YgZGV2aWNlcw0KKGluY2x1ZGluZyBvcGVyYXRpbmcgc3lzdGVtcykgYXJl
IGFwcGVhcmluZyBvbiBXaS1GaSBuZXR3b3Jrcywgb3VyIFdpLUZpDQpuZXR3b3Jrcy4gIFRvIGVu
c3VyZSB3ZSBtZWV0IG91ciBjdXN0b21lcuKAmXMgZXhwZWN0YXRpb25zIHdlIHVzZSB0aGlzIGRh
dGENCmFzIGEgY29ybmVyc3RvbmUgZm9yIG91ciBkZXNpZ24gYW5kIHBsYW5uaW5nLiAgQXMgbmV3
IGRldmljZXMgYXBwZWFyIHRoZXJlDQphcmUgdHdvIGNob2ljZXMgSSBzZWUgYmFzZWQgb24gbXkg
ZXhwZXJpZW5jZToNCg0KKiBOZXcgZGV2aWNlcyAobGlrZSB0aGUgb25lcyB5b3UgYXJlIGNpdGlu
ZykgYXJlIGltcGxlbWVudGVkIHRvIGJlDQpjb21wYXRpYmxlIHdpdGggc3RhbmRhcmRzIGFuZCBo
ZW5jZSBleGlzdGluZyBkZXBsb3ltZW50cw0KKiBOZXcgZGV2aWNlcyBpbXBsZW1lbnQgYWRkaXRp
b25hbC9leHBlcmltZW50YWwgZnVuY3Rpb25hbGl0eSAobGlrZSB3aGF0DQp5b3UgZGVzY3JpYmUp
IHdoaWxlIHJlbWFpbmluZyBjb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgc3RhbmRhcmRzIGFuZA0K
ZGVwbG95bWVudHMNCg0KR2l2ZW4gdGhlIGFib3ZlLCBzdXBwb3J0IGZvciBuZXcsIGV4cGVyaW1l
bnRhbCBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlDQpwbGFubmVkIGluIGFuIGluY3JlbWVudGFsIGZh
c2hpb24gaWYgcmVxdWlyZWQuDQoNCkpvaG4NCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWls
LmNvbT4NCkRhdGU6IEZyaWRheSwgT2N0b2JlciAyMywgMjAxNSBhdCAwNDoyMw0KVG86IEpvaG4g
SmFzb24gQnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPg0KQ2M6
IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1EIEFj
dGlvbjoNCmRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4
dA0KDQo+WWVzLCB0aGFua3MuDQo+DQo+QXMgYSBuZXR3b3JrIG9wZXJhdG9yIGl0IGlzIGdvb2Qg
dG8gYWNjb21tb2RhdGUgYXMgbWFueSBkZXZpY2VzIGFzDQo+cG9zc2libGUgYW5kIHRoYXQgZ29l
cyB3YXkgYmV5b25kIHRoZSBjdXJyZW50IHNtYXJ0cGhvbmVzIGxpa2UgdGhlIG9uZXMNCj55b3Ug
Y2l0ZS4NCj4NCj5BbGV4DQo+DQo+TGUgMjIvMTAvMjAxNSAxOTowOCwgQnJ6b3pvd3NraSwgSm9o
biBhIMOpY3JpdCA6DQo+PiBXZSBjYW4gY29uc2lkZXIgdGhpcyBmb3IgZnV0dXJlIHdvcmsuDQo+
Pg0KPj4gVG8gZGF0ZSB3ZSBoYXZlIHRlc3RlZCB3aXRoIGEgd2lkZSByYW5nZSBvZiBBbmRyb2lk
LCBBcHBsZSwgYW5kIFdpbmRvd3MNCj4+IFdpLUZpIGVuYWJsZWQgZGV2aWNlcy4gIEFsbCBoYXZl
IGJlZW4gdmVyaWZpZWQgYW5kIHdvcmsgcHJvcGVybHksIGFzDQo+PnN1Y2gNCj4+IHdlIGhhdmUg
bm90IGV4Y2x1ZGVkIGFueSBkZXZpY2VzLiAgT3VyIGdvYWwgaGFzIGJlZW4gdG8gYmUgYXMgaW5j
bHVzaXZlDQo+PmFzDQo+PiBwb3NzaWJsZS4gIFdoYXQgaXMgZG9jdW1lbnRlZCBpcywgaW4gZ2Vu
ZXJhbCwgd2hhdCB3aWxsIGJlIHJvbGxlZCBvdXQuDQo+Pg0KPj4gSm9obg0KPj4gKzEtNDg0LTk2
Mi0wMDYwDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+
IEZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4N
Cj4+IERhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDE1IGF0IDEyOjE1DQo+PiBUbzogSm9o
biBKYXNvbiBCcnpvem93c2tpIDxqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20+DQo+
PiBDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRndk
OiBJLUQgQWN0aW9uOg0KPj4gZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
LWhvc3QtMDAudHh0DQo+Pg0KPj4+DQo+Pj4NCj4+PiBMZSAyMi8xMC8yMDE1IDE2OjA2LCBCcnpv
em93c2tpLCBKb2huIGEgw6ljcml0IDoNCj4+Pj4gT2xlIHJlc3BvbmRlZCB0byB0aGUgdXNlIG9m
IHRoZSAvNjMuDQo+Pj4NCj4+PiBXZWxsLg0KPj4+DQo+Pj4+IFJlZ2FyZGluZyB5b3VyIHVzZSBv
ZiB0aGlzLCBJIGFtIGN1cmlvdXMgd2hpY2ggaW1wbGVtZW50YXRpb24gYW5kIGhvdw0KPj4+PiBt
YW55DQo+Pj4+IGRldmljZXMgYXJlIG9wZXJhdGluZyB1c2luZyBhIC82Mz8NCj4+Pg0KPj4+IElm
IHRoZSBnb2FsIGlzIHRvIG1pbmltaXplIHRoZSBpbXBvcnRhbmNlIG9mIGEgc21hbGwgbnVtYmVy
IG9mIGRldmljZXMNCj4+PiB0aGVuIHRoZSBnb2FsIGlzIHJlYWNoZWQuDQo+Pj4NCj4+PiBUaGUg
aW1wbGVtZW50YXRpb24gaXMgd2l0aCBsaW51eCwgcmFkdmQgc29mdHdhcmUgYW5kIGEgUE1JUA0K
Pj4+IGltcGxlbWVudGF0aW9uLg0KPj4+DQo+Pj4gVGhlIHF1ZXN0aW9uIG9mIDYzIGlzIGxpdHRs
ZSBkZXBlbmRlbnQgb24gUE1JUC4NCj4+Pg0KPj4+IElmIHRoZSBxdWVzdGlvbiBpcyBhYm91dCB3
aGV0aGVyIGEgSG9zdCBjYW4gdXNlIFNMQUFDIHRvIHNlbGYtY29uZmlndXJlDQo+Pj4gYW4gYWRk
cmVzcyBvdXQgb2YgYSAvNjMgdGhlbiB0aGUgYW5zd2VyIGlzIHllcy4gIFRoZSBpbXBsZW1lbnRh
dGlvbg0KPj4+IGluc2VydHMgYSAwIGF0IHRoZSA2NHRoIHBvc2l0aW9uLiAgRXZlcnlib2R5IGRv
ZXMgdGhhdCwgbm9ib2R5IGluc2VydHMNCj4+PmENCj4+PiAxLg0KPj4+DQo+Pj4gQW0gSSBhbnN3
ZXJpbmc/DQo+Pj4NCj4+Pj4gRmluYWxseSwgc29tZW9uZSBmcm9tIEdvb2dsZS9BbmRyb2lkIHdp
bGwgaGF2ZSB0byBjb21tZW50IG9uIEFuZHJvaWQNCj4+Pj5hbmQNCj4+Pj4gREhDUHY2IGZvciBQ
RCBzdXBwb3J0LiAgSSBhbHNvIGJlbGlldmUgQXBwbGUgZG9lcyBub3Qgc3VwcG9ydCBQRCB5ZXQN
Cj4+Pj5vbg0KPj4+PiB0aGVpciBkZXZpY2VzIGVpdGhlci4gIExpa2UgdGhlIGRyYWZ0IHNheXMg
dGhpcyBpcyBmdXR1cmUgd29yaywgd2UNCj4+Pj53aWxsDQo+Pj4+IHNlZSB3aGVyZSB0aGlzIGdv
ZXMuDQo+Pj4NCj4+PiBJbnN0ZWFkIG9mIGZ1cnRoZXIgd29yayB3ZSBjYW4ganVzdCBtb2RpZnkg
YSBudW1iZXIgKDY0IHRvIDYzKS4NCj4+Pg0KPj4+IEFsZXgNCj4+Pg0KPj4+Pg0KPj4+PiBKb2hu
DQo+Pj4+ICsxLTQ4NC05NjItMDA2MA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBBbGV4YW5kcmUgUGV0cmVzY3UgPGFs
ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+DQo+Pj4+IERhdGU6IFRodXJzZGF5LCBPY3RvYmVy
IDIyLCAyMDE1IGF0IDA5OjI1DQo+Pj4+IFRvOiBKb2huIEphc29uIEJyem96b3dza2kgPGpvaG5f
YnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbT4NCj4+Pj4gQ2M6IHY2b3BzIDx2Nm9wc0BpZXRm
Lm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9uOg0KPj4+PiBk
cmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCj4+Pj4N
Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gTGUgMjIvMTAvMjAxNSAxNToxNSwgQnJ6b3pvd3NraSwgSm9o
biBhIMOpY3JpdCA6DQo+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBiZWxvdy4N
Cj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4NCj4+Pj4+
PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEFsZXhh
bmRyZSBQZXRyZXNjdQ0KPj4+Pj4+ICAgIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiBE
YXRlOiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNQ0KPj4+Pj4+YXQNCj4+Pj4+PiAwODo0NyBU
bzogdjZvcHMgPHY2b3BzQGlldGYub3JnPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRA0K
Pj4+Pj4+IEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv
c3QtMDAudHh0DQo+Pj4+Pj4NCj4+Pj4+Pj4gSGVsbG8sDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFzc2ln
bmluZyBhIHByZWZpeC1wZXItaG9zdCBpbiBhIFdpRmkgZGVwbG95bWVudCwgcmF0aGVyIHRoYW4g
YW4NCj4+Pj4+Pj4gaW5kaXZpZHVhbCBhZGRyZXNzZXMgd2l0aGluIGEgc2FtZSBwcmVmaXgsIGhh
cyBhbHNvIGJlZW4NCj4+Pj4+Pj4gY29uc2lkZXJlZCBpbiBQcm94eSBNb2JpbGUgSVAgZGVwbG95
bWVudHMgYW5kIGl0IHdvcmtzIG9rLiAgSXQgaGFzDQo+Pj4+Pj4+IHNvbWUgYWR2YW50YWdlcywg
YW5kIHNvbWUgaW5jb252ZW5pZW50cywgZGVwZW5kaW5nIGhvdyBpdCdzIGRvbmUuDQo+Pj4+Pj4+
DQo+Pj4+Pj4+IEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoZSBkcmFmdC4NCj4+Pj4+Pj4NCj4+
Pj4+Pj4gZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0
IHNheXM6DQo+Pj4+Pj4+PiBJZiByYWRpdXMgc2VydmVyIGRpc2NvdmVycyB0aGF0IHRoZSBVRS8g
c3Vic2NyaWJlciBpcyBhIGZyZXNoDQo+Pj4+Pj4+PiBkZXZpY2UgdHJ5aW5nIHRvIGdhaW4gYWNj
ZXNzIG9udG8gdGhlIFdpLUZpIG5ldHdvcmsgaXQgd2lsbA0KPj4+Pj4+Pj4gaWRlbnRpZnkgc29t
ZSBwYXJhbWV0ZXJzIChlLmcuICBJUHY2IC82NCBwcmVmaXgpDQo+Pj4+Pj4+IFsuLi5dDQo+Pj4+
Pj4+PiBUaGlzIFJBIGNvbnRhaW5zIGEgZmV3IGltcG9ydGFudCBwYXJhbWV0ZXJzIGZvciB0aGUg
RVUvDQo+Pj4+Pj4+PiBzdWJzY3JpYmVyIHRvIGNvbnN1bWU6ICgxKSBhIC82NCBwcmVmaXggYW5k
ICgyKSBmbGFncy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdG8g
c3Vic3RpdHV0ZSAvNjMgZm9yIC82NCB0aHJvdWdob3V0IHRoZQ0KPj4+Pj4+PiBkb2N1bWVudC4g
IEEgLzY0IHdpbGwgbm90IGFsbG93IHNtYXJ0cGhvbmVzIHRvIHRldGhlciBjbGVhbmx5Lg0KPj4+
Pj4+DQo+Pj4+Pj4gW2pqbWJdIEkgYmVsaWV2ZSBhbiBSQSB3aXRoIGEgUElPIG9mIGEgLzYzIHdp
bGwgYmUgcHJvYmxlbWF0aWMsDQo+Pj4+Pg0KPj4+Pj4gV2h5Pw0KPj4+Pj4NCj4+Pj4+PiB3ZSBo
YXZlIGFscmVhZHkgdGVzdGVkIHRoZSB1c2Ugb2YgYSAvNjQgYW5kIHdpbGwgbGlrZWx5IG1haW50
YWluDQo+Pj4+Pj4gdGhpcyBmb3Igb3VyIGRlcGxveW1lbnQgb2YgSVB2NiBmb3IgY29tbXVuaXR5
IFdpLUZpLg0KPj4+Pj4NCj4+Pj4+IFdlbGwgaXQgaXMgZ29vZCBmb3IgdGhhdCBjb21tdW5pdHku
DQo+Pj4+Pg0KPj4+Pj4gSW4gdGhpcyByZXNwZWN0LCBJIGRvbnQgdGhpbmsgd2hhdCB0aGUgY29t
bXVuaXR5IHVzZXMgc2hvdWxkIGJlIGFuDQo+Pj4+PiBleGFtcGxlIGZvciBvdGhlciBjb21tdW5p
dGllcyAoYSBCQ1ApLg0KPj4+Pj4NCj4+Pj4+IEkgdXNlIDYzIGFuZCB3b3JrcyBmaW5lLg0KPj4+
Pj4NCj4+Pj4+PiBGb3IgdGV0aGVyaW5nIG92ZXIgV2ktRmkgb3VyIGV4cGVjdGF0aW9uIGlzIHRo
YXQgREhDUHY2IFBEIHdvdWxkIGJlDQo+Pj4+Pj4gdXRpbGl6ZWQuDQo+Pj4+Pg0KPj4+Pj4gSSBo
ZWFyIEFuZHJvaWQgbm90IHN1cHBvcnRpbmcgREhDUCBhdCB0aGlzIHRpbWUsIHNvIFBEIHdvdWxk
IGJlIGENCj4+Pj4+cGFpbi4NCj4+Pj4+DQo+Pj4+PiBPbiBhbm90aGVyIGhhbmQsIGp1c3QgY2hh
bmdlIDY0IHRvIDYzIHdpbGwgbWFrZSB0ZXRoZXJpbmcgc21hcnRwaG9uZXMNCj4+Pj4+IHdvcmsg
ZmluZSB3aXRob3V0IG5lZWRpbmcgREhDUCwgbm9yIERIQ1AtUEQuDQo+Pj4+Pg0KPj4+Pj4+PiBG
b3IgYSBkaXNjdXNzaW9uIG9mIHdoeSA2NCBvbmUgY2FuIHJlZmVyIHRvIFJGQzc1MjEgIkFuYWx5
c2lzIG9mIDY0DQo+Pj4+Pj4+IGJvdW5kYXJ5Li4uIg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb3IgYSBk
aXNjdXNzaW9uIG9mIHdoeSA2MyAtIHdoZXJlIHRvIHN0YXJ0Pw0KPj4+Pj4+Pg0KPj4+Pj4+PiBk
cmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgc2F5czoN
Cj4+Pj4+Pj4+IFRoZSBXTEFOLUdXIHdpbGwgdXNlIHRoZSByZWNlaXZlZCBSYWRpdXMgaW5mb3Jt
YXRpb24gdG8gY29tcG9zZQ0KPj4+Pj4+Pj4gdGhlIHJlc3BvbnNlIHRvIHRoZSBVRS9zdWJzY3Jp
YmVyIG9yaWdpbmF0ZWQgUlMgbWVzc2FnZS4gIFRoZQ0KPj4+Pj4+Pj4gV0xBTi1HVyB3aWxsIGFu
c3dlciB1c2luZyBhIHVuaWNhc3QgUkEgKFJvdXRlciBBZHZlcnRpc2VtZW50KSB0bw0KPj4+Pj4+
Pj4gdGhlIFVFLyBzdWJzY3JpYmVyLiAgVGhpcyBSQSBjb250YWlucyBhIGZldyBpbXBvcnRhbnQg
cGFyYW1ldGVycw0KPj4+Pj4+Pj4gZm9yIHRoZSBFVS8gc3Vic2NyaWJlciB0byBjb25zdW1lOiAo
MSkgYSAvNjQgcHJlZml4IGFuZCAoMikNCj4+Pj4+Pj4+IGZsYWdzLg0KPj4+Pj4+Pg0KPj4+Pj4+
PiBTaW5jZSBhIGNhcHRpdmUgcG9ydGFsIGlzIHVzZWQsIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8g
dXNlIHRoZQ0KPj4+Pj4+PiBDYXB0aXZlIFBvcnRhbCBJUHY2IFJBIE9wdGlvbiBhcyB3ZWxsDQo+
Pj4+Pj4+IChkcmFmdC13a3VtYXJpLWRoYy1jYXBwb3J0LTE2IExDJ2VkIHRvd2FyZHMgUkZDIGVu
ZCBvZiBTZXB0ZW1iZXIpLg0KPj4+Pj4+IFtqam1iXSB3ZSB3aWxsIHRha2UgYSBsb29rIGF0IHRo
aXMgZHJhZnQgdG8gZGV0ZXJtaW5lIGFwcGxpY2FiaWxpdHkuDQo+Pj4+Pj4gU3RheSB0dW5lZC4N
Cj4+Pj4+Pj4NCj4+Pj4+Pj4gZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
LWhvc3QtMDAudHh0IHNheXM6DQo+Pj4+Pj4+PiBXaGVuIGEgbmV3IFVFIGNvbm5lY3RzIHRvIHRo
ZSBjb21tdW5pdHkgV2ktRmkgaXQgY29ubmVjdHMgdG8gdGhlDQo+Pj4+Pj4+PiBXaS0gRmkgbmV0
d29yayBieSBhdHRhY2hpbmcgdG8gdGhlIHJlbGV2YW50ICdvcGVuJyBTU0lEDQo+Pj4+Pj4+PiBh
ZHZlcnRpc2VkIGZvciB1c2UgYXMgcGFydCBvZiB0aGUgY29tbXVuaXR5IFdpLUZpIG9mZmVyaW5n
Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBCdXQgc29tZSBjb21tdW5pdHkgbmV0d29ya3MgdXNlIGEgJ2hp
ZGRlbicgU1NJRCwga25vd24gb25seSBieQ0KPj4+Pj4+PiBtZW1iZXJzIG9mIHRoYXQgY29tbXVu
aXR5Lg0KPj4+Pj4+IFtqam1iXSBoaWRkZW4gc2hvdWxkIHdvcmsgYXMgd2VsbCwgcHJvdmlkaW5n
IHRoZSBlbmQgdXNlciBrbm93cyB0aGUNCj4+Pj4+PiBuYW1lIG9mIHRoZSBTU0lELiAgV2Ugd2ls
bCBsb29rIHRvIHNlZSBpZiB0aGVyZSBhcmUgY2xhcmlmaWNhdGlvbnMNCj4+Pj4+PiB3ZSBjYW4g
bWFrZSB0byBhZGRyZXNzIHRoaXMuDQo+Pj4+Pg0KPj4+Pj4gT2suDQo+Pj4+Pg0KPj4+Pj4gQWxl
eA0KPj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gWW91cnMsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsZXgN
Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gTGUgMjAvMTAvMjAxNSAyMDozNSwgRnJlZCBCYWtl
ciAoZnJlZCkgYSDDqWNyaXQgOg0KPj4+Pj4+Pj4gUG9zdGVkIHllc3RlcmRheS4gWW91ciBjb21t
ZW50IHNvbGljaXRlZC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmVnaW4gZm9yd2FyZGVkIG1lc3Nh
Z2U6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg
U3ViamVjdDogSS1EIEFjdGlvbjoNCj4+Pj4+Pj4+PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1p
cHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgRGF0ZToNCj4+Pj4+Pj4+PiBPY3RvYmVyIDE5LCAy
MDE1IGF0IDEyOjUwOjAxIFBNIFBEVCBUbzoNCj4+Pj4+Pj4+PiA8aS1kLWFubm91bmNlQGlldGYu
b3JnPiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+Pj4NCj4+Pj4+
Pj4+Pg0KPj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo
ZSBvbi1saW5lDQo+Pj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+Pj4+
Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaXRsZSAgICAgICAgICAgOiBVbmlxdWUgSVB2NiBQ
cmVmaXggUGVyIEhvc3QgQXV0aG9ycyA6IEpvaG4NCj4+Pj4+Pj4+PiBKYXNvbiBCcnpvem93c2tp
IEd1bnRlciBWYW4gRGUgVmVsZGUgRmlsZW5hbWUgICAgICAgIDoNCj4+Pj4+Pj4+PiBkcmFmdC1q
am1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQgUGFnZXMgOiAxNA0K
Pj4+Pj4+Pj4+IERhdGUgOiAyMDE1LTEwLTE5DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBYnN0cmFj
dDogSW4gc29tZSBJUHY2IGVudmlyb25tZW50cyB0aGUgbmVlZCBoYXMgYXJpc2VuIGZvcg0KPj4+
Pj4+Pj4+IGhvc3RzIHRvIGJlIGFibGUgdG8gdXRpbGlzZSBhIHVuaXF1ZSBJUHY2IHByZWZpeCBl
dmVuIHRob3VnaA0KPj4+Pj4+Pj4+IHRoZSBsaW5rIG9yIG1lZGlhIG1heSBiZSBzaGFyZWQuICBU
eXBpY2FsbHkgaG9zdHMNCj4+Pj4+Pj4+PiAoc3Vic2NyaWJlcnMpIG9uIGEgc2hhcmVkIG5ldHdv
cmssIGxpa2UgV2ktIEZpIG9yIEV0aGVybmV0LA0KPj4+Pj4+Pj4+IHdpbGwgYWNxdWlyZSB1bmlx
dWUgSVB2NiBhZGRyZXNzZXMgZnJvbSBhIGNvbW1vbiBJUHY2IHByZWZpeA0KPj4+Pj4+Pj4+IHRo
YXQgaXMgYWxsb2NhdGVkIG9yIGFzc2lnbmVkIGZvciB1c2Ugb24gYSBzcGVjaWZpYyBsaW5rLg0K
Pj4+Pj4+Pj4+IEJlbmVmaXRzIG9mIGEgdW5pcXVlIElQdjYgcHJlZml4IGNvbXBhcmVkIHRvIGEg
dW5pcXVlIElQdjYNCj4+Pj4+Pj4+PiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIg
YXJlIGdvaW5nIGZyb20gZW5oYW5jZWQNCj4+Pj4+Pj4+PiBzdWJzY3JpYmVyIG1hbmFnZW1lbnQg
dG8gaW1wcm92ZWQgaXNvbGF0aW9uIGJldHdlZW4NCj4+Pj4+Pj4+PiBzdWJzY3JpYmVycy4NCj4+
Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEluIG1vc3QgZGVwbG95bWVudHMgdG9kYXkgSVB2NiBhZGRyZXNz
IGFzc2lnbm1lbnQgZnJvbSBhIHNpbmdsZQ0KPj4+Pj4+Pj4+IElQdjYgcHJlZml4IG9uIGEgc2hh
cmVkIG5ldHdvcmsgaXMgZG9uZSBieSBlaXRoZXIgdXNpbmcgSVB2Ng0KPj4+Pj4+Pj4+IHN0YXRl
bGVzcyBhZGRyZXNzIGF1dG8tY29uZmlndXJhdGlvbiAoU0xBQUMpIGFuZC9vciBzdGF0ZWZ1bA0K
Pj4+Pj4+Pj4+IERIQ1B2Ni4gIFdoaWxlIHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRl
cyBhcyBkZXNpZ25lZA0KPj4+Pj4+Pj4+IHRoZXJlIGFyZSBzb21lIGxhcmdlIHNjYWxlIGVudmly
b25tZW50cyB3aGVyZSB0aGlzIGNvbmNlcHQNCj4+Pj4+Pj4+PiBpbnRyb2R1Y2VzIHNpZ25pZmlj
YW50IHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywNCj4+Pj4+Pj4+PiBz
cGVjaWZpY2FsbHkgcmVsYXRlZCB0byBJUHY2IHJvdXRlciBhbmQgbmVpZ2hib3IgZGlzY292ZXJ5
Lg0KPj4+Pj4+Pj4+IFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2ggdXRpbGlzaW5n
IGV4aXN0aW5nIElQdjYNCj4+Pj4+Pj4+PiBwcm90b2NvbHMgdG8gYWxsb3cgaG9zdHMgdG8gYmUg
YXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXgNCj4+Pj4+Pj4+PiAoaW5zdGVhZCBvZiBhIHVu
aXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZCBJUHY2IHByZWZpeCkuDQo+Pj4+Pj4+Pj4N
Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv
ciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+
Pj4+IA0KPj4+Pj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtampt
Yi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmDQo+Pj4+Pj4+Pj5peA0KPj4+Pj4+Pj4+IC1wDQo+Pj4+
Pj4+Pj4gZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+IC1ob3N0Lw0K
Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZXJl
J3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+DQo+Pj4+
Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlDQo+Pj4+Pj4+
Pj5yLQ0KPj4+Pj4+Pj4+IGhvDQo+Pj4+Pj4+Pj4gc3QNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+
Pj4+Pj4+Pj4NCj4+Pj4+IC0wMA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4+Pj4gc3VibWlzc2lvbg0K
Pj4+Pj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi
bGUgYXQNCj4+Pj4+Pj4+PiB0b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IElu
dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+
Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+DQo+
Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g
SS1ELUFubm91bmNlDQo+Pj4+Pj4+Pj4gbWFpbGluZyBsaXN0IEktRC1Bbm5vdW5jZUBpZXRmLm9y
Zw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu
bm91bmNlDQo+Pj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cu
aWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3INCj4+Pj4+Pj4+PiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcv
aWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZv
cHMgbWFpbGluZw0KPj4+Pj4+Pj4gbGlzdCB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWls
aW5nIGxpc3QNCj4+Pj4+Pj4gICAgdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+
Pj4NCj4+Pg0KPj4+DQo+Pg0KPg0KPg0KDQo=


From nobody Fri Oct 23 06:18:11 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C551D1A0097 for ; Fri, 23 Oct 2015 06:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddd0JLh5eyyv for ; Fri, 23 Oct 2015 06:18:07 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2F21A008E for ; Fri, 23 Oct 2015 06:18:07 -0700 (PDT)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.306.13; Fri, 23 Oct 2015 13:18:04 +0000
Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 13:18:04 +0000
From: "Metzler, Dan J" 
To: Nikos Mavrogiannopoulos , "v6ops@ietf.org" 
Thread-Topic: [v6ops] preventing denial of service in IPv6
Thread-Index: AQHRDXllPkT3U56Yb0q2IqTxb+Em45542yXQ
Date: Fri, 23 Oct 2015 13:18:04 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dan-metzler@uiowa.edu; 
x-originating-ip: [2620:0:e50:1001:3862:2874:3350:1c09]
x-microsoft-exchange-diagnostics: 1; CO2PR04MB587; 5:LaSBuaNyTcr9zSahfmOQGIcelXo9ikfc8Vfe9/MahSU+XOF29mKXo4SE2z9vltsDWwToTY1CPVmOYOITb4ye6Rc+UAQVzJ68CXwWSRlPNWagtCw0TMg1jZeyZvBV80udb5PVnfdAzXL+T4vp1EXFSA==; 24:d4/UXgivREBm6WNgTtj5fAwP+mol0nprj0jiq8421AD2vTPbBlVPHUDxAUVTuBKIxRg8YiMkrZ6w3/1C4I+/soGZOJWJ7+DJgcfm2fT7P/U=; 20:ljvKuwsgvzZQLxulm66ZmXNs+LfRJOTt2GvfRXCJ3jRg8dWL46gQc4tvuxhqckY2ffl9zh6V3WgdIjAgiW3tRQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587; 
x-forefront-prvs: 0738AF4208
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51444003)(13464003)(377454003)(5003600100002)(19580395003)(90282001)(189998001)(19580405001)(5001960100002)(40100003)(107886002)(99286002)(122556002)(86362001)(106116001)(76176999)(54356999)(105586002)(106356001)(33656002)(101416001)(50986999)(75432002)(87936001)(88552001)(97736004)(5002640100001)(102836002)(5001770100001)(89122001)(81156007)(5004730100002)(11100500001)(15975445007)(2950100001)(92566002)(2900100001)(5008740100001)(76576001)(5007970100001)(2501003)(10400500002)(77096005)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: uiowa.edu does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 13:18:04.4938 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587
Archived-At: 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 13:18:09 -0000

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, October 23, 2015 4:58 AM
> To: v6ops@ietf.org
> Subject: [v6ops] preventing denial of service in IPv6
>=20
> [this was originally sent to saag list, and I'm resending it here as this=
 list is
> focused on IPv6]
>=20
> I've been looking on ways to prevent denial of service on a server
> application, and I stumbled on IPv6. By denial of service, I mean exhaust=
ion
> of resources, being memory or CPU.
>=20
> Unlike IPv4, in IPv6 a user may typically have 2^64, and more able
> adversaries may have 2^80 or even more addresses(*).=20
[DJM] I'm not sure I understand that statement.  A router might have 64 bit=
s of address space.
A typical user would have 1 - 3 addresses per network interface, with 1 typ=
ically used for outbound traffic at any given point in time.

> That means that
> single IP blacklisting to prevent DoS is not going to work; not even agai=
nst a
> single adversary who has 2^64 IPs.=20
[DJM] I would disagree with that assumption.  On the surface the problem se=
ems little different from the same situation in IPv4.

> So one would expect software to blacklist
> whole ranges of networks, e.g., a /64 or /48 once few IPs violate some of=
 its
> "detection properties". =20

[DJM] I would think one would expect software to block a single IP address =
for IPv6 in the same scenarios where that would happen in IPv4.
Granted IPv6 makes it a bit easier to repeatedly change addresses, purely f=
rom an availability standpoint, in the same way that it makes it a bit hard=
er to scan addresses.
I would expect blocking a /64 to be the equivalent of blocking a subnet in =
IPv4, because it is.


>Given recommendations like RFC6164 which
> recommend /127 for PtP links (which can be a user VPN link), any heuristi=
c
> that will ban whole networks looks more like a vessel to perform another
> denial of service (e.g., denying some user access to a server), rather th=
an a
> solution to the original denial of service.=20
[DJM] Absolute agreement here, as is the case with IPv4.
A better approach would be to intelligently and dynamically block offending=
 individual addresses, or sets of addresses, based off of more information =
than a simple assumption that if there is one offender on a subnet, then th=
ey all must be offenders.=20
Of course one might want to block a whole subnet once some sort of critical=
 threshold was reached of a certain number of offending IPs on that subnet.

> This is further reinforced by the fact
> that smaller than /64 networks are occasionally handed out by ISPs to the=
ir
> users.
>=20
> Are there any recommendations for protecting servers from the IPv6 addres=
s
> proliferation?=20
[DJM] Address proliferation doesn't seem like a vulnerability to protect ag=
ainst.
I think that would be deviating from the problem; the DOS attack.
DOS is largely a game of resources; attempting to allocate a large enough p=
ool of resources, that participate in a DOS attack, so as to exceed the cap=
acity of the finite resources dedicated to handling a load.  The fact that =
the resources instigating the attack has a larger pool of addresses, to use=
, doesn't change the amount of resources participating in the attack, or th=
e number of addresses in use at a given point in time.
Also, the likelihood that a DOS attack would be  sourced entirely from a si=
ngle subnet seems more and more of an edge case as time goes on.  (If it we=
re only that easy.)

> If not, are there any conventions for IPv6 address assignment
> to end-users?
[DJM] Outside of the typical DHCPv6 and SLAAC?
Is this an ISP scenario?

>=20
> regards,
> Nikos
>=20
> [0]. rfc6177 is supposed to describe the best current practice, but it mo=
stly
> focuses on what isn't the current best practice (i.e., /48 is not recomme=
nded
> any more)
[DJM] This definitely sounds more like an ISP scenario, if you're referenci=
ng 6177, but again, regarding DOS attacks, not sure the proliferation of ad=
dresses matters to the person trying to defend against an active DOS attack=
.

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


From nobody Fri Oct 23 07:26:15 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF961A1A75 for ; Fri, 23 Oct 2015 07:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.022
X-Spam-Level: 
X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_SUMOF=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLAn5UPK7Tl7 for ; Fri, 23 Oct 2015 07:26:06 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096911A1A73 for ; Fri, 23 Oct 2015 07:26:06 -0700 (PDT)
Received: by igbni9 with SMTP id ni9so35613937igb.1 for ; Fri, 23 Oct 2015 07:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J+0FUSFgwVILip3sFPhEKWZV0rpzv1e8I/EXqtUpeP4=; b=iZRehgs/bVhpg4rBjK1MkCcBJG5UHYK6waK3UFMGqVpk9/++CMPNHtN1BHFpmlX+My Fr7+tH82ug6UBBq55X/g/ZvTDnSQvrG5I5EcffKuyYLAsbKGA6NBbIUpoGdWEU00YQPD BuWjnDreQXbOYtJp4SqJXpj3gGGTq/68aj00tQhdbAseqVcz8bNOBN6Fi2NQys5sIBVB m1YbRfrL/sauhQYfNE35N3fuOUrsHTXNPzfP4s+4D03y6dNsRY3+Vwr3+dy0YZVAvN4H 6DBZ0HYxRDUSCRcOxnVK5Af8kswEiPfXQMGqBW1V3Xi+CdUlgy0WLSueXhbdCD+o+rvr W3BA==
MIME-Version: 1.0
X-Received: by 10.50.41.10 with SMTP id b10mr4310632igl.41.1445610365432; Fri, 23 Oct 2015 07:26:05 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Fri, 23 Oct 2015 07:26:05 -0700 (PDT)
In-Reply-To: <5629EEBE.7010908@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <5629EEBE.7010908@gmail.com>
Date: Fri, 23 Oct 2015 07:26:05 -0700
X-Google-Sender-Auth: _uxl1kNjbj6SqFPzYj397hVQV5k
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 14:26:07 -0000

At Fri, 23 Oct 2015 10:24:30 +0200,
Alexandre Petrescu  wrote:

> >> I believe /63 prefixlength is legal yes.
> >>
> >> SLAAC is done for any  length, the doc does not say 64.
> >
> > no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
> > length is 64 on a link whose IID is supposed to be 64 bits violates
> > Section 5.5.3 d of RFC 4862:
> >
> > If the sum of the prefix length and interface identifier length does
> > not equal 128 bits, the Prefix Information option MUST be ignored.
>
> That is what the SLAAC RFC says, yes.

I don't understand what you were trying to say below, but in any case,
my point was (correcting a typo):

  If an implementation performs SLAAC per RFC4862 Section 5.5.3 for a
  prefix in an RA PIO whose A bit is 1 and length is 63 on a link
  whose IID is supposed to be 64 bits, the implementation is "illegal"
  (meaning violating RFC4862).

I believe others used legal/illegal for the same meaning.  Perhaps you
wanted to say it's not explicitly prohibited to use an implementation
to use the /63 prefix for something other than SLAAC by "legal".  If
so, it would have been better to not use the word "legal" but explain
this is some new protocol extension you wish to have.

> But more precisely, that is a requirement on the sum, not on the value
> of _any_ of its parts.
>
> Given a 63 prefix len to that sum, the IID length must be 65.  And that
> IID len 65 is wrong compared to RFC2464/4191 requiring the IID len to be 64.
>
> Can we conclude that because of that wrongness, the SLAAC RFC is wrong
> with respect to RFC2464-RFC4191?  I dont think so.  Again because the
> requirement in SLAAC RFC is on the _sum_ not on the value of the parts.
>
> So, if we can't think that the SLAAC RFC is wrong with respect to
> RFC4191-2464 for the IID length being 65, then we can think that is
> wrong with respect to a prefix length being 63.  It's just the sum that
> must be respected.

--
JINMEI, Tatuya


From nobody Fri Oct 23 08:00:52 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F581A1BF6 for ; Fri, 23 Oct 2015 08:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrEVrJh1BxtK for ; Fri, 23 Oct 2015 08:00:48 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7821A1A0117 for ; Fri, 23 Oct 2015 08:00:47 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9NF0WaU021209; Fri, 23 Oct 2015 17:00:32 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1C5502071AA; Fri, 23 Oct 2015 17:06:15 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0EEF6207188; Fri, 23 Oct 2015 17:06:15 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9NF0VpQ002616; Fri, 23 Oct 2015 17:00:31 +0200
To: "Brzozowski, John" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <562A4B8F.3040104@gmail.com>
Date: Fri, 23 Oct 2015 17:00:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 15:00:51 -0000

John,

It is an excellent business case, but may not be the best common 
practice.  There are many wifi networks out there on which routers 
connect, as opposed to the cited devices.

Currently it seems the best recommendation to give a prefix per host is 
DHCP-PD.  I could agree with it as best common practice.

Alex

Le 23/10/2015 14:56, Brzozowski, John a écrit :
> Alexander,
>
> We have based our work on data that tells us what sort of devices
> (including operating systems) are appearing on Wi-Fi networks, our Wi-Fi
> networks.  To ensure we meet our customer’s expectations we use this data
> as a cornerstone for our design and planning.  As new devices appear there
> are two choices I see based on my experience:
>
> * New devices (like the ones you are citing) are implemented to be
> compatible with standards and hence existing deployments
> * New devices implement additional/experimental functionality (like what
> you describe) while remaining compatible with existing standards and
> deployments
>
> Given the above, support for new, experimental functionality could be
> planned in an incremental fashion if required.
>
> John
>
>
>
>
> -----Original Message-----
> From: Alexandre Petrescu 
> Date: Friday, October 23, 2015 at 04:23
> To: John Jason Brzozowski 
> Cc: v6ops 
> Subject: Re: [v6ops] Fwd: I-D Action:
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>
>> Yes, thanks.
>>
>> As a network operator it is good to accommodate as many devices as
>> possible and that goes way beyond the current smartphones like the ones
>> you cite.
>>
>> Alex
>>
>> Le 22/10/2015 19:08, Brzozowski, John a écrit :
>>> We can consider this for future work.
>>>
>>> To date we have tested with a wide range of Android, Apple, and Windows
>>> Wi-Fi enabled devices.  All have been verified and work properly, as
>>> such
>>> we have not excluded any devices.  Our goal has been to be as inclusive
>>> as
>>> possible.  What is documented is, in general, what will be rolled out.
>>>
>>> John
>>> +1-484-962-0060
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Alexandre Petrescu 
>>> Date: Thursday, October 22, 2015 at 12:15
>>> To: John Jason Brzozowski 
>>> Cc: v6ops 
>>> Subject: Re: [v6ops] Fwd: I-D Action:
>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>
>>>>
>>>>
>>>> Le 22/10/2015 16:06, Brzozowski, John a écrit :
>>>>> Ole responded to the use of the /63.
>>>>
>>>> Well.
>>>>
>>>>> Regarding your use of this, I am curious which implementation and how
>>>>> many
>>>>> devices are operating using a /63?
>>>>
>>>> If the goal is to minimize the importance of a small number of devices
>>>> then the goal is reached.
>>>>
>>>> The implementation is with linux, radvd software and a PMIP
>>>> implementation.
>>>>
>>>> The question of 63 is little dependent on PMIP.
>>>>
>>>> If the question is about whether a Host can use SLAAC to self-configure
>>>> an address out of a /63 then the answer is yes.  The implementation
>>>> inserts a 0 at the 64th position.  Everybody does that, nobody inserts
>>>> a
>>>> 1.
>>>>
>>>> Am I answering?
>>>>
>>>>> Finally, someone from Google/Android will have to comment on Android
>>>>> and
>>>>> DHCPv6 for PD support.  I also believe Apple does not support PD yet
>>>>> on
>>>>> their devices either.  Like the draft says this is future work, we
>>>>> will
>>>>> see where this goes.
>>>>
>>>> Instead of further work we can just modify a number (64 to 63).
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> John
>>>>> +1-484-962-0060
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alexandre Petrescu 
>>>>> Date: Thursday, October 22, 2015 at 09:25
>>>>> To: John Jason Brzozowski 
>>>>> Cc: v6ops 
>>>>> Subject: Re: [v6ops] Fwd: I-D Action:
>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>>>
>>>>>>
>>>>>>
>>>>>> Le 22/10/2015 15:15, Brzozowski, John a écrit :
>>>>>>> Thanks for the comments, see below.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>
>>>>>>> From: v6ops  on behalf of Alexandre Petrescu
>>>>>>>      Date: Thursday, October 22, 2015
>>>>>>> at
>>>>>>> 08:47 To: v6ops  Subject: Re: [v6ops] Fwd: I-D
>>>>>>> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Assigning a prefix-per-host in a WiFi deployment, rather than an
>>>>>>>> individual addresses within a same prefix, has also been
>>>>>>>> considered in Proxy Mobile IP deployments and it works ok.  It has
>>>>>>>> some advantages, and some inconvenients, depending how it's done.
>>>>>>>>
>>>>>>>> I have some comments on the draft.
>>>>>>>>
>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>>> If radius server discovers that the UE/ subscriber is a fresh
>>>>>>>>> device trying to gain access onto the Wi-Fi network it will
>>>>>>>>> identify some parameters (e.g.  IPv6 /64 prefix)
>>>>>>>> [...]
>>>>>>>>> This RA contains a few important parameters for the EU/
>>>>>>>>> subscriber to consume: (1) a /64 prefix and (2) flags.
>>>>>>>>
>>>>>>>> I would like to suggest to substitute /63 for /64 throughout the
>>>>>>>> document.  A /64 will not allow smartphones to tether cleanly.
>>>>>>>
>>>>>>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>>> we have already tested the use of a /64 and will likely maintain
>>>>>>> this for our deployment of IPv6 for community Wi-Fi.
>>>>>>
>>>>>> Well it is good for that community.
>>>>>>
>>>>>> In this respect, I dont think what the community uses should be an
>>>>>> example for other communities (a BCP).
>>>>>>
>>>>>> I use 63 and works fine.
>>>>>>
>>>>>>> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
>>>>>>> utilized.
>>>>>>
>>>>>> I hear Android not supporting DHCP at this time, so PD would be a
>>>>>> pain.
>>>>>>
>>>>>> On another hand, just change 64 to 63 will make tethering smartphones
>>>>>> work fine without needing DHCP, nor DHCP-PD.
>>>>>>
>>>>>>>> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
>>>>>>>> boundary..."
>>>>>>>>
>>>>>>>> For a discussion of why 63 - where to start?
>>>>>>>>
>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>>> The WLAN-GW will use the received Radius information to compose
>>>>>>>>> the response to the UE/subscriber originated RS message.  The
>>>>>>>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>>>>>>>> the UE/ subscriber.  This RA contains a few important parameters
>>>>>>>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>>>>>>>> flags.
>>>>>>>>
>>>>>>>> Since a captive portal is used, it would make sense to use the
>>>>>>>> Captive Portal IPv6 RA Option as well
>>>>>>>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
>>>>>>> [jjmb] we will take a look at this draft to determine applicability.
>>>>>>> Stay tuned.
>>>>>>>>
>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>>> When a new UE connects to the community Wi-Fi it connects to the
>>>>>>>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>>>>>>>> advertised for use as part of the community Wi-Fi offering.
>>>>>>>>
>>>>>>>> But some community networks use a 'hidden' SSID, known only by
>>>>>>>> members of that community.
>>>>>>> [jjmb] hidden should work as well, providing the end user knows the
>>>>>>> name of the SSID.  We will look to see if there are clarifications
>>>>>>> we can make to address this.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>>
>>>>>>>> Yours,
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>>>>>>>>> Posted yesterday. Your comment solicited.
>>>>>>>>>
>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>
>>>>>>>>>> From: internet-drafts@ietf.org Subject: I-D Action:
>>>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>>>>>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>>>>>>>>  Reply-To: internet-drafts@ietf.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>>>> Internet-Drafts directories.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>>>>>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>>>>>>>> Date : 2015-10-19
>>>>>>>>>>
>>>>>>>>>> Abstract: In some IPv6 environments the need has arisen for
>>>>>>>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>>>>>>>> the link or media may be shared.  Typically hosts
>>>>>>>>>> (subscribers) on a shared network, like Wi- Fi or Ethernet,
>>>>>>>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>>>>>>>> that is allocated or assigned for use on a specific link.
>>>>>>>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>>>>>>>> address from the service provider are going from enhanced
>>>>>>>>>> subscriber management to improved isolation between
>>>>>>>>>> subscribers.
>>>>>>>>>>
>>>>>>>>>> In most deployments today IPv6 address assignment from a single
>>>>>>>>>> IPv6 prefix on a shared network is done by either using IPv6
>>>>>>>>>> stateless address auto-configuration (SLAAC) and/or stateful
>>>>>>>>>> DHCPv6.  While this is still viable and operates as designed
>>>>>>>>>> there are some large scale environments where this concept
>>>>>>>>>> introduces significant performance challenges and implications,
>>>>>>>>>> specifically related to IPv6 router and neighbor discovery.
>>>>>>>>>> This document outlines an approach utilising existing IPv6
>>>>>>>>>> protocols to allow hosts to be assigned a unique IPv6 prefix
>>>>>>>>>> (instead of a unique IPv6 address from a shared IPv6 prefix).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-pref
>>>>>>>>>> ix
>>>>>>>>>> -p
>>>>>>>>>> er
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> -host/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> There's also a htmlized version available at:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-pe
>>>>>>>>>> r-
>>>>>>>>>> ho
>>>>>>>>>> st
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> -00
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission
>>>>>>>>>> until the htmlized version and diff are available at
>>>>>>>>>> tools.ietf.org.
>>>>>>>>>>
>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>>>
>>>>>>>>>> _______________________________________________ I-D-Announce
>>>>>>>>>> mailing list I-D-Announce@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>>>>>>>     ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________ v6ops mailing
>>>>>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ v6ops mailing list
>>>>>>>>     v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From nobody Fri Oct 23 08:07:47 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258E51A0275 for ; Fri, 23 Oct 2015 08:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level: 
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH9Z9S6lAXNJ for ; Fri, 23 Oct 2015 08:07:44 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF8C1A016B for ; Fri, 23 Oct 2015 08:07:44 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so52395267lfb.2 for ; Fri, 23 Oct 2015 08:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IwqMjL+t/l8cWa1eiXF/qdoJubBTCSRCB5TVzG6mWXc=; b=YHs4BtDBtlfcjHll17IoX9LaXH81qS4QpFCeyR54BP3ymUJnbv84Tsyl2lICFiqzTw zeAcXTqtfnGJKRQF3rABn7WFtFrgAmfMlcrnQ6QbVGkVa6xcc1ExCZ+xz5kRrsvEEJIG PiWIBVefUzh8HgLUhjKCKj7q238q7R1o4P91r0k8YjKNGRRdnAzqXaN083VzS4YNs9yQ NeFy4R1PIQGBnmjj+13Xw/bPTq6U4LQ1FF4JW9Oe0QVGaf8J2b1H7zXbRwRkjbohVpfl pW3GClqYh2YmMV3O5wnyQS2rN/pCFH9rdcKWcjFVhFdnODsLZvYMAbGWEGvsypGsR8qg GU9Q==
MIME-Version: 1.0
X-Received: by 10.112.198.69 with SMTP id ja5mr10334334lbc.106.1445612862172;  Fri, 23 Oct 2015 08:07:42 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.30.108 with HTTP; Fri, 23 Oct 2015 08:07:42 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 23 Oct 2015 17:07:42 +0200
X-Google-Sender-Auth: vjaBQFo6EpoNS8_soTSlaGis4DE
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: Philip Homburg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 15:07:46 -0000

On Fri, Oct 23, 2015 at 2:19 PM, Philip Homburg
 wrote:
> In your letter dated Fri, 23 Oct 2015 11:58:13 +0200 you wrote:
>>Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries
>>may have 2^80 or even more addresses(*). That means that single IP
>>blacklisting to prevent DoS is not going to work; not even against a
>>single adversary who has 2^64 IPs. So one would expect software to
>>blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
>>violate some of its "detection properties".  Given recommendations
>>like RFC6164 which recommend /127 for PtP links (which can be a user
>>VPN link), any heuristic that will ban whole networks looks more like
>>a vessel to perform another denial of service (e.g., denying some user
>>access to a server), rather than a solution to the original denial of
>>service. This is further reinforced by the fact that smaller than /64 networks
>>are occasionally handed out by ISPs to their users.
>>Are there any recommendations for protecting servers from the IPv6
>>address proliferation? If not, are there any conventions for IPv6
>>address assignment to end-users?
> I think the real problem is at a different level.
> A first start is to define a policy on how many individual entries you
> want to have before you escalate.
> For example, you can have a policy that you can have block list entries for
> 256 /128s in a /64 and then decide to block the /64. Have 256 /64s and
> block a /48, etc. (Typically also, have abuse from 256 different /64s in a /48
> and block the /48).

My point is exactly this disproportion. In this suggestion you add a
heuristic of 256 misbehaving addresses to block 2^64 addresses in
total (for a /64), and 256*256=2^16 mibehaving addresses to block 2^80
addresses. This will affect someone who has divided a /64 into 2^32
/96 subnets and shared it to different users, he will have his subnet
completely blocked even if only 256 out of 2^32 is misbehaving. We may
adjust these numbers as we like, but the disproportion will remain if
we want to keep reasonable memory consumption for the server.

I've been experimenting and attempting to account for smaller nets
such as /112 and /96, on the server side for DoS protection, but it
quickly becomes unmanageable due to memory needed to store these
tables, if you are under attack from an adversary with access to a /48
for example. So in the end some simple heuristic should be used as you
describe above, but it should be, if possible, documented, so it
becomes a common heuristic which is taken into account in address
allocation and by ISPs.

> Using BGP dumps you can efficiently find out what netblocks belong to a single
> AS. So you can find out if a collection of /48s are part of a single /32 or not.
> (Taking information from BGP is way easier than trying to parse whois)

We currently don't need that information for basic IPv4 DoS
protection, it would be a petty if we have to require that for IPv6.

> This mostly requires real world experience. Create a policy, watch what works
> or doesn't work and refine it.

That's what I'm afraid of. We end up with X vendors having X IP
blocking policies all different, which cause issues to different ISPs.

regards,
Nikos


From nobody Fri Oct 23 08:26:36 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E081A1F04 for ; Fri, 23 Oct 2015 08:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wYXa5Re4OcW for ; Fri, 23 Oct 2015 08:26:33 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7513C1A21B4 for ; Fri, 23 Oct 2015 08:26:33 -0700 (PDT)
Received: by lffv3 with SMTP id v3so87487780lff.0 for ; Fri, 23 Oct 2015 08:26:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=549n0fuYCCpT0Gqc9CtympmLD/5c9AVQtP5TJdEDoqA=; b=daOlEuWP4qCB+MQAAr7/WtPhZggJ1ADbKOr9/Kv0ZiFOPCNPcFJFmK5QAj7uqxFbZU haUlh7xNwQPJMManIwhy+1zS2t916QY1kzII+TAIUiSUXTIqoGENoN/eI1ZIwL3fwppa hVD6Vt8R7uO0a9QiVraAAcOD+aL0mpDW6TzEia0Ot1x8TgSUL5zsCBOU2hJyQaLTv3fq wNGAkzkly9MvYUUPdW8YkUFA/cvPZc2Shll4rL7wQ7v0M8ecH5KnTYRHsrSV+srHU/RT 4veWhg0twxS4wLKjl4eqkxgwRbOzL9fX6hubDQLR+Eb+r0on9IFxNdysyK8l/iJ4CVZg +M1g==
MIME-Version: 1.0
X-Received: by 10.112.146.104 with SMTP id tb8mr11619672lbb.35.1445613991594;  Fri, 23 Oct 2015 08:26:31 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.30.108 with HTTP; Fri, 23 Oct 2015 08:26:31 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 23 Oct 2015 17:26:31 +0200
X-Google-Sender-Auth: cuDtD_sEKtUfvHvj807YDqyah3A
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: "Metzler, Dan J" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 15:26:35 -0000

On Fri, Oct 23, 2015 at 3:18 PM, Metzler, Dan J  wro=
te:

>> So one would expect software to blacklist
>> whole ranges of networks, e.g., a /64 or /48 once few IPs violate some o=
f its
>> "detection properties".
> [DJM] I would think one would expect software to block a single IP addres=
s for IPv6 in the same scenarios where that would happen in IPv4.
> Granted IPv6 makes it a bit easier to repeatedly change addresses, purely=
 from an availability standpoint, in the same way that it makes it a bit ha=
rder to scan addresses.
> I would expect blocking a /64 to be the equivalent of blocking a subnet i=
n IPv4, because it is.

Then a single user can exhaust a server's resources by simply
attacking the server with all his available addresses.

>>Given recommendations like RFC6164 which
>> recommend /127 for PtP links (which can be a user VPN link), any heurist=
ic
>> that will ban whole networks looks more like a vessel to perform another
>> denial of service (e.g., denying some user access to a server), rather t=
han a
>> solution to the original denial of service.
> [DJM] Absolute agreement here, as is the case with IPv4.
> A better approach would be to intelligently and dynamically block offendi=
ng individual addresses, or sets of addresses, based off of more informatio=
n than a simple assumption that if there is one offender on a subnet, then =
they all must be offenders.
> Of course one might want to block a whole subnet once some sort of critic=
al threshold was reached of a certain number of offending IPs on that subne=
t.
>
>> This is further reinforced by the fact
>> that smaller than /64 networks are occasionally handed out by ISPs to th=
eir
>> users.
>>
>> Are there any recommendations for protecting servers from the IPv6 addre=
ss
>> proliferation?
> [DJM] Address proliferation doesn't seem like a vulnerability to protect =
against.
> I think that would be deviating from the problem; the DOS attack.
> DOS is largely a game of resources; attempting to allocate a large enough=
 pool of resources, that participate in a DOS attack, so as to exceed the c=
apacity of the finite resources dedicated to handling a load.  The fact tha=
t the resources instigating the attack has a larger pool of addresses, to u=
se, doesn't change the amount of resources participating in the attack, or =
the number of addresses in use at a given point in time.
> Also, the likelihood that a DOS attack would be  sourced entirely from a =
single subnet seems more and more of an edge case as time goes on.  (If it =
were only that easy.)

IPv6 makes that easy. In IPv4 DOS attacks don't come from a single
subnet because it is expensive to obtain control of a big subnet. In
IPv6 you get 2^64 addresses just like that.

>> If not, are there any conventions for IPv6 address assignment
>> to end-users?
> [DJM] Outside of the typical DHCPv6 and SLAAC?

Could you elaborate what on that? I know that SLAAC requires /64 to
operate, but I'm not aware of any conventions for DHCPv6.

regards,
Nikos


From nobody Fri Oct 23 08:34:25 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663331A1A8D for ; Fri, 23 Oct 2015 08:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.683
X-Spam-Level: 
X-Spam-Status: No, score=-3.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_SUMOF=1, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPXJUEGUD_iO for ; Fri, 23 Oct 2015 08:34:22 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7576F1A1A72 for ; Fri, 23 Oct 2015 08:34:22 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9NFYHP4013314; Fri, 23 Oct 2015 17:34:17 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8152920726F; Fri, 23 Oct 2015 17:40:00 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6F0FB207233; Fri, 23 Oct 2015 17:40:00 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9NFYF4C022204; Fri, 23 Oct 2015 17:34:17 +0200
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <5629EEBE.7010908@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <562A5377.4060701@gmail.com>
Date: Fri, 23 Oct 2015 17:34:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 15:34:24 -0000

Le 23/10/2015 16:26, 神明é”哉 a écrit :
> At Fri, 23 Oct 2015 10:24:30 +0200,
> Alexandre Petrescu  wrote:
>
>>>> I believe /63 prefixlength is legal yes.
>>>>
>>>> SLAAC is done for any  length, the doc does not say 64.
>>>
>>> no, this is not legal.  A prefix in an RA PIO whose A bit is 1 and
>>> length is 64 on a link whose IID is supposed to be 64 bits violates
>>> Section 5.5.3 d of RFC 4862:
>>>
>>> If the sum of the prefix length and interface identifier length does
>>> not equal 128 bits, the Prefix Information option MUST be ignored.
>>
>> That is what the SLAAC RFC says, yes.
>
> I don't understand what you were trying to say below, but in any case,
> my point was (correcting a typo):
>
>    If an implementation performs SLAAC per RFC4862 Section 5.5.3 for a
>    prefix in an RA PIO whose A bit is 1 and length is 63 on a link
>    whose IID is supposed to be 64 bits, the implementation is "illegal"
>    (meaning violating RFC4862).

The !128 sum is illegal.  RFC4862 can't say which part is illegal.

If we take RFC4862 alone (not with rfc2464, nor 4291) then there is no 
violation in using a /63 with it.

There are many reasons to not take rfc2464 into consideration when 
discussing WiFi: WiFi and Ethernet are very different things.

There are some reasons to ignore some parts of RFC 4291.

> I believe others used legal/illegal for the same meaning.  Perhaps you
> wanted to say it's not explicitly prohibited to use an implementation
> to use the /63 prefix for something other than SLAAC by "legal".  If
> so, it would have been better to not use the word "legal" but explain
> this is some new protocol extension you wish to have.

Well, thanks for the explanation.

In truth this wish is more operational than protocol extension.

It is how to make /64s out of a /63.

It is how a smartphone tethers bigger LANs if it receives a /63 rather 
than a /64.

There is no new message exchange or new bits in message formats.

Alex

>> But more precisely, that is a requirement on the sum, not on the value
>> of _any_ of its parts.
>>
>> Given a 63 prefix len to that sum, the IID length must be 65.  And that
>> IID len 65 is wrong compared to RFC2464/4191 requiring the IID len to be 64.
>>
>> Can we conclude that because of that wrongness, the SLAAC RFC is wrong
>> with respect to RFC2464-RFC4191?  I dont think so.  Again because the
>> requirement in SLAAC RFC is on the _sum_ not on the value of the parts.
>>
>> So, if we can't think that the SLAAC RFC is wrong with respect to
>> RFC4191-2464 for the IID length being 65, then we can think that is
>> wrong with respect to a prefix length being 63.  It's just the sum that
>> must be respected.
>
> --
> JINMEI, Tatuya
>


From nobody Fri Oct 23 08:39:40 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DFB1A6F03 for ; Fri, 23 Oct 2015 08:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw4iVY_pIWh5 for ; Fri, 23 Oct 2015 08:39:37 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631CE1A6F10 for ; Fri, 23 Oct 2015 08:39:37 -0700 (PDT)
Received: by oiao187 with SMTP id o187so67780815oia.3 for ; Fri, 23 Oct 2015 08:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CdndEjDP2vEqMdem/o4UX5Pzu4cupVbJKxlUnH5oLKs=; b=afUYc9WIt3CV85D6sUWlU/ItVO3R7ozEGMyrRJxnGhZUTlEkkAOGIfwx/a67B7Jc1B v+lNuGgLkB5PZrNtoTxohGw4zFxo1k3WsE5lyStVYufsA5MQW0kd1XFYqSRl+YJXG633 fHXhXDwcmDxtsgbefx8cfhf1Cj5kyQKFHcUf0BbjLQ+mCXDKKasp1QGCBg5TwpsOv7YC Qs9NeVCYQPRnpAeOmOFNDVGu9rXraZIBTwc+tHP/r/3bfITsjDSwU3te5FE85XTrJ8Om sia3u5Ia4J6HmzL+MdUmrb3DuH5uI7KpiBEjwRzRzlHh9SuNEYpPNe9ObWvL/+dmb+CL QVdg==
MIME-Version: 1.0
X-Received: by 10.202.94.133 with SMTP id s127mr15239764oib.92.1445614776821;  Fri, 23 Oct 2015 08:39:36 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.76.80.73 with HTTP; Fri, 23 Oct 2015 08:39:36 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 23 Oct 2015 11:39:36 -0400
X-Google-Sender-Auth: 2WrRcKuvCV0je3FVA146JWPHnlk
Message-ID: 
From: Erik Nygren 
To: Nikos Mavrogiannopoulos 
Content-Type: multipart/alternative; boundary=001a113d4a2e412cd70522c76b09
Archived-At: 
Cc: "v6ops@ietf.org" , dplonka@akamai.com
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 15:39:39 -0000

--001a113d4a2e412cd70522c76b09
Content-Type: text/plain; charset=UTF-8

My colleagues David Plonka and Arthur Berger are presenting this paper at
IMC next week
which is of direct relevance to this topic:

David Plonka and Arthur Berger. "Temporal and Spatial Classification of
Active IPv6 Addresses".
Proceedings of the ACM Internet Measurement Conference (IMC), Tokyo, Japan,
October 28-30 2015.
http://arxiv.org/abs/1506.08134

http://conferences2.sigcomm.org/imc/2015/program.html

David will also be in Yokohama if people would like to ask him questions on
his research.

         Erik



On Fri, Oct 23, 2015 at 5:58 AM, Nikos Mavrogiannopoulos 
wrote:

> [this was originally sent to saag list, and I'm resending it here as
> this list is focused on IPv6]
>
> I've been looking on ways to prevent denial of service on a server
> application, and I stumbled on IPv6. By denial of service, I mean
> exhaustion of resources, being memory or CPU.
>
> Unlike IPv4, in IPv6 a user may typically have 2^64, and more able
> adversaries
> may have 2^80 or even more addresses(*). That means that single IP
> blacklisting to prevent DoS is not going to work; not even against a
> single adversary who has 2^64 IPs. So one would expect software to
> blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
> violate some of its "detection properties".  Given recommendations
> like RFC6164 which recommend /127 for PtP links (which can be a user
> VPN link), any heuristic that will ban whole networks looks more like
> a vessel to perform another denial of service (e.g., denying some user
> access to a server), rather than a solution to the original denial of
> service. This is further reinforced by the fact that smaller than /64
> networks
> are occasionally handed out by ISPs to their users.
>
> Are there any recommendations for protecting servers from the IPv6
> address proliferation? If not, are there any conventions for IPv6
> address assignment to end-users?
>
> regards,
> Nikos
>
> [0]. rfc6177 is supposed to describe the best current practice, but it
> mostly focuses on what isn't the current best practice (i.e., /48 is
> not recommended any more)
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--001a113d4a2e412cd70522c76b09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


My colleagues David Plonka and Arthur Berge=
r are presenting this paper at IMC next week
which is of direct re=
levance to this topic:


=20
David Plonka and Arthur Berger. "Te=
mporal and Spatial Classification of Active IPv6 Addresses". 
Proce=
edings of the ACM Internet Measurement Conference (IMC), Tokyo, Japan, Octo=
ber 28-30 2015.=20

http://arxiv.org/abs=
/1506.08134

http://conferences2.sigcomm.org/imc/2015/program.html
=

David will also be in Yokohama if people would like to ask him qu=
estions on his research.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Erik



On Fri, Oct 23, 2015 at 5:58 AM, Ni=
kos Mavrogiannopoulos <nmav@gnutls.org> wrote:
[this was originally sent to saag list, and I'm rese=
nding it here as

this list is focused on IPv6]



I've been looking on ways to prevent denial of service on a server

application, and I stumbled on IPv6. By denial of service, I mean

exhaustion of resources, being memory or CPU.



Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversar=
ies

may have 2^80 or even more addresses(*). That means that single IP

blacklisting to prevent DoS is not going to work; not even against a

single adversary who has 2^64 IPs. So one would expect software to

blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs

violate some of its "detection properties".=C2=A0 Given recommend=
ations

like RFC6164 which recommend /127 for PtP links (which can be a user

VPN link), any heuristic that will ban whole networks looks more like

a vessel to perform another denial of service (e.g., denying some user

access to a server), rather than a solution to the original denial of

service. This is further reinforced by the fact that smaller than /6=
4 networks

are occasionally handed out by ISPs to their users.



Are there any recommendations for protecting servers from the IPv6

address proliferation? If not, are there any conventions for IPv6

address assignment to end-users?



regards,

Nikos



[0]. rfc6177 is supposed to describe the best current practice, but it

mostly focuses on what isn't the current best practice (i.e., /48 is
not recommended any more)



_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--001a113d4a2e412cd70522c76b09--


From nobody Fri Oct 23 09:48:06 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F451A86FF for ; Fri, 23 Oct 2015 09:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBO6vdgFThbG for ; Fri, 23 Oct 2015 09:48:03 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F551A86EF for ; Fri, 23 Oct 2015 09:48:02 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 44C6862F1D for ; Fri, 23 Oct 2015 18:48:00 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id ED18260A5C for ; Fri, 23 Oct 2015 18:47:59 +0200 (CEST)
Received: (qmail 70025 invoked by uid 1007); 23 Oct 2015 18:47:59 +0200
Date: Fri, 23 Oct 2015 18:47:59 +0200
From: Gert Doering 
To: Nikos Mavrogiannopoulos 
Message-ID: <20151023164759.GD70452@Space.Net>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 16:48:05 -0000

Hi,

On Fri, Oct 23, 2015 at 05:07:42PM +0200, Nikos Mavrogiannopoulos wrote:
> This will affect someone who has divided a /64 into 2^32
> /96 subnets and shared it to different users, he will have his subnet
> completely blocked even if only 256 out of 2^32 is misbehaving. 

And rightly so.

There are enough IPv6 addresses available to NEVER give users less than
a /64 if they are given a "subnet".

So, someone doing this, and getting all his users blocked if a few of
them are misbehaving is getting what he deserves.  Period.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Fri Oct 23 09:55:54 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2BA1A874C for ; Fri, 23 Oct 2015 09:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WfbvQyofjgH for ; Fri, 23 Oct 2015 09:55:51 -0700 (PDT)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7687D1A8749 for ; Fri, 23 Oct 2015 09:55:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9NGtrdJ019598; Fri, 23 Oct 2015 09:55:53 -0700
Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9NGtkoj019558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 23 Oct 2015 09:55:47 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.49]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 09:55:44 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDWwH/+MZsnq7pUCTitCxpFGwKp55fxmA///FwdA=
Date: Fri, 23 Oct 2015 16:55:43 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 16:55:53 -0000

SGksDQoNCkkgcmVhZCB0aGlzIGRyYWZ0IGluIG1vcmUgZGV0YWlsLCBhbmQgSSBhbSBsZWZ0IHdp
dGggbWFueSBxdWVzdGlvbnMuIEZpcnN0LA0KSSBkb24ndCBzZWUgYW55IHByb3Zpc2lvbnMgZm9y
IG1vYmlsaXR5IG9yIHJvdXRlIG9wdGltaXphdGlvbi4gSW4gdGVybXMgb2YNCm1vYmlsaXR5LCB0
aGUgVUUncyBJUHY2IHByZWZpeCBhcHBlYXJzIHRvIGJlIHRldGhlcmVkIHRvIHRoZSBjdXJyZW50
IEFQDQpwb2ludCBhbmQgY2Fubm90IG1vdmUgd2l0aCB0aGUgVUUgYXMgaXQgbW92ZXMgZnJvbSBB
UCB0byBBUC4gSW4gdGVybXMNCm9mIHJvdXRlIG9wdGltaXphdGlvbiwgZXZlcnl0aGluZyBuZWVk
cyB0byBnbyB0aHJvdWdoIHRoZSBXTEFOLUdXDQphbmQgY2Fubm90IGdvIGRpcmVjdGx5IGZyb20g
VUUgdG8gVUUgZXZlbiBpZiB0aGUgdHdvIFVFcyBhcmUgcmlnaHQgbmV4dA0KdG8gb25lIGFub3Ro
ZXIuDQoNClRoZSBhcHByb2FjaCBhbHNvIHN0aWxsIHJlcXVpcmVzIHRoZSBVRSB0byBkbyBEQUQg
b3ZlciB0aGUgaW50ZXJmYWNlIGl0DQpyZWNlaXZlcyB0aGUgSVB2NiBSQSB3aXRoIFBJTyBmcm9t
LiBBcHByb2FjaGVzIHRoYXQgcHJvcGVybHkgZGVsZWdhdGUNCmFuIElQdjYgcHJlZml4IChlLmcu
LCBESENQdjYgUEQpIGRvIG5vdCByZXF1aXJlIERBRCBvdmVyIHRoZSBpbnRlcmZhY2UNCnRoZSBw
cmVmaXggaXMgcmVjZWl2ZWQgb24gYmVjYXVzZSB0aGUgcHJlZml4IGl0c2VsZiBtdXN0IG5vdCBi
ZSBhc3NpZ25lZA0KdG8gdGhhdCBpbnRlcmZhY2UuIEFuZCwgREhDUHY2IFBEIGNsaWVudCBpcyB0
cml2aWFsIHRvIGltcGxlbWVudCB0b2RheQ0KYW5kIGRvZXMgbm90IG5lZWQgdG8gYmUgcHVzaGVk
IGludG8gdGhlIGZhciBkaXN0YW50IGZ1dHVyZS4NCg0KVGhlIGFwcHJvYWNoIGlzIGFsc28gYSBu
ZXR3b3JrLWJhc2VkIGFwcHJvYWNoIHVzaW5nIGluLXRoZS1uZXR3b3JrDQp0dW5uZWxpbmcsIGJ1
dCB0aGVyZSBhcmUgYWxyZWFkeSBtYW55IHNvbHV0aW9ucyB0aGF0IGRvIHRoaXMgaW5jbHVkaW5n
DQpQTUlQdjYsIFByb3h5IEFFUk8sIGFuZCBDQVBXQVAuIEEgYmV0dGVyIG1vYmlsaXR5IGFuZCBy
b3V0ZQ0Kb3B0aW1pemF0aW9uIGV4cGVyaWVuY2UgaXMgYWxzbyBwb3NzaWJsZSB3aGVuIHRoZSBl
bmNhcHN1bGF0aW9uIGlzDQpyZW1vdmVkIGZyb20gdGhlIG5ldHdvcmsgYW5kIHBsYWNlZCBvbiB0
aGUgVUUgc3VjaCBhcyBmb3IgY2xpZW50DQpNSVB2NiBhbmQgY2xpZW50IEFFUk8uIEZvciBBRVJP
IGluIHBhcnRpY3VsYXIsIGl0IGlzIGEgdmVyeSBzaW1wbGUgYXBwDQp0aGF0IHJ1bnMgb24gdGhl
IFVFIHRoYXQgY2FuIGJlIGRvd25sb2FkZWQgYW5kIGludm9rZWQgaW4gYSBzaW1pbGFyDQpmYXNo
aW9uIGFzIGZvciBWUE4gY2xpZW50cyBsaWtlIE9wZW5WUE4uDQoNCkZpbmFsbHksIEkgYW0gYXNz
dW1pbmcgdGhhdCBpbiBsYXJnZSBkZXBsb3ltZW50cyB0aGVyZSB3aWxsIGJlIG1hbnkNCldMQU4t
R1dzIC0gZWFjaCBhc3NvY2lhdGVkIHdpdGggcG90ZW50aWFsbHkgbWFueSBBUHMuIEJ1dCwgdGhl
cmUNCmlzIG5vIGRpc2N1c3Npb24gb2YgaG93IG5ldHdvcmtpbmcgYmV0d2VlbiB0aGUgV0xBTi1H
V3Mgd2lsbA0Kb2NjdXIgLSBlc3BlY2lhbGx5IGlmIFVFcyBhcmUgYWxsb3dlZCB0byByb2FtIGJl
dHdlZW4gZGlmZmVyZW50DQpXTEFOLUdXcy4gVGhpcyBpcyBjb3ZlcmVkIGluIGRldGFpbCBpbiBB
RVJPIGFuZCBvdGhlciBhcHByb2FjaGVzLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxp
bkBib2VpbmcuY29tDQoNCg0K


From nobody Fri Oct 23 11:09:23 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8861A6EE8 for ; Fri, 23 Oct 2015 11:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb-nFCQY4o2Y for ; Fri, 23 Oct 2015 11:09:19 -0700 (PDT)
Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04391A3BA7 for ; Fri, 23 Oct 2015 11:09:18 -0700 (PDT)
Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id C4D3115EC39 for ; Fri, 23 Oct 2015 20:08:48 +0200 (CEST)
Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id B7FE090C for ; Fri, 23 Oct 2015 20:09:16 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id 9B948C4A68; Fri, 23 Oct 2015 20:09:16 +0200 (CEST)
Date: Fri, 23 Oct 2015 20:09:16 +0200
From: Enno Rey 
To: v6ops@ietf.org
Message-ID: <20151023180916.GA10645@ernw.de>
References:    <20151023164759.GD70452@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151023164759.GD70452@Space.Net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 18:09:22 -0000

Hi,

On Fri, Oct 23, 2015 at 06:47:59PM +0200, Gert Doering wrote:
> Hi,
> 
> On Fri, Oct 23, 2015 at 05:07:42PM +0200, Nikos Mavrogiannopoulos wrote:
> > This will affect someone who has divided a /64 into 2^32
> > /96 subnets and shared it to different users, he will have his subnet
> > completely blocked even if only 256 out of 2^32 is misbehaving. 
> 
> And rightly so.
> 
> There are enough IPv6 addresses available to NEVER give users less than
> a /64 if they are given a "subnet".
> 
> So, someone doing this, and getting all his users blocked if a few of
> them are misbehaving is getting what he deserves.  Period.

wait a second.
what about a "Guest Wifi" network (implemented as a /64 - I mean, what else, and) shared by hundreds of users?
any of those users can still perform attacks with many many different source addresses... or am I overlooking sth here/misunderstanding the scenario laid out?

best

Enno






> 
> Gert Doering
>         -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


From nobody Fri Oct 23 11:34:02 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08CA1A896A for ; Fri, 23 Oct 2015 11:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhcNGhgsVH-h for ; Fri, 23 Oct 2015 11:33:58 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 62CAF1A895E for ; Fri, 23 Oct 2015 11:33:58 -0700 (PDT)
Received: from [181.165.127.203] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zph9y-0006kO-Jn; Fri, 23 Oct 2015 20:33:50 +0200
To: Nikos Mavrogiannopoulos , v6ops@ietf.org
References: 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <562A5C3A.80905@gont.com.ar>
Date: Fri, 23 Oct 2015 13:11:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 18:34:01 -0000

Hi, Nikos,

On 10/23/2015 06:58 AM, Nikos Mavrogiannopoulos wrote:
> [this was originally sent to saag list, and I'm resending it here as
> this list is focused on IPv6]
> 
> I've been looking on ways to prevent denial of service on a server
> application, and I stumbled on IPv6. By denial of service, I mean
> exhaustion of resources, being memory or CPU.
> 
> Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries
> may have 2^80 or even more addresses(*). That means that single IP
> blacklisting to prevent DoS is not going to work; not even against a
> single adversary who has 2^64 IPs. So one would expect software to
> blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
> violate some of its "detection properties". 

Yes. I'd expect that in those cases where in IPv4 you'd ban a single
IPv4, you'd likely ban a prefix in the IPv6 world (typically a /64).

You might want to re-ask your question on this list, too:


Thanks!

Best regards,
-- 
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 Fri Oct 23 13:20:43 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B221A8BAF for ; Fri, 23 Oct 2015 13:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHL2lukInEF6 for ; Fri, 23 Oct 2015 13:20:41 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531BD1A8ADA for ; Fri, 23 Oct 2015 13:20:40 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8A47A62E64 for ; Fri, 23 Oct 2015 22:20:38 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3491760612 for ; Fri, 23 Oct 2015 22:20:38 +0200 (CEST)
Received: (qmail 78458 invoked by uid 1007); 23 Oct 2015 22:20:38 +0200
Date: Fri, 23 Oct 2015 22:20:38 +0200
From: Gert Doering 
To: Enno Rey 
Message-ID: <20151023202038.GJ70452@Space.Net>
References:    <20151023164759.GD70452@Space.Net> <20151023180916.GA10645@ernw.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151023180916.GA10645@ernw.de>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 20:20:43 -0000

Hi,

On Fri, Oct 23, 2015 at 08:09:16PM +0200, Enno Rey wrote:
> > There are enough IPv6 addresses available to NEVER give users less than
> > a /64 if they are given a "subnet".
> > 
> > So, someone doing this, and getting all his users blocked if a few of
> > them are misbehaving is getting what he deserves.  Period.
> 
> wait a second.
> what about a "Guest Wifi" network (implemented as a /64 - I mean, what else, and) shared by hundreds of users?
> any of those users can still perform attacks with many many different source addresses... or am I overlooking sth here/misunderstanding the scenario laid out?

What would you do in IPv4 land?  Right, block the single external IPv4
address of the Guest Wifi NAT router...

This usually gets the attention of those operating the network that 
they have something bad in their backyard.

With IPv6, one could do better, of course - reduce the amount of addresses
that a client can use (enforce first hop security), and/or delegate a 
dedicated prefix to the client (Lorenzo's recent draft)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Fri Oct 23 15:46:06 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB861B2EAF for ; Fri, 23 Oct 2015 15:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA2YYz5gCkuW for ; Fri, 23 Oct 2015 15:46:03 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DC31B2EB7 for ; Fri, 23 Oct 2015 15:46:02 -0700 (PDT)
Received: by pabrc13 with SMTP id rc13so129221555pab.0 for ; Fri, 23 Oct 2015 15:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uPm9frqT+NcEjOihBVeIJyP4OdCwq2HX7t1kNYdpTyk=; b=pFUny98qSNjsJ2sY7zZHhH6znFYonbraQcQ0dCmxO4lV0MiENI2s6qrWMpcQPpqp2l jHWMW55vYL5IzWEwMse33bmXzYsa7KDEs99iRLnIPgiz2BPxleKeGiTf6lk8OdvzI5Sj IUIpgg6gXiocBhN1DuUe/XWIY07VNLIV6r87PujKp84woXvwMhFZmmJZqx0cZzi87AKD jkZxG8qv28ieeMCruB/B5c8i56YZefs47HdisNLSXUnD9ZtWnZZSrMPVmHSm/NNPLR57 CIYTdXlGTAaHq44SYjnpI+HfLdJDAdz7c32RPbJd6jEYTh7RdTO6L5EDdSj99x245Cmz gAOw==
X-Received: by 10.66.118.129 with SMTP id km1mr7621107pab.4.1445640362588; Fri, 23 Oct 2015 15:46:02 -0700 (PDT)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ij3sm5468501pbb.62.2015.10.23.15.45.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 15:46:01 -0700 (PDT)
To: Gert Doering , Nikos Mavrogiannopoulos 
References:    <20151023164759.GD70452@Space.Net>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <562AB8B2.4010109@gmail.com>
Date: Sat, 24 Oct 2015 11:46:10 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151023164759.GD70452@Space.Net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 22:46:04 -0000

On 24/10/2015 05:47, Gert Doering wrote:
> Hi,
> 
> On Fri, Oct 23, 2015 at 05:07:42PM +0200, Nikos Mavrogiannopoulos wrote:
>> This will affect someone who has divided a /64 into 2^32
>> /96 subnets and shared it to different users, he will have his subnet
>> completely blocked even if only 256 out of 2^32 is misbehaving. 
> 
> And rightly so.
> 
> There are enough IPv6 addresses available to NEVER give users less than
> a /64 if they are given a "subnet".
> 
> So, someone doing this, and getting all his users blocked if a few of
> them are misbehaving is getting what he deserves.  Period.

Or to say it another way: don't do that. Read http://tools.ietf.org/html/rfc7421
which tells you in painful detail why you shouldn't do that.

If you must blacklist, blacklist a /64. As others have said, that is roughly
the same as blacklisting the IPv4 address of a NAT, or blacklisting an
IPv4 subnet. In any case, with IPv6, you must expect the attacker to be
changing their interface identifier all the time.

   Brian


From nobody Fri Oct 23 15:55:02 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056851A8A57 for ; Fri, 23 Oct 2015 15:55:01 -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=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_kbZkjw1e9w for ; Fri, 23 Oct 2015 15:54:58 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4911A1BA7 for ; Fri, 23 Oct 2015 15:54:57 -0700 (PDT)
Received: by vkex70 with SMTP id x70so71690514vke.3 for ; Fri, 23 Oct 2015 15:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t/QvEDdKq9uXJBbH6v0VYLfMmHnubK79BybXmrtrCbs=; b=MWG5mEc2J1c+n1TeyClpNHNa0dH8Xb9IJKvUk9iKX1p4AenSjwPX/p/dS7ru38EV46 wBaRliHPk6wCtxAFXDXxMUZvrSI6TlL998f/PPsPpRtz+VYn1cczcXsYw5XsL6Eob9rq UD/4tnHGOEdJYhNKT6IKNsTKuXb8w/SzLSocbPzd5ys8dgC49SV8CGsXpzGx6knW69nA 4IeRBULw6lQ3MVQ9yG2MmnxUx/gwQTrfKIUINWoBpEU0nS+dnlcbm/kPn03JDHJzLIzG iuBGQNPKumlrnYrzxfI2r+zCNlWpckCnT36uTcWg1s215OgCwhl2ob60FabnsvrUOVNa SOFw==
MIME-Version: 1.0
X-Received: by 10.31.132.79 with SMTP id g76mr15163542vkd.40.1445640896960; Fri, 23 Oct 2015 15:54:56 -0700 (PDT)
Received: by 10.103.67.194 with HTTP; Fri, 23 Oct 2015 15:54:56 -0700 (PDT)
Received: by 10.103.67.194 with HTTP; Fri, 23 Oct 2015 15:54:56 -0700 (PDT)
In-Reply-To: <562A17F0.4040309@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>  <5629FA51.4000807@gmail.com>  <562A17F0.4040309@gmail.com>
Date: Sat, 24 Oct 2015 09:54:56 +1100
Message-ID: 
From: Mark Smith 
To: Alexandre Petrescu 
Content-Type: multipart/alternative; boundary=001a1145809622de120522cd803f
Archived-At: 
Cc: v6ops list , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 22:55:01 -0000

--001a1145809622de120522cd803f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 Oct 2015 22:20, "Alexandre Petrescu" 
wrote:
>
>
>
> Le 23/10/2015 11:46, Mark Smith a =C3=A9crit :
>>
>> On 23 October 2015 at 20:13, Alexandre Petrescu
>>  wrote:
>>>
>>>
>>>
>>> Le 23/10/2015 10:55, Mark Smith a =C3=A9crit :
>>>>
>>>>
>>>> On 23 October 2015 at 19:25, Alexandre Petrescu
>>>>  wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le 22/10/2015 19:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9cri=
t : [...]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regarding the main context, I don't know how advertising /63
>>>>>>  helps the tethering scenario, btw.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Giving a '/63' to the smartphone allows it to create some
>>>>> '/64's out of it.
>>>>
>>>>
>>>>
>>>> Does code exist that already does this?
>>>
>>>
>>>
>>> I dont know?
>>>

So we know that code does exist for DHCPv6-PD, and it has been proven
though production deployments.

>>> I know that in homenet they have this Prefix Assignment RFC-to-be
>>> which talks about 'portioning' a prefix.  The problem of
>>> automatically making sub-prefixes out of a prefix is well sensed
>>> in homenets.
>>>
>>>> If it doesn't, why wouldn't it be better to implement DHCPv6-PD,
>>>> the existing, tested and proven mechanism to do this sort of
>>>> thing?
>>>
>>>
>>>
>>> DHCPv6-PD - yes there is software available and it works ok on many
>>> platforms as I've tried it extensively.
>>>
>>> But it looks simpler to make 64s out of a 63 - it's a local
>>> decision on the device.
>>>
>>
>> I don't think it is simpler.
>>
>> It relies on only one device being on the link.
>
>
> Well yes and no.
>
> A possibility is the /63 prefix would be advertised as not being
> on-link, and the device would not form a global address out of it.

So would the router blindly forward traffic for the /63 to the host,
regardless of whether the host was using it? It would have to unless there
was a way to signal its use, and that mandates an assumption that there is
only one device on the link that can use the /63.

If there are two or more devices on the link that could use the /63, then
you need a signaling method to indicate which one is using it.

> Also, the case described by the jjmb draft proposes each device a unique
> prefix.  Not sure how that translates to subnets and links - maybe there
> are several subnets present on a link already.
>
>
>> It relies on the upstream router knowing there is only one device on
>>  the link, so that it doesn't ND NS for any addresses in the space it
>>  is advertising, instead it sends all traffic to the device.
>
>
> That is true, provided the device configures an address within that /63
> prefix.
>
>
>> It relies on the link being point to point, because the above
>> conditions can only be true if the link is a point-to-point link
>> between a router and host that might want to act as a router if it
>> decides to.
>
>
> It may be that what the jjmb draft proposes looks as a point-to-point
link.
>
>
>> We end up with:
>>
>> If ConditionA, ConditionB and ConditionC, then
>>
>> SolutionY (/63s)
>>
>> else
>>
>> SolutionX (DHCPv6-PD)
>>
>>
>>
>> Where as,
>>
>>
>> If ConditionA, ConditionB and ConditionC, then
>>
>> SolutionX (DHCPv6-PD)
>>
>> else
>>
>> SolutionX (DHCPv6-PD)
>>
>>
>> or just
>>
>>
>> SolutionX (DHCPv6-PD)
>>
>>
>> will also work for both situations.
>
>
> I can agree.  I just dont know how to persuade others to implement
> DHCP-PD.  Especially operators.
>

We need to find out why they aren't implementing DHCPv6-PD first.

It could just be that they don't have a need right now for a delegated
prefix solution (although given what I've heard about some carriers, it
might be because they object to the idea of tethering from a business point
of view.)

There is no evidence that DHCPv6-PD is fatally flawed at performing this
task, so there is no need to invent an alternative. By doing so, it creates
a greater barrier to adopting either of them, because now a value and
somewhat subjective judgement has to be made as to which one is
functionally best, which one is likely going to have the most vendor
support, which one is going to be most commonly understood by people
operating network using them.

More choice isn't always good.

>
>> The code in a smartphone to do /63s divided into /64s might be
>> simpler than the code to do DHCPv6-PD. However, there is also code
>> overhead in the upstream router,
>
>
> There is code overhead in the upstream router only if the device
> configures an address for its egress interface out of that /63.
> Otherwise there is not.
>

So if the /63 is used by the device, than that had to be signaled to the
router, so the router treated the device as a next hop for the prefix,
which equals more code in the router to process the signaling.

The thing is, when you address all of the issues that crop up, you end up
with having invented something that is going to look very similar to
DHCPv6-PD.

> Remark the jjmb draft already proposes some changes in the upstream
> router in order to realize the unique-prefix/device work on WiFi.  They
> dont recomment DHCP-PD.  Should one advise to rather use DHCP-PD?
>

I think so, it is the way prefixes have been delegated to devices in
production networks for many years now.

>
>> and there are also human mental, operational and troubleshooting
>> overheads, because now there are two solutions to the same problems
>> which have to be learned, operated, troubleshooted, and a set of
>> conditions to learn to know which solution will or might be used
>> when, which is also more human mental overhead.
>
>
> I can agree.
>
>
>> (The existence of the "sharing /64" RFC shouldn't be seen as an
>> indication that multiple solutions to this sort of problem is ok - it
>> has a number of limitations, and is only a work around to 3GPP
>> freezing feature sets such that for certain devices it isn't possible
>> to deploy DHCPv6-PD, despite the devices really just being pocket
>> computers/hosts that just happen to be able to also make phone
>> calls.)
>
>
> I can agree.  But I think it is hard to suggest operators of networks
> supporting mobile devices to implement DHCP-PD.
>

>From what I remember, "share /64" was an interim work around to certain
revisions of 3GPP devices, and later revisions of the 3GPP specs specified
DHCPv6-PD as the solution.

So operators not impending this can't just be assumed to be because they
don't find DHCPV6-PD to be an acceptable solution.

Regards,
Mark.

> Alex
>
>
>>
>> Regards, Mark.
>>
>>
>>> All the operators must do is not hardcode 64 prefixlengths, i.e.
>>> have it as a parameter.
>>>
>>> Some operators moved from a 64-centric for end-user way of
>>> thinking - it's a parameter.
>>>
>>> Alex
>>>
>>>>
>>>>
>>>>
>>>>> They are useful for SLAAC in its LAN segments.  Giving it a
>>>>> '64' allows it to create '65's which can not be used with
>>>>> SLAAC in its LAN segments.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> -- JINMEI, Tatuya
>>>>>>
>>>>>
>>>>> _______________________________________________ v6ops mailing
>>>>> list v6ops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>>
>>>>
>>>
>>
>

--001a1145809622de120522cd803f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 23 Oct 2015 22:20, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:
>

>

>

> Le 23/10/2015 11:46, Mark Smith a =C3=A9crit :

>>

>> On 23 October 2015 at 20:13, Alexandre Petrescu

>> <alexandre.petr=
escu@gmail.com> wrote:

>>>

>>>

>>>

>>> Le 23/10/2015 10:55, Mark Smith a =C3=A9crit :

>>>>

>>>>

>>>> On 23 October 2015 at 19:25, Alexandre Petrescu

>>>> <alexan=
dre.petrescu@gmail.com> wrote:

>>>>>

>>>>>

>>>>>

>>>>>

>>>>> Le 22/10/2015 19:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=
=89 a =C3=A9crit : [...]

>>>>>>

>>>>>>

>>>>>>

>>>>>> Regarding the main context, I don't know how a=
dvertising /63

>>>>>> =C2=A0helps the tethering scenario, btw.

>>>>>

>>>>>

>>>>>

>>>>>

>>>>> Giving a '/63' to the smartphone allows it to =
create some

>>>>> '/64's out of it.

>>>>

>>>>

>>>>

>>>> Does code exist that already does this?

>>>

>>>

>>>

>>> I dont know?

>>>


So we know that code does exist for DHCPv6-PD, and it has be=
en proven though production deployments.


>>> I know that in homenet they have this Prefix As=
signment RFC-to-be

>>> which talks about 'portioning' a prefix.=C2=A0 The pro=
blem of

>>> automatically making sub-prefixes out of a prefix is well sens=
ed

>>> in homenets.

>>>

>>>> If it doesn't, why wouldn't it be better to implem=
ent DHCPv6-PD,

>>>> the existing, tested and proven mechanism to do this sort =
of

>>>> thing?

>>>

>>>

>>>

>>> DHCPv6-PD - yes there is software available and it works ok on=
 many

>>> platforms as I've tried it extensively.

>>>

>>> But it looks simpler to make 64s out of a 63 - it's a loca=
l

>>> decision on the device.

>>>

>>

>> I don't think it is simpler.

>>

>> It relies on only one device being on the link.

>

>

> Well yes and no.

>

> A possibility is the /63 prefix would be advertised as not being

> on-link, and the device would not form a global address out of it.


So would the router blindly forward traffic for the /63 to t=
he host, regardless of whether the host was using it? It would have to unle=
ss there was a way to signal its use, and that mandates an assumption that =
there is only one device on the link that can use the /63.


If there are two or more devices on the link that could use =
the /63, then you need a signaling method to indicate which one is using it=
.


> Also, the case described by the jjmb draft proposes eac=
h device a unique

> prefix.=C2=A0 Not sure how that translates to subnets and links - mayb=
e there

> are several subnets present on a link already.

>

>

>> It relies on the upstream router knowing there is only one device =
on

>> =C2=A0the link, so that it doesn't ND NS for any addresses in =
the space it

>> =C2=A0is advertising, instead it sends all traffic to the device.<=
br>
>

>

> That is true, provided the device configures an address within that /6=
3

> prefix.

>

>

>> It relies on the link being point to point, because the above

>> conditions can only be true if the link is a point-to-point link
>> between a router and host that might want to act as a router if it=


>> decides to.

>

>

> It may be that what the jjmb draft proposes looks as a point-to-point =
link.

>

>

>> We end up with:

>>

>> If ConditionA, ConditionB and ConditionC, then

>>

>> SolutionY (/63s)

>>

>> else

>>

>> SolutionX (DHCPv6-PD)

>>

>>

>>

>> Where as,

>>

>>

>> If ConditionA, ConditionB and ConditionC, then

>>

>> SolutionX (DHCPv6-PD)

>>

>> else

>>

>> SolutionX (DHCPv6-PD)

>>

>>

>> or just

>>

>>

>> SolutionX (DHCPv6-PD)

>>

>>

>> will also work for both situations.

>

>

> I can agree.=C2=A0 I just dont know how to persuade others to implemen=
t

> DHCP-PD.=C2=A0 Especially operators.

>


We need to find out why they aren't implementing DHCPv6-=
PD first.


It could just be that they don't have a need right now f=
or a delegated prefix solution (although given what I've heard about so=
me carriers, it might be because they object to the idea of tethering from =
a business point of view.)


There is no evidence that DHCPv6-PD is fatally flawed at per=
forming this task, so there is no need to invent an alternative. By doing s=
o, it creates a greater barrier to adopting either of them, because now a v=
alue and somewhat subjective judgement has to be made as to which one is fu=
nctionally best, which one is likely going to have the most vendor support,=
 which one is going to be most commonly understood by people operating netw=
ork using them.


More choice isn't always good.


>

>> The code in a smartphone to do /63s divided into /64s might be

>> simpler than the code to do DHCPv6-PD. However, there is also code=


>> overhead in the upstream router,

>

>

> There is code overhead in the upstream router only if the device

> configures an address for its egress interface out of that /63.

> Otherwise there is not.

>


So if the /63 is used by the device, than that had to be sig=
naled to the router, so the router treated the device as a next hop for the=
 prefix, which equals more code in the router to process the signaling.


The thing is, when you address all of the issues that crop u=
p, you end up with having invented something that is going to look very sim=
ilar to DHCPv6-PD.


> Remark the jjmb draft already proposes some changes in =
the upstream

> router in order to realize the unique-prefix/device work on WiFi.=C2=
=A0 They

> dont recomment DHCP-PD.=C2=A0 Should one advise to rather use DHCP-PD?=


>


I think so, it is the way prefixes have been delegated to de=
vices in production networks for many years now. 


>

>> and there are also human mental, operational and troubleshooting
>> overheads, because now there are two solutions to the same problem=
s

>> which have to be learned, operated, troubleshooted, and a set of
>> conditions to learn to know which solution will or might be used
>> when, which is also more human mental overhead.

>

>

> I can agree.

>

>

>> (The existence of the "sharing /64" RFC shouldn't be=
 seen as an

>> indication that multiple solutions to this sort of problem is ok -=
 it

>> has a number of limitations, and is only a work around to 3GPP

>> freezing feature sets such that for certain devices it isn't p=
ossible

>> to deploy DHCPv6-PD, despite the devices really just being pocket<=
br>
>> computers/hosts that just happen to be able to also make phone

>> calls.)

>

>

> I can agree.=C2=A0 But I think it is hard to suggest operators of netw=
orks

> supporting mobile devices to implement DHCP-PD.

>


From what I remember, "share /64" was an interim w=
ork around to certain revisions of 3GPP devices, and later revisions of the=
 3GPP specs specified DHCPv6-PD as the solution.


So operators not impending this can't just be assumed to=
 be because they don't find DHCPV6-PD to be an acceptable solution.


Regards,

Mark.


> Alex

>

>

>>

>> Regards, Mark.

>>

>>

>>> All the operators must do is not hardcode 64 prefixlengths, i.=
e.

>>> have it as a parameter.

>>>

>>> Some operators moved from a 64-centric for end-user way of

>>> thinking - it's a parameter.

>>>

>>> Alex

>>>

>>>>

>>>>

>>>>

>>>>> They are useful for SLAAC in its LAN segments.=C2=A0 G=
iving it a

>>>>> '64' allows it to create '65's which c=
an not be used with

>>>>> SLAAC in its LAN segments.

>>>>>

>>>>> Alex

>>>>>

>>>>>>

>>>>>> -- JINMEI, Tatuya

>>>>>>

>>>>>

>>>>> _______________________________________________ v6ops =
mailing

>>>>> list v6ops@ietf.org<=
/a>

>>>>> https://www.ietf.org/mailman/listinfo/v6ops

>>>>

>>>>

>>>>

>>>

>>

>




--001a1145809622de120522cd803f--


From nobody Fri Oct 23 16:55:51 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F9F1A8A84 for ; Fri, 23 Oct 2015 16:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1Ltxi9rGxsG for ; Fri, 23 Oct 2015 16:55:49 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EF61A8A3D for ; Fri, 23 Oct 2015 16:55:48 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-20-562ac9035d0c
Received: from PACDCEXHUB02.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 5C.49.04607.309CA265; Fri, 23 Oct 2015 19:55:47 -0400 (EDT)
Received: from PACDCEX46.cable.comcast.com (24.40.2.145) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 Oct 2015 19:55:46 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX46.cable.comcast.com (24.40.2.145) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 23 Oct 2015 19:55:46 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Fri, 23 Oct 2015 19:55:46 -0400
From: "Brzozowski, John" 
To: "Templin, Fred L" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwg==
Date: Fri, 23 Oct 2015 23:55:45 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com>  <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.11]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsXiEq4ko8t8UivMoPWoqsX5U1NYLE4f28vs wOTx++AbZo8lS34yBTBFcdmkpOZklqUW6dslcGX8vDmPsaBHs6L71AKmBsYWjS5GTg4JAROJ ztVHmSBsMYkL99azdTFycQgJ7GKS2HlxLStIQkhgL6PEsrkiEIndjBK3X5+BSpxklDhwOALE ZhOwkXj94ScjiC0iECYx+dwCFhBbWCBaYseWfjaIeIzErBeNTBC2nsS3id+YQWwWAVWJAyeX g9XwCthLfNt9nx1i2QQWidlvv4MlOAVCJea0XwRbzAh06vdTa8AGMQuIS9x6Mh/qBQGJJXvO M0PYohIvH/8DqxcFWtZ+6j8bRNxAYuvSfUDHcQDZ8hIf5zKBmMwCmhLrd+lDTHSQ+DOxhwXC VpSY0v2QHeI0QYmTM5+AdQoBTZz3QBpioLjE4SM7WCcwysxCcs8shKGzkAydhWToLCRDFzCy rmKUK0hMTknOzcgvLTEw1EtOTMpJ1UvOz01OLC4B0ZsYwVEvv3wH470XTocYBTgYlXh4a7dp hQmxJpYVV+YeYpTgYFYS4T0+AyjEm5JYWZValB9fVJqTWnyIUZqDRUmcd/O9X6FCAumJJanZ qakFqUUwWSYOTqkGxk6NNNepBR9O/VpYInC/OXNL8ISJWw/2TpnAt9CoR7086JmdkNC3pS+u b57Q0h1QKGj7dplck9DvkIJg3cS5E0vZVCUmfTr191/VzFbzXj/zW50PTyXtnrZ16/sTnyw/ 501hi2fmzbQ58DHyLlvxqe9P1vhV94oLSiS9Cz018WbrnMXOnIpdsUosxRmJhlrMRcWJACIi +fT2AgAA
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Oct 2015 23:55:50 -0000

DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNA
aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmVkIFRlbXBsaW4NCjxGcmVkLkwuVGVtcGxpbkBib2Vp
bmcuY29tPg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDIzLCAyMDE1IGF0IDEyOjU1DQpUbzogdjZv
cHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9u
Og0KZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoN
Cj5IaSwNCj4NCj5JIHJlYWQgdGhpcyBkcmFmdCBpbiBtb3JlIGRldGFpbCwgYW5kIEkgYW0gbGVm
dCB3aXRoIG1hbnkgcXVlc3Rpb25zLg0KPkZpcnN0LA0KPkkgZG9uJ3Qgc2VlIGFueSBwcm92aXNp
b25zIGZvciBtb2JpbGl0eSBvciByb3V0ZSBvcHRpbWl6YXRpb24uIEluIHRlcm1zIG9mDQo+bW9i
aWxpdHksIHRoZSBVRSdzIElQdjYgcHJlZml4IGFwcGVhcnMgdG8gYmUgdGV0aGVyZWQgdG8gdGhl
IGN1cnJlbnQgQVANCj5wb2ludCBhbmQgY2Fubm90IG1vdmUgd2l0aCB0aGUgVUUgYXMgaXQgbW92
ZXMgZnJvbSBBUCB0byBBUC4NCltqam1iXSBhcyB0aGUgZHJhZnQgc2l0ZXMgQVBzIGFyZSBsYXJn
ZWx5IHRyYW5zcGFyZW50LiAgTW9iaWxpdHkgaXMNCnN1cHBvcnQgYmV0d2VlbiBBUHMsIGhvd2V2
ZXIsIFdMQU4tR1cgdG8gV0xBTi1HVyB3aWxsIHJlc3VsdCBpbiBhDQpyZW51bWJlcmluZy4gIEFz
IGZhciBhcyByb3V0ZSBvcHRpbWl6YXRpb24gaXMgY29uY2VybmVkIEkgYW0gbm90IHN1cmUgaG93
DQplbHNlIHdlIGNhbiBvcHRpbWl6ZSByb3V0aW5nIHRvIGEgZGVmYXVsdCBnYXRld2F5Lg0KPklu
IHRlcm1zDQo+b2Ygcm91dGUgb3B0aW1pemF0aW9uLCBldmVyeXRoaW5nIG5lZWRzIHRvIGdvIHRo
cm91Z2ggdGhlIFdMQU4tR1cNCj5hbmQgY2Fubm90IGdvIGRpcmVjdGx5IGZyb20gVUUgdG8gVUUg
ZXZlbiBpZiB0aGUgdHdvIFVFcyBhcmUgcmlnaHQgbmV4dA0KPnRvIG9uZSBhbm90aGVyLg0KW2pq
bWJdIHRoaXMgaXMgYWN0dWFsbHkgZGVsaWJlcmF0ZSBhbmQgY29uc2lkZXJlZCBhIGZlYXR1cmUu
ICBBbHNvIG5vdGUNCnRoZSBMIGJpdCBpcyBzZXQgdG8gMCB0byBmdXJ0aGVyIGVuY291cmFnZSB0
aGUgdXNlIG9mIHRoZSBkZWZhdWx0IGdhdGV3YXkNCihXTEFOLUdXKSB0byBmYWNpbGl0YXRlIG5v
ZGUgdG8gSW50ZXJuZXQgYW5kIG5vZGUgdG8gbm9kZSBjb21tdW5pY2F0aW9ucy4NCj4NCj5UaGUg
YXBwcm9hY2ggYWxzbyBzdGlsbCByZXF1aXJlcyB0aGUgVUUgdG8gZG8gREFEIG92ZXIgdGhlIGlu
dGVyZmFjZSBpdA0KPnJlY2VpdmVzIHRoZSBJUHY2IFJBIHdpdGggUElPIGZyb20uDQpbamptYl0g
dGhpcyBjb3VsZCBjb25jZWl2YWJseSBiZSBvbWl0dGVkIG90aGVyIHRoYW4gdGhlIERBRCBmb3Ig
dGhlIFVFDQpsaW5rIGxvY2FsIGFkZHJlc3MuICBQZXJoYXBzIHdlIGNhbiBvcHRpbWl6ZSBEQUQg
Ynkgc2V0dGluZyBhZGRpdGlvbmFsDQpmbGFncyBpbiB0aGUgUkEuDQo+QXBwcm9hY2hlcyB0aGF0
IHByb3Blcmx5IGRlbGVnYXRlDQo+YW4gSVB2NiBwcmVmaXggKGUuZy4sIERIQ1B2NiBQRCkgZG8g
bm90IHJlcXVpcmUgREFEIG92ZXIgdGhlIGludGVyZmFjZQ0KPnRoZSBwcmVmaXggaXMgcmVjZWl2
ZWQgb24gYmVjYXVzZSB0aGUgcHJlZml4IGl0c2VsZiBtdXN0IG5vdCBiZSBhc3NpZ25lZA0KPnRv
IHRoYXQgaW50ZXJmYWNlLg0KW2pqbWJdIHRoaXMgaXMgd2hhdCBpcyBwbGFubmVkIGZvciB3aGVu
L2lmIHdlIHN1cHBvcnQgUEQuDQo+IEFuZCwgREhDUHY2IFBEIGNsaWVudCBpcyB0cml2aWFsIHRv
IGltcGxlbWVudCB0b2RheQ0KPmFuZCBkb2VzIG5vdCBuZWVkIHRvIGJlIHB1c2hlZCBpbnRvIHRo
ZSBmYXIgZGlzdGFudCBmdXR1cmUuDQpbamptYl0gdGhlIGluY3JlbWVudGFsIG5hdHVyZSBvZiB0
aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGNsaWVudCwNCmhhcyB0byBkbyB3aXRoIHR3
byB0aGluZ3MuICAxKSB3ZSBhcmUgZG9pbmcgdGhpcyBpbmNyZW1lbnRhbGx5IGFuZCAyKSB3ZQ0K
bmVlZCB0byBtYWtlIHN1cmUgdGhlIFdMQU4tR1cgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhp
cyB1bml2ZXJzYWxseSB0bw0KYXZvaWQgcGFydGlhbCBzdXBwb3J0Lg0KPg0KPlRoZSBhcHByb2Fj
aCBpcyBhbHNvIGEgbmV0d29yay1iYXNlZCBhcHByb2FjaCB1c2luZyBpbi10aGUtbmV0d29yaw0K
PnR1bm5lbGluZywgYnV0IHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgc29sdXRpb25zIHRoYXQgZG8g
dGhpcyBpbmNsdWRpbmcNCj5QTUlQdjYsIFByb3h5IEFFUk8sIGFuZCBDQVBXQVAuIEEgYmV0dGVy
IG1vYmlsaXR5IGFuZCByb3V0ZQ0KPm9wdGltaXphdGlvbiBleHBlcmllbmNlIGlzIGFsc28gcG9z
c2libGUgd2hlbiB0aGUgZW5jYXBzdWxhdGlvbiBpcw0KPnJlbW92ZWQgZnJvbSB0aGUgbmV0d29y
ayBhbmQgcGxhY2VkIG9uIHRoZSBVRSBzdWNoIGFzIGZvciBjbGllbnQNCj5NSVB2NiBhbmQgY2xp
ZW50IEFFUk8uIEZvciBBRVJPIGluIHBhcnRpY3VsYXIsIGl0IGlzIGEgdmVyeSBzaW1wbGUgYXBw
DQo+dGhhdCBydW5zIG9uIHRoZSBVRSB0aGF0IGNhbiBiZSBkb3dubG9hZGVkIGFuZCBpbnZva2Vk
IGluIGEgc2ltaWxhcg0KPmZhc2hpb24gYXMgZm9yIFZQTiBjbGllbnRzIGxpa2UgT3BlblZQTi4N
Cltqam1iXSBJIGhhdmUgbm8gY29udHJvbCBvdmVyIHRoZSBjbGllbnRzIGFzIHN1Y2ggSSBjYW4g
bm90IGVuZm9yY2UgdGhlDQppbnN0YWxsYXRpb24gb2Ygc3VjaCBzb2Z0d2FyZS4gIEkgYW0gcXVp
dGUgSSB3b3VsZCBnZXQgYSB2ZXJ5IGRpZmZlcmVudA0KZnJvbSB0aGlzIGNyb3dkIGFuZCB0aGUg
cHVibGljIGluIGdlbmVyYWwgaWYgSSBtYW5kYXRlZCBhZGRpdGlvbmFsDQpzb2Z0d2FyZS4NCj4N
Cj5GaW5hbGx5LCBJIGFtIGFzc3VtaW5nIHRoYXQgaW4gbGFyZ2UgZGVwbG95bWVudHMgdGhlcmUg
d2lsbCBiZSBtYW55DQo+V0xBTi1HV3MgLSBlYWNoIGFzc29jaWF0ZWQgd2l0aCBwb3RlbnRpYWxs
eSBtYW55IEFQcy4NCltqam1iXSB5ZXMgbWFueSBBUHMgdG8gYSBzaW5nbGUgV0xBTi1HVy4gIE11
bHRpcGxlIFdMQU4tR1dzLiAgQW4gQVAgd2lsbA0KYXNzb2NpYXRlIHRvIG9uZSBhbmQgb25seSBv
bmUgV0xBTi1HVy4NCj5CdXQsIHRoZXJlDQo+aXMgbm8gZGlzY3Vzc2lvbiBvZiBob3cgbmV0d29y
a2luZyBiZXR3ZWVuIHRoZSBXTEFOLUdXcyB3aWxsDQo+b2NjdXIgLSBlc3BlY2lhbGx5IGlmIFVF
cyBhcmUgYWxsb3dlZCB0byByb2FtIGJldHdlZW4gZGlmZmVyZW50DQo+V0xBTi1HV3MuIA0KW2pq
bWJdIGludGVybmV0d29ya2luZyBiZXR3ZWVuIFVFcyBzZXJ2ZWQgYnkgZGlmZmVyZW50IFdMQU4t
R1cgd2lsbCBiZQ0KZG9uZSB1c2luZyBsYXllciAzIHJvdXRpbmcgYXMgd2Uga25vdyBpdCB0b2Rh
eSwgd2hlcmUgYXBwbGljYWJsZS4NCj5UaGlzIGlzIGNvdmVyZWQgaW4gZGV0YWlsIGluIEFFUk8g
YW5kIG90aGVyIGFwcHJvYWNoZXMuDQpbamptYl0gSSBhbSBzdXJlIEFFUk8gaXMgYSBncmVhdCBz
b2x1dGlvbiBmb3IgeW91ciB1c2UgY2FzZSwgaG93ZXZlciwNCnRoZXJlIGlzIGxpdHRsZSB0byBu
byBvdmVybGFwIGZvciBvdXIgZGVwbG95bWVudCBvZiBJUHY2IGZvciBjb21tdW5pdHkNCldpLUZp
Lg0KPg0KPlRoYW5rcyAtIEZyZWQNCj5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+DQo+DQo+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBt
YWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdjZvcHMNCj4NCg0K


From nobody Fri Oct 23 17:46:38 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3D1ACE41 for ; Fri, 23 Oct 2015 17:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqn64a_HrQ0p for ; Fri, 23 Oct 2015 17:46:34 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61931ACDDE for ; Fri, 23 Oct 2015 17:46:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9O0kXN9008049; Fri, 23 Oct 2015 19:46:33 -0500
Received: from XCH-BLV-401.nw.nos.boeing.com (xch-blv-401.nw.nos.boeing.com [130.247.25.18]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9O0kPtd007435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 23 Oct 2015 19:46:25 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.5]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 17:46:24 -0700
From: "Templin, Fred L" 
To: "Brzozowski, John" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDWwH/+MZsnq7pUCTitCxpFGwKp55fxmA///FwdCAAPJQgP//jjZQ
Date: Sat, 24 Oct 2015 00:46:23 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2E2BD@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com>  <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Oct 2015 00:46:37 -0000

SGkgSm9obiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcnpvem93
c2tpLCBKb2huIFttYWlsdG86Sm9obl9Ccnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tXQ0KPiBT
ZW50OiBGcmlkYXksIE9jdG9iZXIgMjMsIDIwMTUgNDo1NiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJl
ZCBMOyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rp
b246IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0K
PiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIDx2Nm9w
cy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRnJlZCBUZW1wbGluDQo+IDxGcmVkLkwu
VGVtcGxpbkBib2VpbmcuY29tPg0KPiBEYXRlOiBGcmlkYXksIE9jdG9iZXIgMjMsIDIwMTUgYXQg
MTI6NTUNCj4gVG86IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt2Nm9w
c10gRndkOiBJLUQgQWN0aW9uOg0KPiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp
eC1wZXItaG9zdC0wMC50eHQNCj4gDQo+ID5IaSwNCj4gPg0KPiA+SSByZWFkIHRoaXMgZHJhZnQg
aW4gbW9yZSBkZXRhaWwsIGFuZCBJIGFtIGxlZnQgd2l0aCBtYW55IHF1ZXN0aW9ucy4NCj4gPkZp
cnN0LA0KPiA+SSBkb24ndCBzZWUgYW55IHByb3Zpc2lvbnMgZm9yIG1vYmlsaXR5IG9yIHJvdXRl
IG9wdGltaXphdGlvbi4gSW4gdGVybXMgb2YNCj4gPm1vYmlsaXR5LCB0aGUgVUUncyBJUHY2IHBy
ZWZpeCBhcHBlYXJzIHRvIGJlIHRldGhlcmVkIHRvIHRoZSBjdXJyZW50IEFQDQo+ID5wb2ludCBh
bmQgY2Fubm90IG1vdmUgd2l0aCB0aGUgVUUgYXMgaXQgbW92ZXMgZnJvbSBBUCB0byBBUC4NCj4g
W2pqbWJdIGFzIHRoZSBkcmFmdCBzaXRlcyBBUHMgYXJlIGxhcmdlbHkgdHJhbnNwYXJlbnQuICBN
b2JpbGl0eSBpcw0KPiBzdXBwb3J0IGJldHdlZW4gQXBzDQoNClRoZSBkcmFmdCBkb2Vzbid0IHNh
eSBob3cgdGhhdCBpcyBkb25lOyBpdCBqdXN0IHNheXMgdGhhdCB0aGVyZSBpcyBhIEdSRQ0KdHVu
bmVsIGJldHdlZW4gdGhlIEFQIGFuZCB0aGUgV0xBTi1HVy4gV2lyZWxlc3Mgc29sdXRpb25zIG5l
ZWQNCnRvIHNwZWFrIHRvIG1vYmlsaXR5IGFzIGEgbWF0dGVyIG9mIGNvdXJzZS4gVW5sZXNzIHdl
IGFyZSB0cnlpbmcgdG8NCmZ1cnRoZXIgZW5nZW5kZXIgYSBwb3B1bGF0aW9uIG9mIGNvdWNoIHBv
dGF0b2VzIHRoYXQgbmV2ZXIgbGVhdmUNCnRoZWlyIG93biBsaXZpbmcgcm9vbXMuDQoNCj4gaG93
ZXZlciwgV0xBTi1HVyB0byBXTEFOLUdXIHdpbGwgcmVzdWx0IGluIGEgcmVudW1iZXJpbmcuIA0K
DQpSb2FtaW5nIGJldHdlZW4gV0xBTi1HV3MgZG9lcyBub3QgbmVlZCB0byByZXN1bHQgaW4gYQ0K
cmVudW1iZXJpbmcgZXZlbnQsIHdoaWNoIHdvdWxkIGJlIHZlcnkgdW5mb3J0dW5hdGUuDQpSZW51
bWJlcmluZyBuZXZlciBoYXBwZW5zIHdpdGggQUVSTywgYW5kIFVFcyBnZXQgdG8NCnVzZSB0aGVp
ciBzYW1lIGRlbGVnYXRlZCBwcmVmaXhlcyB3aGVyZXZlciB0aGV5IGhhcHBlbg0KdG8gcG9wIHVw
IGluIHRoZSBuZXR3b3JrLg0KDQo+IEFzIGZhciBhcyByb3V0ZSBvcHRpbWl6YXRpb24gaXMgY29u
Y2VybmVkIEkgYW0gbm90IHN1cmUgaG93DQo+IGVsc2Ugd2UgY2FuIG9wdGltaXplIHJvdXRpbmcg
dG8gYSBkZWZhdWx0IGdhdGV3YXkuDQoNClJvdXRlIG9wdGltaXphdGlvbiBpcyBicm9rZXJlZCBi
eSB0aGUgbmV0d29yayBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpjbGllbnRzIGFuZCBhbHNvIHRv
IHJlbW92ZSB0cmFmZmljIGNvbmNlbnRyYXRpb24gZnJvbSBwZXJmb3JtYW5jZQ0KY3JpdGljYWwg
bmV0d29yayBlbGVtZW50cy4gQUVSTyBzcGVjaWZpZXMgYSBtZWFucyBmb3IgY2xpZW50IHRvIGNs
aWVudA0Kcm91dGUgb3B0aW1pemF0aW9uIHRoYXQgcmVtb3ZlcyB0aGUgZGVmYXVsdCBnYXRld2F5
IGZyb20gdGhlIHBhdGguDQoNCj4gPkluIHRlcm1zDQo+ID5vZiByb3V0ZSBvcHRpbWl6YXRpb24s
IGV2ZXJ5dGhpbmcgbmVlZHMgdG8gZ28gdGhyb3VnaCB0aGUgV0xBTi1HVw0KPiA+YW5kIGNhbm5v
dCBnbyBkaXJlY3RseSBmcm9tIFVFIHRvIFVFIGV2ZW4gaWYgdGhlIHR3byBVRXMgYXJlIHJpZ2h0
IG5leHQNCj4gPnRvIG9uZSBhbm90aGVyLg0KPiBbamptYl0gdGhpcyBpcyBhY3R1YWxseSBkZWxp
YmVyYXRlIGFuZCBjb25zaWRlcmVkIGEgZmVhdHVyZS4gIEFsc28gbm90ZQ0KPiB0aGUgTCBiaXQg
aXMgc2V0IHRvIDAgdG8gZnVydGhlciBlbmNvdXJhZ2UgdGhlIHVzZSBvZiB0aGUgZGVmYXVsdCBn
YXRld2F5DQo+IChXTEFOLUdXKSB0byBmYWNpbGl0YXRlIG5vZGUgdG8gSW50ZXJuZXQgYW5kIG5v
ZGUgdG8gbm9kZSBjb21tdW5pY2F0aW9ucy4NCg0KQUVSTyBwcm92aWRlcyByb3V0ZSBvcHRpbWl6
YXRpb24gcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQgYW5kIGJyb2tlcmVkDQpieSB0aGUgbmV0d29y
ay4gVGhlIG5ldHdvcmsgY2FuIGVpdGhlciBwZXJtaXQgb3IgZGVueSByb3V0ZSBvcHRpbWl6YXRp
b24NCmFzIGl0IGlzIGNvbmZpZ3VyZWQgdG8gZG8gc28sIGFuZCBwcm92aWRlcyBhIHRydXN0IGJh
c2lzIGZvciBjbGllbnRzIHRvIGVuZ2FnZQ0KaW4gdGhlIHJvdXRlIG9wdGltaXphdGlvbi4gIChB
bHNvIGNoZWNrIDZyZCB0aGF0IHByb3ZpZGVzIG5hdHVyYWwgcm91dGUNCm9wdGltaXphdGlvbiBh
cyBhIGZ1bmRhbWVudGFsIGFzcGVjdCBvZiBpdHMgZGVzaWduLikgUm91dGUgb3B0aW1pemF0aW9u
DQpvZmZsb2FkcyBwZXJmb3JtYW5jZS1jcml0aWNhbCBpbmZyYXN0cnVjdHVyZSBhbmQgcHJvdmlk
ZXMgYSBiZXR0ZXIgY2xpZW50DQp0byBjbGllbnQgZXhwZXJpZW5jZS4NCg0KPiA+VGhlIGFwcHJv
YWNoIGFsc28gc3RpbGwgcmVxdWlyZXMgdGhlIFVFIHRvIGRvIERBRCBvdmVyIHRoZSBpbnRlcmZh
Y2UgaXQNCj4gPnJlY2VpdmVzIHRoZSBJUHY2IFJBIHdpdGggUElPIGZyb20uDQo+IFtqam1iXSB0
aGlzIGNvdWxkIGNvbmNlaXZhYmx5IGJlIG9taXR0ZWQgb3RoZXIgdGhhbiB0aGUgREFEIGZvciB0
aGUgVUUNCj4gbGluayBsb2NhbCBhZGRyZXNzLiAgUGVyaGFwcyB3ZSBjYW4gb3B0aW1pemUgREFE
IGJ5IHNldHRpbmcgYWRkaXRpb25hbA0KPiBmbGFncyBpbiB0aGUgUkEuDQoNCldoYXQgYWRkaXRp
b25hbCBmbGFncyB3b3VsZCB5b3Ugc2V0IGluIHRoZSBSQSB0aGF0IGFuIHVubW9kaWZpZWQgaG9z
dA0Kd291bGQgYmUgYWJsZSB0byByZWNvZ25pemUgYXMgYSBzaWduYWwgbm90IHRvIGRvIERBRD8N
Cg0KPiA+QXBwcm9hY2hlcyB0aGF0IHByb3Blcmx5IGRlbGVnYXRlDQo+ID5hbiBJUHY2IHByZWZp
eCAoZS5nLiwgREhDUHY2IFBEKSBkbyBub3QgcmVxdWlyZSBEQUQgb3ZlciB0aGUgaW50ZXJmYWNl
DQo+ID50aGUgcHJlZml4IGlzIHJlY2VpdmVkIG9uIGJlY2F1c2UgdGhlIHByZWZpeCBpdHNlbGYg
bXVzdCBub3QgYmUgYXNzaWduZWQNCj4gPnRvIHRoYXQgaW50ZXJmYWNlLg0KPiBbamptYl0gdGhp
cyBpcyB3aGF0IGlzIHBsYW5uZWQgZm9yIHdoZW4vaWYgd2Ugc3VwcG9ydCBQRC4NCg0KUEQgZ2l2
ZXMgdGhlIG5vZGUgYSBwcmVmaXggdGhhdCB0aGUgbmV0d29yayBjZXJ0aWZpZXMgd2lsbCBub3Qg
YmUgZ2l2ZW4NCnRvIGFueSBvdGhlciBub2RlLiBUaGUgcHJlZml4IGlzIG5vdCB0byBiZSBhc3Np
Z25lZCB0byB0aGUgbGluayBvdmVyDQp3aGljaCBpdCB3YXMgcmVjZWl2ZWQsIHNvIHRoZXJlIGlz
IG5vIG5lZWQgdG8gREFEIGZvciBhbnkgb2YgdGhlDQphZGRyZXNzZXMgYXNzaWduZWQgZnJvbSB0
aGUgcHJlZml4LiBBbmQsIHRoZXJlIGNvdWxkIGJlIG1pbGxpb25zDQpvZiBzdWNoIGFkZHJlc3Nl
cy4NCg0KPiA+IEFuZCwgREhDUHY2IFBEIGNsaWVudCBpcyB0cml2aWFsIHRvIGltcGxlbWVudCB0
b2RheQ0KPiA+YW5kIGRvZXMgbm90IG5lZWQgdG8gYmUgcHVzaGVkIGludG8gdGhlIGZhciBkaXN0
YW50IGZ1dHVyZS4NCj4gW2pqbWJdIHRoZSBpbmNyZW1lbnRhbCBuYXR1cmUgb2YgdGhpcyBoYXMg
bm90aGluZyB0byBkbyB3aXRoIHRoZSBjbGllbnQsDQo+IGhhcyB0byBkbyB3aXRoIHR3byB0aGlu
Z3MuICAxKSB3ZSBhcmUgZG9pbmcgdGhpcyBpbmNyZW1lbnRhbGx5IGFuZCAyKSB3ZQ0KPiBuZWVk
IHRvIG1ha2Ugc3VyZSB0aGUgV0xBTi1HVyBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGlzIHVu
aXZlcnNhbGx5IHRvDQo+IGF2b2lkIHBhcnRpYWwgc3VwcG9ydC4NCg0KSSBkb24ndCB1bmRlcnN0
YW5kIHlvdXIgbWVhbmluZyBoZXJlLCBidXQgd2hhdCBtYXR0ZXJzIGlzIGEgcm9idXN0DQphbmQg
YWNjZXB0YWJsZSBlbmQgdXNlciBleHBlcmllbmNlIHRocm91Z2hvdXQgYWxsIHJvbGxvdXQgcGhh
c2VzLg0KDQo+ID5UaGUgYXBwcm9hY2ggaXMgYWxzbyBhIG5ldHdvcmstYmFzZWQgYXBwcm9hY2gg
dXNpbmcgaW4tdGhlLW5ldHdvcmsNCj4gPnR1bm5lbGluZywgYnV0IHRoZXJlIGFyZSBhbHJlYWR5
IG1hbnkgc29sdXRpb25zIHRoYXQgZG8gdGhpcyBpbmNsdWRpbmcNCj4gPlBNSVB2NiwgUHJveHkg
QUVSTywgYW5kIENBUFdBUC4gQSBiZXR0ZXIgbW9iaWxpdHkgYW5kIHJvdXRlDQo+ID5vcHRpbWl6
YXRpb24gZXhwZXJpZW5jZSBpcyBhbHNvIHBvc3NpYmxlIHdoZW4gdGhlIGVuY2Fwc3VsYXRpb24g
aXMNCj4gPnJlbW92ZWQgZnJvbSB0aGUgbmV0d29yayBhbmQgcGxhY2VkIG9uIHRoZSBVRSBzdWNo
IGFzIGZvciBjbGllbnQNCj4gPk1JUHY2IGFuZCBjbGllbnQgQUVSTy4gRm9yIEFFUk8gaW4gcGFy
dGljdWxhciwgaXQgaXMgYSB2ZXJ5IHNpbXBsZSBhcHANCj4gPnRoYXQgcnVucyBvbiB0aGUgVUUg
dGhhdCBjYW4gYmUgZG93bmxvYWRlZCBhbmQgaW52b2tlZCBpbiBhIHNpbWlsYXINCj4gPmZhc2hp
b24gYXMgZm9yIFZQTiBjbGllbnRzIGxpa2UgT3BlblZQTi4NCj4gW2pqbWJdIEkgaGF2ZSBubyBj
b250cm9sIG92ZXIgdGhlIGNsaWVudHMgYXMgc3VjaCBJIGNhbiBub3QgZW5mb3JjZSB0aGUNCj4g
aW5zdGFsbGF0aW9uIG9mIHN1Y2ggc29mdHdhcmUuICBJIGFtIHF1aXRlIEkgd291bGQgZ2V0IGEg
dmVyeSBkaWZmZXJlbnQNCj4gZnJvbSB0aGlzIGNyb3dkIGFuZCB0aGUgcHVibGljIGluIGdlbmVy
YWwgaWYgSSBtYW5kYXRlZCBhZGRpdGlvbmFsDQo+IHNvZnR3YXJlLg0KDQpJZiB5b3UgZG9uJ3Qg
d2FudCB0byBjb250cm9sIHRoZSBjbGllbnRzLCB0aGVuIGhhdmUgYSBsb29rIGF0IFBNSVB2NiwN
ClByb3h5IEFFUk8gYW5kL29yIENBUFdBUC4NCg0KPiA+RmluYWxseSwgSSBhbSBhc3N1bWluZyB0
aGF0IGluIGxhcmdlIGRlcGxveW1lbnRzIHRoZXJlIHdpbGwgYmUgbWFueQ0KPiA+V0xBTi1HV3Mg
LSBlYWNoIGFzc29jaWF0ZWQgd2l0aCBwb3RlbnRpYWxseSBtYW55IEFQcy4NCj4gW2pqbWJdIHll
cyBtYW55IEFQcyB0byBhIHNpbmdsZSBXTEFOLUdXLiAgTXVsdGlwbGUgV0xBTi1HV3MuICBBbiBB
UCB3aWxsDQo+IGFzc29jaWF0ZSB0byBvbmUgYW5kIG9ubHkgb25lIFdMQU4tR1cuDQoNClRoYXQg
aXMgZmluZSwgYnV0IHlvdSBzdGlsbCBuZWVkIHRvIGNhcmUgZm9yIG1vYmlsZXMgdGhhdCBqdW1w
IGZyb20gQVANCnRvIEFQIGFuZCBpbiB0aGUgcHJvY2VzcyBtYXkgcm9hbSBiZXR3ZWVuIFdMQU4t
R1dzLiBUaGF0DQpyZXF1aXJlcyBhIG1vYmlsaXR5IG1hbmFnZW1lbnQgc2NoZW1lIHRoYXQgSSBk
byBub3Qgc2VlIGluIHRoZSBkcmFmdC4NCg0KPiA+QnV0LCB0aGVyZQ0KPiA+aXMgbm8gZGlzY3Vz
c2lvbiBvZiBob3cgbmV0d29ya2luZyBiZXR3ZWVuIHRoZSBXTEFOLUdXcyB3aWxsDQo+ID5vY2N1
ciAtIGVzcGVjaWFsbHkgaWYgVUVzIGFyZSBhbGxvd2VkIHRvIHJvYW0gYmV0d2VlbiBkaWZmZXJl
bnQNCj4gPldMQU4tR1dzLg0KPiBbamptYl0gaW50ZXJuZXR3b3JraW5nIGJldHdlZW4gVUVzIHNl
cnZlZCBieSBkaWZmZXJlbnQgV0xBTi1HVyB3aWxsIGJlDQo+IGRvbmUgdXNpbmcgbGF5ZXIgMyBy
b3V0aW5nIGFzIHdlIGtub3cgaXQgdG9kYXksIHdoZXJlIGFwcGxpY2FibGUuDQoNCkxheWVyIDMg
cm91dGluZyBob3csIHRob3VnaD8gSWYgeW91IGluamVjdCBtaWxsaW9ucyB1cG9uIG1pbGxpb25z
IG9mDQpVRSBwcmVmaXhlcyBpbnRvIHRoZSByb3V0aW5nIHN5c3RlbSBpdCBpcyBhIHJlY2lwZSBm
b3IgZGlzYXN0ZXIuIFVzaW5nDQphIHByaXZhdGUgQkdQIGluc3RhbmNlIGFzIHNwZWNpZmllZCBp
biBBRVJPIGlzIGEgd2F5IHRvIGF2b2lkIHRoaXMuDQogDQo+ID5UaGlzIGlzIGNvdmVyZWQgaW4g
ZGV0YWlsIGluIEFFUk8gYW5kIG90aGVyIGFwcHJvYWNoZXMuDQo+IFtqam1iXSBJIGFtIHN1cmUg
QUVSTyBpcyBhIGdyZWF0IHNvbHV0aW9uIGZvciB5b3VyIHVzZSBjYXNlLCBob3dldmVyLA0KPiB0
aGVyZSBpcyBsaXR0bGUgdG8gbm8gb3ZlcmxhcCBmb3Igb3VyIGRlcGxveW1lbnQgb2YgSVB2NiBm
b3IgY29tbXVuaXR5DQo+IFdpLUZpLg0KDQpNYW55IEFFUk8gdXNlIGNhc2VzIGFyZSBleGFtaW5l
ZCBpbiBSRkM2MTM5LCBidXQgdGhlIGxpc3QgdGhlcmUNCmlzIG5vdCBleGhhdXN0aXZlLiBUaGUg
dXNlIGNhc2UgZGVzY3JpYmVkIGluIHlvdXIgZHJhZnQgaXMgaW5kZWVkDQphbm90aGVyIHVzZSBj
YXNlIGZvciBBRVJPLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBiZW9pbmcuY29t
DQoNCj4gPlRoYW5rcyAtIEZyZWQNCj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0K
PiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+djZvcHMgbWFpbGluZyBsaXN0DQo+ID52Nm9wc0BpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+DQoNCg==


From nobody Fri Oct 23 19:09:30 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F081B2EC9 for ; Fri, 23 Oct 2015 19:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqOTYghVmEUi for ; Fri, 23 Oct 2015 19:09:25 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98291B2EC8 for ; Fri, 23 Oct 2015 19:09:24 -0700 (PDT)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.306.13; Sat, 24 Oct 2015 02:09:03 +0000
Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0306.003; Sat, 24 Oct 2015 02:09:03 +0000
From: "Metzler, Dan J" 
To: Nikos Mavrogiannopoulos 
Thread-Topic: [v6ops] preventing denial of service in IPv6
Thread-Index: AQHRDXllPkT3U56Yb0q2IqTxb+Em45542yXQgABYS4CAAICuEA==
Date: Sat, 24 Oct 2015 02:09:02 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dan-metzler@uiowa.edu; 
x-originating-ip: [66.43.218.133]
x-microsoft-exchange-diagnostics: 1; CO2PR04MB585; 5:JhkZ7sdedy9bwXaa6Nu/XHNLtKzA5I7fZ9Vt/dDLe/Mx/oZmDKboAOk3j9fEUaVzgo70BPYTjcwa0f3bo4a/dXdFBS0k32a+J1JO1I8o+iIVtHqQE7Un7yp+2sWZxpDLaDclvHhmjOIKtU/Hexy6rA==; 24:r4/Ujieg4F6d749LrGZ5/vPa8Zycxxi82tfITgzE3PKojKKOnAiqINgjgbfGxHlSgWeaftV/KRfAxyeAiavOYlgk0c11VZd67L6AnfdLIuk=; 20:7y6Tnv4NyHyentEj17Rw/PI3wgWFWLgpMDQMlE8fT4skcAGDkLhv0p6oG/y03rPO8tE39Ak+i4Ar++XM1aDxWw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(86304536128247);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:CO2PR04MB585; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB585; 
x-forefront-prvs: 073966E86B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(52314003)(13464003)(199003)(377454003)(24454002)(105586002)(97736004)(74316001)(77096005)(66066001)(76576001)(2950100001)(81156007)(90282001)(5004730100002)(5007970100001)(102836002)(2900100001)(11100500001)(19580395003)(110136002)(19580405001)(76176999)(54356999)(101416001)(5001960100002)(33656002)(50986999)(88552001)(106116001)(189998001)(99286002)(10400500002)(89122001)(5003600100002)(40100003)(86362001)(5002640100001)(5008740100001)(92566002)(106356001)(75432002)(122556002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: uiowa.edu does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2015 02:09:02.7376 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Oct 2015 02:09:28 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbi5tYXZyb2dpYW5ub3Bv
dWxvc0BnbWFpbC5jb20NCj4gW21haWx0bzpuLm1hdnJvZ2lhbm5vcG91bG9zQGdtYWlsLmNvbV0g
T24gQmVoYWxmIE9mIE5pa29zDQo+IE1hdnJvZ2lhbm5vcG91bG9zDQo+IFNlbnQ6IEZyaWRheSwg
T2N0b2JlciAyMywgMjAxNSAxMDoyNyBBTQ0KPiBUbzogTWV0emxlciwgRGFuIEogPGRhbi1tZXR6
bGVyQHVpb3dhLmVkdT4NCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZv
cHNdIHByZXZlbnRpbmcgZGVuaWFsIG9mIHNlcnZpY2UgaW4gSVB2Ng0KPiANCj4gT24gRnJpLCBP
Y3QgMjMsIDIwMTUgYXQgMzoxOCBQTSwgTWV0emxlciwgRGFuIEogPGRhbi1tZXR6bGVyQHVpb3dh
LmVkdT4NCj4gd3JvdGU6DQo+IA0KPiA+PiBTbyBvbmUgd291bGQgZXhwZWN0IHNvZnR3YXJlIHRv
IGJsYWNrbGlzdCB3aG9sZSByYW5nZXMgb2YgbmV0d29ya3MsDQo+ID4+IGUuZy4sIGEgLzY0IG9y
IC80OCBvbmNlIGZldyBJUHMgdmlvbGF0ZSBzb21lIG9mIGl0cyAiZGV0ZWN0aW9uDQo+ID4+IHBy
b3BlcnRpZXMiLg0KPiA+IFtESk1dIEkgd291bGQgdGhpbmsgb25lIHdvdWxkIGV4cGVjdCBzb2Z0
d2FyZSB0byBibG9jayBhIHNpbmdsZSBJUCBhZGRyZXNzDQo+IGZvciBJUHY2IGluIHRoZSBzYW1l
IHNjZW5hcmlvcyB3aGVyZSB0aGF0IHdvdWxkIGhhcHBlbiBpbiBJUHY0Lg0KPiA+IEdyYW50ZWQg
SVB2NiBtYWtlcyBpdCBhIGJpdCBlYXNpZXIgdG8gcmVwZWF0ZWRseSBjaGFuZ2UgYWRkcmVzc2Vz
LCBwdXJlbHkNCj4gZnJvbSBhbiBhdmFpbGFiaWxpdHkgc3RhbmRwb2ludCwgaW4gdGhlIHNhbWUg
d2F5IHRoYXQgaXQgbWFrZXMgaXQgYSBiaXQgaGFyZGVyDQo+IHRvIHNjYW4gYWRkcmVzc2VzLg0K
PiA+IEkgd291bGQgZXhwZWN0IGJsb2NraW5nIGEgLzY0IHRvIGJlIHRoZSBlcXVpdmFsZW50IG9m
IGJsb2NraW5nIGEgc3VibmV0IGluDQo+IElQdjQsIGJlY2F1c2UgaXQgaXMuDQo+IA0KPiBUaGVu
IGEgc2luZ2xlIHVzZXIgY2FuIGV4aGF1c3QgYSBzZXJ2ZXIncyByZXNvdXJjZXMgYnkgc2ltcGx5
IGF0dGFja2luZyB0aGUNCj4gc2VydmVyIHdpdGggYWxsIGhpcyBhdmFpbGFibGUgYWRkcmVzc2Vz
Lg0KW0RKTV0gVGhhdCdzIHRydWUgb24gSVB2NCBhcyB3ZWxsIGFzIGl0IGlzIG9uIElQdjYsIGFu
ZCBubyBtb3JlIHNvIG9uIElQdjYuICBTbywgdG8gdGhlIGV4dGVudCB0aGF0IGEgc2luZ2xlIHVz
ZXIgY2FuIERPUyBhdHRhY2sgYSBzZXJ2ZXIgb3ZlciB3aGF0ZXZlciBiYW5kd2lkdGggaGUgaGFz
IHRocm91Z2ggdGhlIElTUC4uLg0KSG93ZXZlciB0aGUgbnVtYmVyIG9mIHBvdGVudGlhbCBhZGRy
ZXNzZXMgYXZhaWxhYmxlIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGNhcGFjaXR5IHRvIERP
UyBhdHRhY2sgYSBzZXJ2ZXIuDQpUaGF0IGRlcGVuZHMgbW9yZSBvbiBDUFUsIHRoZSBudW1iZXIg
b2YgbmV0d29yayBpbnRlcmZhY2VzIG9uIHRoZSBhdHRhY2tpbmcgc3lzdGVtLg0KDQpUaGUgbWFp
biBwb2ludCBpcyB0aGF0IDJeNjQgYWRkcmVzc2VzIGRvZXMgbm90IGVxdWF0ZSBtb3JlIGF0dGFj
a2luZyBzeXN0ZW1zLg0KT25lIGNvdWxkIGFyZ3VlIHRoYXQgaXQgbWFrZXMgaXQgZWFzaWVyIHRv
IGhpZGUsIGJ1dCBpbiBtb3N0IGNhc2VzLCBJIHdvdWxkIHRoaW5rIHRoYXQnZCBiZSBmYWlybHkg
d2VhayBhcmd1bWVudC4NClRoZXkgYXJlIGFsbCBzdGlsbCBjb21pbmcgZnJvbSB0aGUgc2FtZSAv
NjQsIGFuZCBzdGlsbCBoYXZlIHRoZSBzYW1lIHNpZ25hdHVyZS4NCg0KPiANCj4gPj5HaXZlbiBy
ZWNvbW1lbmRhdGlvbnMgbGlrZSBSRkM2MTY0IHdoaWNoICByZWNvbW1lbmQgLzEyNyBmb3IgUHRQ
IGxpbmtzDQo+ID4+KHdoaWNoIGNhbiBiZSBhIHVzZXIgVlBOIGxpbmspLCBhbnkgaGV1cmlzdGlj
ICB0aGF0IHdpbGwgYmFuIHdob2xlDQo+ID4+bmV0d29ya3MgbG9va3MgbW9yZSBsaWtlIGEgdmVz
c2VsIHRvIHBlcmZvcm0gYW5vdGhlciAgZGVuaWFsIG9mDQo+ID4+c2VydmljZSAoZS5nLiwgZGVu
eWluZyBzb21lIHVzZXIgYWNjZXNzIHRvIGEgc2VydmVyKSwgcmF0aGVyIHRoYW4gYQ0KPiA+PnNv
bHV0aW9uIHRvIHRoZSBvcmlnaW5hbCBkZW5pYWwgb2Ygc2VydmljZS4NCj4gPiBbREpNXSBBYnNv
bHV0ZSBhZ3JlZW1lbnQgaGVyZSwgYXMgaXMgdGhlIGNhc2Ugd2l0aCBJUHY0Lg0KPiA+IEEgYmV0
dGVyIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGludGVsbGlnZW50bHkgYW5kIGR5bmFtaWNhbGx5IGJs
b2NrIG9mZmVuZGluZw0KPiBpbmRpdmlkdWFsIGFkZHJlc3Nlcywgb3Igc2V0cyBvZiBhZGRyZXNz
ZXMsIGJhc2VkIG9mZiBvZiBtb3JlIGluZm9ybWF0aW9uDQo+IHRoYW4gYSBzaW1wbGUgYXNzdW1w
dGlvbiB0aGF0IGlmIHRoZXJlIGlzIG9uZSBvZmZlbmRlciBvbiBhIHN1Ym5ldCwgdGhlbiB0aGV5
DQo+IGFsbCBtdXN0IGJlIG9mZmVuZGVycy4NCj4gPiBPZiBjb3Vyc2Ugb25lIG1pZ2h0IHdhbnQg
dG8gYmxvY2sgYSB3aG9sZSBzdWJuZXQgb25jZSBzb21lIHNvcnQgb2YNCj4gY3JpdGljYWwgdGhy
ZXNob2xkIHdhcyByZWFjaGVkIG9mIGEgY2VydGFpbiBudW1iZXIgb2Ygb2ZmZW5kaW5nIElQcyBv
biB0aGF0DQo+IHN1Ym5ldC4NCj4gPg0KPiA+PiBUaGlzIGlzIGZ1cnRoZXIgcmVpbmZvcmNlZCBi
eSB0aGUgZmFjdCB0aGF0IHNtYWxsZXIgdGhhbiAvNjQgbmV0d29ya3MNCj4gPj4gYXJlIG9jY2Fz
aW9uYWxseSBoYW5kZWQgb3V0IGJ5IElTUHMgdG8gdGhlaXIgdXNlcnMuDQo+ID4+DQo+ID4+IEFy
ZSB0aGVyZSBhbnkgcmVjb21tZW5kYXRpb25zIGZvciBwcm90ZWN0aW5nIHNlcnZlcnMgZnJvbSB0
aGUgSVB2Ng0KPiA+PiBhZGRyZXNzIHByb2xpZmVyYXRpb24/DQo+ID4gW0RKTV0gQWRkcmVzcyBw
cm9saWZlcmF0aW9uIGRvZXNuJ3Qgc2VlbSBsaWtlIGEgdnVsbmVyYWJpbGl0eSB0byBwcm90ZWN0
DQo+IGFnYWluc3QuDQo+ID4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGRldmlhdGluZyBmcm9tIHRo
ZSBwcm9ibGVtOyB0aGUgRE9TIGF0dGFjay4NCj4gPiBET1MgaXMgbGFyZ2VseSBhIGdhbWUgb2Yg
cmVzb3VyY2VzOyBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIGEgbGFyZ2UgZW5vdWdoDQo+IHBvb2wg
b2YgcmVzb3VyY2VzLCB0aGF0IHBhcnRpY2lwYXRlIGluIGEgRE9TIGF0dGFjaywgc28gYXMgdG8g
ZXhjZWVkIHRoZQ0KPiBjYXBhY2l0eSBvZiB0aGUgZmluaXRlIHJlc291cmNlcyBkZWRpY2F0ZWQg
dG8gaGFuZGxpbmcgYSBsb2FkLiAgVGhlIGZhY3QgdGhhdA0KPiB0aGUgcmVzb3VyY2VzIGluc3Rp
Z2F0aW5nIHRoZSBhdHRhY2sgaGFzIGEgbGFyZ2VyIHBvb2wgb2YgYWRkcmVzc2VzLCB0byB1c2Us
DQo+IGRvZXNuJ3QgY2hhbmdlIHRoZSBhbW91bnQgb2YgcmVzb3VyY2VzIHBhcnRpY2lwYXRpbmcg
aW4gdGhlIGF0dGFjaywgb3IgdGhlDQo+IG51bWJlciBvZiBhZGRyZXNzZXMgaW4gdXNlIGF0IGEg
Z2l2ZW4gcG9pbnQgaW4gdGltZS4NCj4gPiBBbHNvLCB0aGUgbGlrZWxpaG9vZCB0aGF0IGEgRE9T
IGF0dGFjayB3b3VsZCBiZSAgc291cmNlZCBlbnRpcmVseSBmcm9tDQo+ID4gYSBzaW5nbGUgc3Vi
bmV0IHNlZW1zIG1vcmUgYW5kIG1vcmUgb2YgYW4gZWRnZSBjYXNlIGFzIHRpbWUgZ29lcyBvbi4N
Cj4gPiAoSWYgaXQgd2VyZSBvbmx5IHRoYXQgZWFzeS4pDQo+IA0KPiBJUHY2IG1ha2VzIHRoYXQg
ZWFzeS4gSW4gSVB2NCBET1MgYXR0YWNrcyBkb24ndCBjb21lIGZyb20gYSBzaW5nbGUgc3VibmV0
DQo+IGJlY2F1c2UgaXQgaXMgZXhwZW5zaXZlIHRvIG9idGFpbiBjb250cm9sIG9mIGEgYmlnIHN1
Ym5ldC4gSW4NCj4gSVB2NiB5b3UgZ2V0IDJeNjQgYWRkcmVzc2VzIGp1c3QgbGlrZSB0aGF0Lg0K
DQoNCltESk1dIEkgZG9uJ3QgdGhpbmsgSSBhZ3JlZSB3aXRoIHRoaXMgcHJlbWlzZS4gIElQdjQg
RE9TIGF0dGFja3MsIGluIG15IG9waW5pb24sIHR5cGljYWxseSBkb24ndCBjb21lIGZyb20gYSBz
aW5nbGUgc3VibmV0IGJlY2F1c2UgaXQgaXNuJ3QgaGVscGZ1bCB0byB0aGUgYXR0YWNrLiAgVGhl
IG1vcmUgZGlzdHJpYnV0ZWQsIGFuZCBzcHJlYWQgb3V0IGFjcm9zcyBkaWZmZXJlbnQgc3VibmV0
cywgdGhlIGJldHRlci4NCg0KSWYgeW91IGhhdmUgYSBzaW5nbGUgc3VibmV0IGZ1bGwgb2YgMjUw
IGNvbXB1dGVycyB0byBiZSB1c2VkIGluIGFuIGF0dGFjay4uLg0KMSkgVGhleSBhcmUgYWxsIGNv
bWluZyBmcm9tIHRoZSBzYW1lIHN1Ym5ldCwgYW5kIHRoYXQncyBmYWlybHkgdHJpdmlhbCB0byBi
bG9jay4gIChFdmVuIGVhc2llciB0byBkZXRlY3QgaWYgb25lIGNhbiBhc3N1bWUgdGhhdCBldmVy
eW9uZSB1c2VzIC82NHMsIHdoaWNoIGxpa2VseSBwZW9wbGUgd2lsbCBkbyBhbnl3YXksIHJlZ2Fy
ZGxlc3Mgb2YgaG93IHNtYWxsIHlvdSB0cnkgdG8gbGltaXQgYWRkcmVzcyBzcGFjZSBpbiBhY3R1
YWxpdHkuKQ0KMikgMjUwIGNvbXB1dGVycyBvbiB0aGUgc2FtZSBzdWJuZXQgYXJlIHJlYWxseSB0
aGUgc2FtZSAyNTAgaG9zdHMgd2hldGhlciB0aGV5IHVzZSBJUHY0IG9yIElQdjYuICBBIGdyZWF0
ZXIgcG9vbCBvZiBhZGRyZXNzZXMgZG9lcyBub3QgaW5jcmVhc2UgdGhlIG51bWJlciBvZiBpbnRl
cmZhY2VzIG9uIHRoZSBuZXR3b3JrLCBvciB0aGUgbnVtYmVyIG9mIGNvbXB1dGUgcmVzb3VyY2Vz
IGludm9sdmVkIGluIHRoZSBhdHRhY2suIA0KMykgQmFkIGd1eXMgaGF2ZSBub3RoaW5nIHRvIGdh
aW4gYnkgYXR0ZW1wdGluZyB0byBoYXZlIGFsbCBvZiB0aGVpciBhdHRhY2tlcnMgb24gYSBzaW5n
bGUgc3VibmV0LiAgSXQgbGltaXRzIHRoZWlyIGJhbmR3aWR0aCByZWxhdGl2ZSB0byBhIGRpc3Ry
aWJ1dGVkIGF0dGFjay4NCg0KPiANCj4gPj4gSWYgbm90LCBhcmUgdGhlcmUgYW55IGNvbnZlbnRp
b25zIGZvciBJUHY2IGFkZHJlc3MgYXNzaWdubWVudCB0bw0KPiA+PiBlbmQtdXNlcnM/DQo+ID4g
W0RKTV0gT3V0c2lkZSBvZiB0aGUgdHlwaWNhbCBESENQdjYgYW5kIFNMQUFDPw0KPiANCj4gQ291
bGQgeW91IGVsYWJvcmF0ZSB3aGF0IG9uIHRoYXQ/IEkga25vdyB0aGF0IFNMQUFDIHJlcXVpcmVz
IC82NCB0bw0KPiBvcGVyYXRlLCBidXQgSSdtIG5vdCBhd2FyZSBvZiBhbnkgY29udmVudGlvbnMg
Zm9yIERIQ1B2Ni4NCltESk1dICANCkRIQ1B2NiBTdGF0ZWxlc3MgLSBzYW1lIGFzIFNMQUFDLg0K
REhDUHY2IFN0YXRlZnVsIC0gSSB0aGluayB0aGUgImNvbnZlbnRpb24iIGlzIHN0aWxsIC82NCBm
b3IgZW5kIHVzZXIgbmV0cyBiZWNhdXNlLCB3ZWxsLi4uIGl0IGlzIElQdjYsIGJ1dCB5b3UgY291
bGQgdGhlb3JldGljYWxseSBtYWtlIGl0IHNtYWxsZXIgKHByZWZpeCBsYXJnZXIpLCBpZiB0aGF0
J3Mgd2hhdCB5b3UncmUgYWZ0ZXIsIGFuZCB5b3UncmUgd2lsbGluZyB0byBkZWFsIHdpdGggYW55
IGlzc3VlcyB0aGF0IG1pZ2h0IGFyaXNlLiAgKE9uZSBvZiB0aGVtIGJlaW5nIGRldmljZXMgdGhh
dCBkb24ndCBzdXBwb3J0IERIQ1B2NiBhbmQgb25seSBzdXBwb3J0IFNMQUFDLikNCg0KDQo+IA0K
PiByZWdhcmRzLA0KPiBOaWtvcw0K


From nobody Sun Oct 25 01:22:00 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA781B2BDA; Sun, 25 Oct 2015 01:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.359
X-Spam-Level: 
X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgg9xv3WD5tH; Sun, 25 Oct 2015 01:21:39 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 DEBF11B2BD7; Sun, 25 Oct 2015 01:21:38 -0700 (PDT)
Received: from [210.160.37.24] (helo=[10.217.244.41]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZqGYY-0003gA-Gp; Sun, 25 Oct 2015 09:21:34 +0100
To: "Brzozowski, John" , v6ops 
References: <20151019195001.22760.70127.idtracker@ietfa.amsl.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <562C398F.5090308@si6networks.com>
Date: Sun, 25 Oct 2015 11:08:15 +0900
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-jjmb-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Oct 2015 08:21:40 -0000

Hi, John (& Gunter),

On 10/20/2015 08:45 AM, Brzozowski, John wrote:
> v6ops,
> 
> Over the past several years there has been some planning for IPv6 support
> for a large scale Wi-Fi deployment.  Turns after sharing some of these
> details with many of your over the past several IETF meetings there is
> interest beyond Wi-Fi for this work.  The I-D has finally been written so
> please send us some feedback on the list.  Assuming we get adequate
> discussion on the list we will request a slot in Yokohama to discuss this
> I-D.

I went through you document, but I'd say that it wasn't that clear
what's the problem statement behind this document.

It would seem to be "we need DHCPv6-PD, but it is not widely supported".
Is that the problem statement? Or am I missing something?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Sun Oct 25 02:21:25 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1E1B2D05 for ; Sun, 25 Oct 2015 02:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.51
X-Spam-Level: 
X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulpj8WE3Fmki for ; Sun, 25 Oct 2015 02:21:22 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918041B2D02 for ; Sun, 25 Oct 2015 02:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3591; q=dns/txt; s=iport; t=1445764882; x=1446974482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fjLtI7S7Bbm/PsdYzxfy17luHxK+0fIGCuNKB9HII48=; b=EugmVATVhIrLahRCaKtDx67Z+5y3dU0RPTuTU6TmNAdu2L5jY9JadGd2 pdGMaqP67L9ImoVLHNhyUcRyN9z8sfKi8WJ9/Jy1CVAMfnE0xphFVWmGq RLmrBNKNE3gIVnwc06zOnvXagVFZdLPRAAKOoGgii3m7toqnkKGIWq6QQ A=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DMAgAinixW/4wNJK1egmlNgUMGvjYOgVqGHQKBGTgUAQEBAQEBAYEKhDIBAQEDAXkFCwIBCAQBEy4yJQIEDgUOiBoIxDgBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYkHgm6FDQeDGoEUAQSWNgGCUIFhiHCcLgEfAUOEA3KGEoEGAQEB
X-IronPort-AV: E=Sophos;i="5.20,195,1444694400";  d="asc'?scan'208,217";a="201384277"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 25 Oct 2015 09:21:21 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9P9LL4H004359 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 25 Oct 2015 09:21:21 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 25 Oct 2015 04:20:59 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Sun, 25 Oct 2015 04:20:59 -0500
From: "Fred Baker (fred)" 
To: Erik Nygren 
Thread-Topic: [v6ops] preventing denial of service in IPv6
Thread-Index: AQHRDwZ14rNGYqj1qU6DiapSwdmuGw==
Date: Sun, 25 Oct 2015 09:20:59 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.64.125]
Content-Type: multipart/signed; boundary="Apple-Mail=_CC66EECF-A17A-433B-BFCA-BDEDF5C7BCDB"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" , "dplonka@akamai.com" 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Oct 2015 09:21:23 -0000

--Apple-Mail=_CC66EECF-A17A-433B-BFCA-BDEDF5C7BCDB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E5CD43B1-1788-4CD2-9E1E-F09A8DEA3AD9"


--Apple-Mail=_E5CD43B1-1788-4CD2-9E1E-F09A8DEA3AD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Oct 23, 2015, at 8:39 AM, Erik Nygren  wrote:
>=20
> My colleagues David Plonka and Arthur Berger are presenting this paper =
at IMC next week
> which is of direct relevance to this topic:

Dave offered to re-present in v6ops at IETF-94, and I took him up on it. =
It seems timely.


--Apple-Mail=_E5CD43B1-1788-4CD2-9E1E-F09A8DEA3AD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Oct 23, 2015, at 8:39 AM, Erik Nygren <erik+ietf@nygren.org> wrote:

My colleagues David =
Plonka and Arthur Berger are presenting this paper at IMC next week
which is of direct =
relevance to this topic:

Dave offered to re-present in v6ops at IETF-94, =
and I took him up on it. It seems timely.

=

--Apple-Mail=_E5CD43B1-1788-4CD2-9E1E-F09A8DEA3AD9--

--Apple-Mail=_CC66EECF-A17A-433B-BFCA-BDEDF5C7BCDB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBViyfEEayAOS/EQ8MAQJivBAAz79HZPMcLZBYwnuFQlqg9rfmPm0s9mCw
+LCer0vs/eeG4lVQZWs6GVBffCAPBJ7gln1BUsVtuElNLW0rBJ/4uWRG/VpQK0xD
6HRyWRPIlO9Kpg9tSwBQe0ril3/rh5/ZtrLh3UBvPnIzl5IjmevmlA5JjEQhQjDw
sEJhqM8kacawse/Eb8XmoLoMV8USHZVmsVDfT6Kyowt29luNsSiBlB0/Xr48bM4W
c4yOwVF4tQYtYzZYizZadnP1+CPBa9IvJT0A2n+tk4YnVdZuRf86vj2CJoLmdY4i
E+8Jim/aAyhX9WoV9f8kCTslTOgjdtN4H0stoCUtROKClKHGF1udXskRHmCId4mL
uqDH5F6rdIgzaYIbI2WjPDRUU3pE1Y9lEOLoIbHpeh+n82OCFwR9gIT28YySxJUU
Bfp32BhsdZSaL9JZB1Zz/ikIJI+yMUaHuox3Yn2RLVzOU+df2zd5Q0ual/xA4c0X
rQ6jWnIVWd5hWvWzpJ9DgSVpTCm6AhncLsHRgG+dxzzhk6rJL6Gqxdmt1w+etkEc
p7a2sxfiqt0m1fk6UvY0siS7ZJrci/xKn/VYa4MzEKLyA4zZLeiQVo9/lbg+DSdv
cZ5ooHvgh5lb8AwpKAFnpwUUuTgz+FT/g/dz5ySMgfE6ReqwJKibAPssltsa6SSn
lbxJBjzkUrE=
=/vOJ
-----END PGP SIGNATURE-----

--Apple-Mail=_CC66EECF-A17A-433B-BFCA-BDEDF5C7BCDB--


From nobody Mon Oct 26 06:05:29 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DCA1B3D84 for ; Mon, 26 Oct 2015 06:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNECfBEtjoGv for ; Mon, 26 Oct 2015 06:05:22 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A356C1B3DA8 for ; Mon, 26 Oct 2015 06:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=904; q=dns/txt; s=iport; t=1445864722; x=1447074322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WI5smIzDpAhHbnnXHLsetcp41ccr0mFKI8w5AniHuKM=; b=WrkCGbFef5yYdt8CYUMiYHldj4TEAi2/q24pwJR5sRpzfUsGvz2NSKA4 D3f1HoqyirDTggQVSwF6BkryvRMUJLTm9H4Qwu4BoqC33QAoIb81KAVtq r3J6X0AolFt4/M1pVKpunbnNyn4DGtlC23KP9TFel7WtxArX9m1CFym/y E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAgCdJC5W/5tdJa1egzaBQwa+OwENgVqGHQIcgRI4FAEBAQEBAQGBCoQyAQEBBCMRRQwEAgEGAhEEAQEDAh8EAwICAjAUAQgIAgQBDQUIiCiVBJ03kgsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgSKKU4UNBwaCY4FFAQSWNgGNGpw1AR8BAUKCRIE/coYSgQYBAQE
X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="scan'208";a="201241353"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 26 Oct 2015 13:05:21 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9QD5Lcr015295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 13:05:21 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 08:04:58 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 08:04:58 -0500
From: "Hemant Singh (shemant)" 
To: Mark Smith , Alexandre Petrescu 
Thread-Topic: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
Thread-Index: AQHRDWxhb2/kpxJs3UyHJzBFrgSLn555GiMAgASoN4A=
Date: Mon, 26 Oct 2015 13:04:58 +0000
Message-ID: <681e9f2f0440463a962c9dab3ce4f55e@XCH-RCD-005.cisco.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.44]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 13:05:27 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNClNlbnQ6IEZyaWRheSwgT2N0
b2JlciAyMywgMjAxNSA0OjU2IEFNDQpUbzogQWxleGFuZHJlIFBldHJlc2N1DQpDYzogdjZvcHNA
aWV0Zi5vcmc7IEJyem96b3dza2ksIEpvaG47IOelnuaYjumBlOWTiQ0KU3ViamVjdDogUmU6IFt2
Nm9wc10gaG93IC82MyBoZWxwcyB0ZXRoZXJpbmcgKHdhczogRndkOiBJLUQgQWN0aW9uOiBkcmFm
dC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQpDQoNCg0KPkRv
ZXMgY29kZSBleGlzdCB0aGF0IGFscmVhZHkgZG9lcyB0aGlzPyBJZiBpdCBkb2Vzbid0LCB3aHkg
d291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIGltcGxlbWVudCBESENQdjYtUEQsIHRoZSBleGlzdGlu
ZywgdGVzdGVkIGFuZCBwcm92ZW4gbWVjaGFuaXNtIHRvIGRvIHRoaXMgc29ydCBvZiB0aGluZz8N
Cg0KVGhlIE9wZW5XUlQgaG9tZSByb3V0ZXIgTGludXggaW1wbGVtZW50YXRpb24gc3VwcG9ydHMg
REhDUHY2IFBELiAgIFNldmVyYWwgdmVuZG9ycyBzdXBwb3J0IERIQ1B2NiBQRCBpbiB0aGVpciBo
b21lIHJvdXRlcnMuICAgDQoNCkhlbWFudA0KDQoNCg0K


From nobody Mon Oct 26 08:27:38 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36CD1B4A4F for ; Mon, 26 Oct 2015 08:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03nRo7Z8NerA for ; Mon, 26 Oct 2015 08:27:34 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2993F1B4A4B for ; Mon, 26 Oct 2015 08:27:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9QFRZnU032159; Mon, 26 Oct 2015 08:27:35 -0700
Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9QFRVUT032137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 26 Oct 2015 08:27:31 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.201]) with mapi id 14.03.0235.001;  Mon, 26 Oct 2015 08:27:28 -0700
From: "Templin, Fred L" 
To: "Brzozowski, John" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDWwH/+MZsnq7pUCTitCxpFGwKp55fxmA///FwdCAAPJQgP//jjZQgAQaVNA=
Date: Mon, 26 Oct 2015 15:27:28 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F2F984@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com>  <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com>  <2134F8430051B64F815C691A62D9831832F2E2BD@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F2E2BD@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 15:27:37 -0000

Top-posting my own message from last Friday, I realized after clicking send
that I was out of line and want to apologize to John for the tone of the no=
te.
John knows and understands the community WiFi service use case in ways
that I do not, so it was inappropriate for me to profess knowledge of the
use case that I do not have.

That said, I think there are two areas that need further discussion:

1) Use of SLAAC PD vs DHCPv6 PD
2) Applicability to other domains

Regarding 1), there seems to be a growing interest in SLAAC-based prefix
delegation as an easy means for multi-addressing in some environments.
However, IMHO DHCPv6 PD is still the more appropriate method for many
use cases including enterprise/corporate, aviation networks, etc. The
relatives merits of both approaches should therefore be examined
according to their intended use cases.

Regarding 2), John's document indicates an interest in exploring other
domains of applicability such as corporate/enterprise and campus. But,
those are the use cases AERO has been primarily focused on for a long
time as documented here:

https://datatracker.ietf.org/doc/draft-templin-aeroent/

That is all I have to say for now.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Friday, October 23, 2015 5:46 PM
> To: Brzozowski, John; v6ops@ietf.org
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix=
-per-host-00.txt
>=20
> Hi John,
>=20
> > -----Original Message-----
> > From: Brzozowski, John [mailto:John_Brzozowski@cable.comcast.com]
> > Sent: Friday, October 23, 2015 4:56 PM
> > To: Templin, Fred L; v6ops@ietf.org
> > Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-pref=
ix-per-host-00.txt
> >
> >
> > -----Original Message-----
> > From: v6ops  on behalf of Fred Templin
> > 
> > Date: Friday, October 23, 2015 at 12:55
> > To: v6ops 
> > Subject: Re: [v6ops] Fwd: I-D Action:
> > draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
> >
> > >Hi,
> > >
> > >I read this draft in more detail, and I am left with many questions.
> > >First,
> > >I don't see any provisions for mobility or route optimization. In term=
s of
> > >mobility, the UE's IPv6 prefix appears to be tethered to the current A=
P
> > >point and cannot move with the UE as it moves from AP to AP.
> > [jjmb] as the draft sites APs are largely transparent.  Mobility is
> > support between Aps
>=20
> The draft doesn't say how that is done; it just says that there is a GRE
> tunnel between the AP and the WLAN-GW. Wireless solutions need
> to speak to mobility as a matter of course. Unless we are trying to
> further engender a population of couch potatoes that never leave
> their own living rooms.
>=20
> > however, WLAN-GW to WLAN-GW will result in a renumbering.
>=20
> Roaming between WLAN-GWs does not need to result in a
> renumbering event, which would be very unfortunate.
> Renumbering never happens with AERO, and UEs get to
> use their same delegated prefixes wherever they happen
> to pop up in the network.
>=20
> > As far as route optimization is concerned I am not sure how
> > else we can optimize routing to a default gateway.
>=20
> Route optimization is brokered by the network for the benefit of the
> clients and also to remove traffic concentration from performance
> critical network elements. AERO specifies a means for client to client
> route optimization that removes the default gateway from the path.
>=20
> > >In terms
> > >of route optimization, everything needs to go through the WLAN-GW
> > >and cannot go directly from UE to UE even if the two UEs are right nex=
t
> > >to one another.
> > [jjmb] this is actually deliberate and considered a feature.  Also note
> > the L bit is set to 0 to further encourage the use of the default gatew=
ay
> > (WLAN-GW) to facilitate node to Internet and node to node communication=
s.
>=20
> AERO provides route optimization requested by the client and brokered
> by the network. The network can either permit or deny route optimization
> as it is configured to do so, and provides a trust basis for clients to e=
ngage
> in the route optimization.  (Also check 6rd that provides natural route
> optimization as a fundamental aspect of its design.) Route optimization
> offloads performance-critical infrastructure and provides a better client
> to client experience.
>=20
> > >The approach also still requires the UE to do DAD over the interface i=
t
> > >receives the IPv6 RA with PIO from.
> > [jjmb] this could conceivably be omitted other than the DAD for the UE
> > link local address.  Perhaps we can optimize DAD by setting additional
> > flags in the RA.
>=20
> What additional flags would you set in the RA that an unmodified host
> would be able to recognize as a signal not to do DAD?
>=20
> > >Approaches that properly delegate
> > >an IPv6 prefix (e.g., DHCPv6 PD) do not require DAD over the interface
> > >the prefix is received on because the prefix itself must not be assign=
ed
> > >to that interface.
> > [jjmb] this is what is planned for when/if we support PD.
>=20
> PD gives the node a prefix that the network certifies will not be given
> to any other node. The prefix is not to be assigned to the link over
> which it was received, so there is no need to DAD for any of the
> addresses assigned from the prefix. And, there could be millions
> of such addresses.
>=20
> > > And, DHCPv6 PD client is trivial to implement today
> > >and does not need to be pushed into the far distant future.
> > [jjmb] the incremental nature of this has nothing to do with the client=
,
> > has to do with two things.  1) we are doing this incrementally and 2) w=
e
> > need to make sure the WLAN-GW implementations support this universally =
to
> > avoid partial support.
>=20
> I don't understand your meaning here, but what matters is a robust
> and acceptable end user experience throughout all rollout phases.
>=20
> > >The approach is also a network-based approach using in-the-network
> > >tunneling, but there are already many solutions that do this including
> > >PMIPv6, Proxy AERO, and CAPWAP. A better mobility and route
> > >optimization experience is also possible when the encapsulation is
> > >removed from the network and placed on the UE such as for client
> > >MIPv6 and client AERO. For AERO in particular, it is a very simple app
> > >that runs on the UE that can be downloaded and invoked in a similar
> > >fashion as for VPN clients like OpenVPN.
> > [jjmb] I have no control over the clients as such I can not enforce the
> > installation of such software.  I am quite I would get a very different
> > from this crowd and the public in general if I mandated additional
> > software.
>=20
> If you don't want to control the clients, then have a look at PMIPv6,
> Proxy AERO and/or CAPWAP.
>=20
> > >Finally, I am assuming that in large deployments there will be many
> > >WLAN-GWs - each associated with potentially many APs.
> > [jjmb] yes many APs to a single WLAN-GW.  Multiple WLAN-GWs.  An AP wil=
l
> > associate to one and only one WLAN-GW.
>=20
> That is fine, but you still need to care for mobiles that jump from AP
> to AP and in the process may roam between WLAN-GWs. That
> requires a mobility management scheme that I do not see in the draft.
>=20
> > >But, there
> > >is no discussion of how networking between the WLAN-GWs will
> > >occur - especially if UEs are allowed to roam between different
> > >WLAN-GWs.
> > [jjmb] internetworking between UEs served by different WLAN-GW will be
> > done using layer 3 routing as we know it today, where applicable.
>=20
> Layer 3 routing how, though? If you inject millions upon millions of
> UE prefixes into the routing system it is a recipe for disaster. Using
> a private BGP instance as specified in AERO is a way to avoid this.
>=20
> > >This is covered in detail in AERO and other approaches.
> > [jjmb] I am sure AERO is a great solution for your use case, however,
> > there is little to no overlap for our deployment of IPv6 for community
> > Wi-Fi.
>=20
> Many AERO use cases are examined in RFC6139, but the list there
> is not exhaustive. The use case described in your draft is indeed
> another use case for AERO.
>=20
> Thanks - Fred
> fred.l.templin@beoing.com
>=20
> > >Thanks - Fred
> > >fred.l.templin@boeing.com
> > >
> > >
> > >_______________________________________________
> > >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


From nobody Mon Oct 26 09:44:35 2015
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 B45D01B4F29; Mon, 26 Oct 2015 09:44:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151026164431.19176.87503.idtracker@ietfa.amsl.com>
Date: Mon, 26 Oct 2015 09:44:31 -0700
Archived-At: 
Cc: v6ops@ietf.org, fred.baker@cisco.com, joelja@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-dc-2xlat@ietf.org, The IESG , rfc-editor@rfc-editor.org
Subject: [v6ops] Document Action: 'SIIT-DC: Dual Translation Mode' to Informational RFC (draft-ietf-v6ops-siit-dc-2xlat-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 16:44:31 -0000

The IESG has approved the following document:
- 'SIIT-DC: Dual Translation Mode'
  (draft-ietf-v6ops-siit-dc-2xlat-02.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/





Technical Summary

   This document describes an extension of the Stateless IP/ICMP
   Translation for IPv6 Internet Data Centre Environments architecture
   (SIIT-DC), which allows applications, protocols, or nodes that
   are incompatible with IPv6, and/or Network Address Translation
   to operate correctly in an SIIT-DC environment.  This is
   accomplished by introducing a new component called an SIIT-DC
   Edge Relay, which reverses the translations made by an SIIT-DC
   Border Relay.  The application and/or node is thus provided with
   seemingly native IPv4 connectivity that provides end-to-end
   address transparency.

   The reader is expected to be familiar with the SIIT-DC architecture
   described in I-D.ietf-v6ops-siit-dc.

Working Group Summary

   The only real question was whether it belonged in the WG. The
   WG, in discussion, determined that it constituted an operational
   procedure comparable to 464xlat, and was therefore within charter.

Document Quality

   The only real question was whether it belonged in the WG. The
   WG, in discussion, determined that it constituted an operational
   procedure comparable to 464xlat, and was therefore within charter.

Personnel

   Fred Baker is the document shepherd. The AD is Joel Jaeggli.


From nobody Mon Oct 26 09:47:29 2015
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 DB3071B46A1; Mon, 26 Oct 2015 09:47:26 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151026164726.19662.55380.idtracker@ietfa.amsl.com>
Date: Mon, 26 Oct 2015 09:47:26 -0700
Archived-At: 
Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-dc@ietf.org, fred.baker@cisco.com, joelja@gmail.com, v6ops-chairs@ietf.org, The IESG , rfc-editor@rfc-editor.org
Subject: [v6ops] Document Action: 'SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments' to Informational RFC (draft-ietf-v6ops-siit-dc-03.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 16:47:27 -0000

The IESG has approved the following document:
- 'SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre
   Environments'
  (draft-ietf-v6ops-siit-dc-03.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/





Technical Summary

   This document describes the use of the Stateless IP/ICMP Translation
   (SIIT) algorithm in an IPv6 Internet Data Centre (IDC).  In this
   deployment model, traffic from legacy IPv4-only clients on the
   Internet is translated to IPv6 upon reaching the IDC operator's
   network infrastructure.  From that point on, it may be treated
   the same as traffic from native IPv6 end users.  The IPv6 endpoints
   may be numbered using arbitrary (non-IPv4-translatable) IPv6
   addresses.  This facilitates a single-stack IPv6-only network
   infrastructure, as well as efficient utilisation of public IPv4
   addresses.

   The primary audience is IDC operators who are deploying IPv6,
   running out of available IPv4 addresses, and/or feel that dual
   stack causes undesirable operational complexity.  Working Group
   Summary


Working Group Summary

   The only real question was whether it belonged in the WG. The
   WG, in discussion, determined that it constituted an operational
   procedure comparable to 464xlat, and was therefore within charter.

Document Quality

   The document describes something that is in fact implemented in
   at least four products from three vendors, and is in use in the
   author's networks and in other networks, as discussed at IETF
   93.


Personnel

   Fred Baker is the document shepherd. The AD is Joel Jaeggli.


From nobody Mon Oct 26 09:48:38 2015
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 6F2071B4FB8; Mon, 26 Oct 2015 09:48:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151026164833.23784.12962.idtracker@ietfa.amsl.com>
Date: Mon, 26 Oct 2015 09:48:33 -0700
Archived-At: 
Cc: v6ops@ietf.org, draft-ietf-v6ops-siit-eam@ietf.org, fred.baker@cisco.com, joelja@gmail.com, v6ops-chairs@ietf.org, The IESG , rfc-editor@rfc-editor.org
Subject: [v6ops] Protocol Action: 'Explicit Address Mappings for Stateless IP/ICMP Translation' to Proposed Standard (draft-ietf-v6ops-siit-eam-03.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 16:48:33 -0000

The IESG has approved the following document:
- 'Explicit Address Mappings for Stateless IP/ICMP Translation'
  (draft-ietf-v6ops-siit-eam-03.txt) as Proposed Standard

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/





Technical Summary

   This document extends the Stateless IP/ICMP Translation Algorithm
   (SIIT) with an Explicit Address Mapping (EAM) algorithm, and
   formally updates RFC 6145.  The EAM algorithm facilitates stateless
   IP/ICMP translation between arbitrary (non-IPv4-translatable)
   IPv6 endpoints and IPv4.

Working Group Summary

   The only real issue raised in the working group was whether the
   document should go to a different one, based on the working group
   charter. The working group elected to address it, with the AD's
   concurrence, based on siit-dc and siit-dc-2xlat being an operational
   procedure and this being closely related, and the facts that
   behave is closed and softwire is closing.

Document Quality

   The document describes something that is in fact implemented in
   at least four products from three vendors, and is in use in the
   author's networks and in other networks, as discussed at IETF
   93.

Personnel

Fred Baker is the document shepherd, and Joel Jaeggli is the AD.


From nobody Mon Oct 26 14:22:41 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7C51A1A9E; Mon, 26 Oct 2015 14:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dablAIpkYxvK; Mon, 26 Oct 2015 14:22:40 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34EE1A1A9F; Mon, 26 Oct 2015 14:22:39 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-3e-562e999ec4a6
Received: from PACDCEXHUB01.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 0D.CF.04607.E999E265; Mon, 26 Oct 2015 17:22:38 -0400 (EDT)
Received: from PACDCEX46.cable.comcast.com (24.40.2.145) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 26 Oct 2015 17:22:24 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX46.cable.comcast.com (24.40.2.145) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 26 Oct 2015 17:22:23 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Mon, 26 Oct 2015 17:22:23 -0400
From: "Brzozowski, John" 
To: Fernando Gont , v6ops 
Thread-Topic: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDv4tnEv4j9p2tUCHm9xx0gT8FJ5+cMcA
Date: Mon, 26 Oct 2015 21:22:22 +0000
Message-ID: 
References: <20151019195001.22760.70127.idtracker@ietfa.amsl.com>  <562C398F.5090308@si6networks.com>
In-Reply-To: <562C398F.5090308@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsXiEq4koztvpl6YwYvjUhZ3v79ksXiy6g2b xelje5kdmD2WLPnJ5PHhUA97AFMUl01Kak5mWWqRvl0CV8ahJ9+YCs6JV9z+tImxgbFBvIuR k0NCwERi9cO7jBC2mMSFe+vZuhi5OIQEdjFJ/F54lAXC2cso8W/OJGYIZzejxLqzT1khnJOM Eo0n3oL1swnYSLz+8BPMFhFwlFj+5jE7iM0sUCrR/OoVM4gtLJAu0XPlEDtETYbEkcvdrBC2 kcTzO7/AelkEVCUuTfkGFucVsJe4cfEG1E1zGCW2bZnJ1MXIwcEpoC+x4GERSA0j0N3fT61h gtglLnHryXwmiH8EJJbsOc8MYYtKvHz8D2ymqICeRPup/2wQcQOJrUv3sUDYihK/5l1hAxnP LKApsX6XPsRIB4krl7ayQNiKElO6H7JDnCYocXLmExaQciGgkfMeSENMEZc4fGQH6wRG2VlI DpqFMHQWkqGzkAydhWToAkbWVYxyBYnJKcm5GfmlJQaGesmJSTmpesn5ucmJxSUgehMjODXI L9/BeO+F0yFGAQ5GJR5ehn69MCHWxLLiytxDjBIczEoivJcnAoV4UxIrq1KL8uOLSnNSiw8x SnOwKInzbr73K1RIID2xJDU7NbUgtQgmy8TBKdXAOC3Ud1l+UbBMsGnbkqjrvk9EWM/sCOS0 XxKgXsju8nbN3JQq51drM0+HRZpq7JHq3F0wISLO3qFz0qLbs1nMXqm1vnt4SFNpSaMEu8LW V2uf7c5zE1J//bCxYJa6l97MC927/OorLNYqhRyecPN29hcJ3Qebl2411cncYJ6yXrwpKSaR 4c5BJZbijERDLeai4kQAXP2h7wkDAAA=
Archived-At: 
Cc: "draft-jjmb-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Oct 2015 21:22:41 -0000

RmVybmFuZG8sDQoNClRoZXJlIGlzIG5vdCBhIOKAnHByb2JsZW3igJ0gcGVyIHNlLCBtb3N0IG9m
IHRoZSBkb2N1bWVudCBvcmJpdHMgYXJvdW5kIGEgYmVzdA0KcHJhY3RpY2UgZm9yIGhvdyBJUHY2
IGNhbiBhbmQgaXMgYmVpbmcgZGVwbG95ZWQgZm9yIGEgbGFyZ2Ugc2NhbGUgV2ktRmkNCnNlcnZp
Y2UuICBCYXNlZCBvbiBleHBlcmllbmNlIGRlcGxveWluZyBJUHY2IGVsc2V3aGVyZSB3ZSBoYXZl
IHNlZW4NCmNoYWxsZW5nZXMgaW4gYXJlYXMgcGVydGFpbmluZyB0byByb3V0ZXIgYW5kIG5laWdo
Ym9yIGRpc2NvdmVyeSBhbmQgc2hhcmVkDQptZWRpYSBsaWtlIFdpLUZpLiAgU2luY2Ugbm90IGVu
YWJsaW5nIElQdjYgaXMgbm90IGFuIG9wdGlvbiBhbiBhcHByb2FjaA0Kd2FzIGRldmVsb3BlZCB0
byBlbnN1cmUgdGhlIHNhbWUgY2FuIGJlIGVuYWJsZWQgd2l0aG91dCBpbXBhY3RpbmcgdGhlDQpx
dWFsaXR5IGFuZCBwZXJmb3JtYW5jZSBvZiB0aGUgc2VydmljZS4gIFRoZSBJLUQgc2ltcGx5IGRv
Y3VtZW50cyB0aGUNCmFwcHJvYWNoIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGFsb25nIHdpdGggdGhl
IGNvcnJlc3BvbmRpbmcgcHJvdG9jb2xzIGJpdHMuDQoNCkRIQ1B2NiBQRCBzdXBwb3J0IGlzIHJl
ZmVyZW5jZWQgYXMgZnV0dXJlIHdvcmsuICBUaGUgSS1EIGRvZXMgbm90IGNvbW1lbnQNCm9uIHdo
ZXRoZXIgb3Igbm90IHN1cHBvcnQgZm9yIHRoZSBzYW1lIGlzIHBlcnZhc2l2ZS4NCg0KSm9obg0K
KzEtNDg0LTk2Mi0wMDYwDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+DQpEYXRlOiBTdW5kYXksIE9j
dG9iZXIgMjUsIDIwMTUgYXQgMDI6MDgNClRvOiBKb2huIEphc29uIEJyem96b3dza2kgPGpvaG5f
YnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbT4sIHY2b3BzDQo8djZvcHNAaWV0Zi5vcmc+DQpD
YzogImRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3Jn
Ig0KPGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNCj5IaSwg
Sm9obiAoJiBHdW50ZXIpLA0KPg0KPk9uIDEwLzIwLzIwMTUgMDg6NDUgQU0sIEJyem96b3dza2ks
IEpvaG4gd3JvdGU6DQo+PiB2Nm9wcywNCj4+IA0KPj4gT3ZlciB0aGUgcGFzdCBzZXZlcmFsIHll
YXJzIHRoZXJlIGhhcyBiZWVuIHNvbWUgcGxhbm5pbmcgZm9yIElQdjYNCj4+c3VwcG9ydA0KPj4g
Zm9yIGEgbGFyZ2Ugc2NhbGUgV2ktRmkgZGVwbG95bWVudC4gIFR1cm5zIGFmdGVyIHNoYXJpbmcg
c29tZSBvZiB0aGVzZQ0KPj4gZGV0YWlscyB3aXRoIG1hbnkgb2YgeW91ciBvdmVyIHRoZSBwYXN0
IHNldmVyYWwgSUVURiBtZWV0aW5ncyB0aGVyZSBpcw0KPj4gaW50ZXJlc3QgYmV5b25kIFdpLUZp
IGZvciB0aGlzIHdvcmsuICBUaGUgSS1EIGhhcyBmaW5hbGx5IGJlZW4gd3JpdHRlbg0KPj5zbw0K
Pj4gcGxlYXNlIHNlbmQgdXMgc29tZSBmZWVkYmFjayBvbiB0aGUgbGlzdC4gIEFzc3VtaW5nIHdl
IGdldCBhZGVxdWF0ZQ0KPj4gZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3ZSB3aWxsIHJlcXVlc3Qg
YSBzbG90IGluIFlva29oYW1hIHRvIGRpc2N1c3MNCj4+dGhpcw0KPj4gSS1ELg0KPg0KPkkgd2Vu
dCB0aHJvdWdoIHlvdSBkb2N1bWVudCwgYnV0IEknZCBzYXkgdGhhdCBpdCB3YXNuJ3QgdGhhdCBj
bGVhcg0KPndoYXQncyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYmVoaW5kIHRoaXMgZG9jdW1lbnQu
DQo+DQo+SXQgd291bGQgc2VlbSB0byBiZSAid2UgbmVlZCBESENQdjYtUEQsIGJ1dCBpdCBpcyBu
b3Qgd2lkZWx5IHN1cHBvcnRlZCIuDQo+SXMgdGhhdCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQ/IE9y
IGFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQo+DQo+VGhhbmtzIQ0KPg0KPkJlc3QgcmVnYXJkcywN
Cj4tLSANCj5GZXJuYW5kbyBHb250DQo+U0k2IE5ldHdvcmtzDQo+ZS1tYWlsOiBmZ29udEBzaTZu
ZXR3b3Jrcy5jb20NCj5QR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBF
M0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4NCj4NCj4NCj4NCj4NCg0K


From nobody Mon Oct 26 19:36:57 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EBC1B336E; Mon, 26 Oct 2015 19:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atq2c8xPNXWE; Mon, 26 Oct 2015 19:36:48 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CAD1B336C; Mon, 26 Oct 2015 19:36:48 -0700 (PDT)
Received: from g131.219-121-84.ppp.wakwak.ne.jp ([219.121.84.131] helo=[192.168.0.126]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zqu7v-0001m3-5A; Tue, 27 Oct 2015 03:36:43 +0100
To: "Brzozowski, John" , v6ops 
References: <20151019195001.22760.70127.idtracker@ietfa.amsl.com>  <562C398F.5090308@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <562EE0FD.5000609@si6networks.com>
Date: Tue, 27 Oct 2015 11:27:09 +0900
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "draft-jjmb-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 02:36:50 -0000

Hi, John,

On 10/27/2015 06:22 AM, Brzozowski, John wrote:
> 
> There is not a “problem†per se, most of the document orbits around a best
> practice for how IPv6 can and is being deployed for a large scale Wi-Fi
> service.  Based on experience deploying IPv6 elsewhere we have seen
> challenges in areas pertaining to router and neighbor discovery and shared
> media like Wi-Fi.

This should be stated more clearly.

For example, if this is "guidelines on how to do X", it should be
clearly stated.. Besides, the challenges you mentioned should be spelled
out. -- are they issues regarding multicast use in ND? Something else?


> Since not enabling IPv6 is not an option an approach
> was developed to ensure the same can be enabled without impacting the
> quality and performance of the service.  The I-D simply documents the
> approach that will be used to along with the corresponding protocols bits.

That's certainly fine. My point is that this was not clear to me when
reading the document.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Oct 27 04:24:00 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41FD1A0250 for ; Tue, 27 Oct 2015 04:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKTRwHAuUeqi for ; Tue, 27 Oct 2015 04:23:58 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57271A00BC for ; Tue, 27 Oct 2015 04:23:57 -0700 (PDT)
Received: by ykft191 with SMTP id t191so31716387ykf.0 for ; Tue, 27 Oct 2015 04:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i9oUkiMEv5skESr0aktnA3ZK/coLG2zRXRvnFmMI2bI=; b=my1Mt64bDknMSSig+VbJDUL1gLzZPeZRhPbaLoHvHKPU5fq4XLGT3DazIn6qbeKoeA 9Bjd9MJXW5Wj12rlKa9xtloYX9/uN8x0BuYDbmtpsWkZMG2TNv3g5OtDUHyTSG8EIFQf 5+zxaKwiISK858sMjIbojE8816aDZqNIJh4hOwPwhe4BBEEQjhCy0XEP714ascjk3cuK JTMdQtWIJOTzeHd9KSyavVhNDfkgo8BSCF20zz652Cj5w/RbIpeh49HJlvDpUNfXAagf G0jvXJoY7eMGp6WovVXy74mMqJa0bDbFVk0+bMu8veiNan1OEsc0JYUT7Iwlc790PqXL N16w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i9oUkiMEv5skESr0aktnA3ZK/coLG2zRXRvnFmMI2bI=; b=ZtywgG0mZ0RDhFAnBXhV05Fg2QRtypxxwdNWfkebrag9YoMz/6ohDEuAYAzJL/fhIm 1sYkOSfnPHuoF8XGZMID+5NmpNkRkgbvRFMuMWMO9SiCxdG3qK/vQzmogTswCwQffYrT cCji+qMlDI4USdQetKVFU/LE6b0Khl3Zh9obR1hgNhjgSRdOQ843w4xz94pkiFs0Eckr N5SyVMs0ZNbzD2K18y8RPLud4snp1LB2ZcfRLjyZUOpiBfzsJrQR2rjwPjtcVrKNjcAI s6hz2lDe3IpXXShLz5lC/73tH89AO9x9YO3mNg+VqViG67+3tbsG5i0hNnWn/GmFCNZi Iyxg==
X-Gm-Message-State: ALoCoQksUu4d/OpBLWXVLFnXxbdBPGUyD5eglTj+/PDlAR2x01Ciut8yXhrsp1cB2P3tImcV56bq
X-Received: by 10.13.215.213 with SMTP id z204mr33322272ywd.123.1445945036988;  Tue, 27 Oct 2015 04:23:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.87.197 with HTTP; Tue, 27 Oct 2015 04:23:37 -0700 (PDT)
In-Reply-To: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com> 
From: Lorenzo Colitti 
Date: Tue, 27 Oct 2015 20:23:37 +0900
Message-ID: 
To: Mark Smith 
Content-Type: multipart/alternative; boundary=94eb2c0762e04bc5540523145037
Archived-At: 
Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 11:23:58 -0000

--94eb2c0762e04bc5540523145037
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 23, 2015 at 5:55 PM, Mark Smith  wrote:

> Does code exist that already does this? If it doesn't, why wouldn't it
> be better to implement DHCPv6-PD, the existing, tested and proven
> mechanism to do this sort of thing?


Because this is an operational working group, and the document describes an
operational solution.

No popular operating system currently implements DHCPv6 PD on wifi, and
even if they all implemented it tomorrow, it would take years before a
substantial number of devices supported it.

--94eb2c0762e04bc5540523145037
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 23, 2015 at 5:55 PM, Mark Smith <markzzzsmith@gmail.com&g=
t; wrote:
Does code exist that alr=
eady does this? If it doesn't, why wouldn't it

be better to implement DHCPv6-PD, the existing, tested and proven

mechanism to do this sort of thing?

Because=
 this is an operational working group, and the document describes an operat=
ional solution.

No popular operating system curren=
tly implements DHCPv6 PD on wifi, and even if they all implemented it tomor=
row, it would take years before a substantial number of devices supported i=
t.


--94eb2c0762e04bc5540523145037--


From nobody Tue Oct 27 04:36:13 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B287F1A86DD for ; Tue, 27 Oct 2015 04:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCzMbJE837rM for ; Tue, 27 Oct 2015 04:36:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763811A854C for ; Tue, 27 Oct 2015 04:36:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDD32632; Tue, 27 Oct 2015 11:36:06 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Oct 2015 11:36:04 +0000
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.22]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 19:36:00 +0800
From: "Liushucheng (Will)" 
To: Nikos Mavrogiannopoulos , Philip Homburg 
Thread-Topic: [v6ops] preventing denial of service in IPv6
Thread-Index: AQHRDY0R12oD3DLxG0qx7EREYXrDKJ54p+oAgAaTEnA=
Date: Tue, 27 Oct 2015 11:35:59 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.84]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 11:36:11 -0000

Hi Nikos,

Please see my reply in-line below.

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, October 23, 2015 11:08 PM
> To: Philip Homburg
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] preventing denial of service in IPv6
>=20
> On Fri, Oct 23, 2015 at 2:19 PM, Philip Homburg
>  wrote:

> My point is exactly this disproportion. In this suggestion you add a heur=
istic of
> 256 misbehaving addresses to block 2^64 addresses in total (for a /64), a=
nd
> 256*256=3D2^16 mibehaving addresses to block 2^80 addresses. This will af=
fect
> someone who has divided a /64 into 2^32
> /96 subnets and shared it to different users, he will have his subnet com=
pletely
> blocked even if only 256 out of 2^32 is misbehaving. We may adjust these
> numbers as we like, but the disproportion will remain if we want to keep
> reasonable memory consumption for the server.

[Will] Just to chime in here to say that, IMHO, for SLAAC the network can t=
ypically be assumed to be a /64. And you might make a similar assumption fo=
r DHCPv6.

Regards,
Will (Shucheng LIU)=20


From nobody Tue Oct 27 04:47:26 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A7C1A8747 for ; Tue, 27 Oct 2015 04:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lUM5T62kddZ for ; Tue, 27 Oct 2015 04:47:23 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28CD1A8745 for ; Tue, 27 Oct 2015 04:47:22 -0700 (PDT)
X-Envelope-To: 
Received: from crumpet.local ([46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id t9RBlJF5097433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Oct 2015 11:47:20 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [46.182.8.8] claimed to be crumpet.local
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>  
From: Nick Hilliard 
X-Enigmail-Draft-Status: N1110
Message-ID: <562F6447.9010105@foobar.org>
Date: Tue, 27 Oct 2015 12:47:19 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040703050708040002000803"
Archived-At: 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 11:47:25 -0000

This is a multi-part message in MIME format.
--------------040703050708040002000803
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 27/10/2015 12:23, Lorenzo Colitti wrote:
> No popular operating system currently implements DHCPv6 PD on wifi, and=

> even if they all implemented it tomorrow, it would take years before a
> substantial number of devices supported it.
Apple's iOS distribution model disagrees with you.  Multiple trend sites
suggest that ios9, released 6 weeks ago, is currently standing at 55-60%
adoption across all iDevices.=20

Nick


--------------040703050708040002000803
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 27/10/2015 12:23, Lorenzo Colitti
      wrote:

    

    

      
No popular operating system currently implements DHCPv6 PD on
        wifi, and even if they all implemented it tomorrow, it would
        take years before a substantial number of devices supported it.

    

    Apple's iOS distribution model
        disagrees with you.  Multiple trend sites suggest that ios9,
        released 6 weeks ago, is currently standing at 55-60% adoption
        across all iDevices.  

        

        Nick

        

      
  


--------------040703050708040002000803--


From nobody Tue Oct 27 08:11:36 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C81A904F for ; Tue, 27 Oct 2015 08:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCaZza-2iEQD for ; Tue, 27 Oct 2015 08:11:29 -0700 (PDT)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63DA1A8BAF for ; Tue, 27 Oct 2015 08:11:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9RFBVBt014710; Tue, 27 Oct 2015 08:11:31 -0700
Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9RFBURN014696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 27 Oct 2015 08:11:30 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.147]) with mapi id 14.03.0235.001;  Tue, 27 Oct 2015 08:11:27 -0700
From: "Templin, Fred L" 
To: Lorenzo Colitti , Mark Smith 
Thread-Topic: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
Thread-Index: AQHREKoDwPvj4n+DlEaKgsVfDR4JT55/cGTQ
Date: Tue, 27 Oct 2015 15:11:26 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F30F94XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 15:11:36 -0000

--_000_2134F8430051B64F815C691A62D9831832F30F94XCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTG9yZW56bywNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI3
LCAyMDE1IDQ6MjQgQU0NClRvOiBNYXJrIFNtaXRoDQpDYzog56We5piO6YGU5ZOJOyB2Nm9wc0Bp
ZXRmLm9yZzsgQnJ6b3pvd3NraSwgSm9obg0KU3ViamVjdDogUmU6IFt2Nm9wc10gaG93IC82MyBo
ZWxwcyB0ZXRoZXJpbmcgKHdhczogRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2b3BzLXVu
aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQpDQoNCk9uIEZyaSwgT2N0IDIzLCAyMDE1
IGF0IDU6NTUgUE0sIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb208bWFpbHRvOm1h
cmt6enpzbWl0aEBnbWFpbC5jb20+PiB3cm90ZToNCkRvZXMgY29kZSBleGlzdCB0aGF0IGFscmVh
ZHkgZG9lcyB0aGlzPyBJZiBpdCBkb2Vzbid0LCB3aHkgd291bGRuJ3QgaXQNCmJlIGJldHRlciB0
byBpbXBsZW1lbnQgREhDUHY2LVBELCB0aGUgZXhpc3RpbmcsIHRlc3RlZCBhbmQgcHJvdmVuDQpt
ZWNoYW5pc20gdG8gZG8gdGhpcyBzb3J0IG9mIHRoaW5nPw0KDQpCZWNhdXNlIHRoaXMgaXMgYW4g
b3BlcmF0aW9uYWwgd29ya2luZyBncm91cCwgYW5kIHRoZSBkb2N1bWVudCBkZXNjcmliZXMgYW4g
b3BlcmF0aW9uYWwgc29sdXRpb24uDQoNCk5vIHBvcHVsYXIgb3BlcmF0aW5nIHN5c3RlbSBjdXJy
ZW50bHkgaW1wbGVtZW50cyBESENQdjYgUEQgb24gd2lmaSwgYW5kIGV2ZW4gaWYgdGhleSBhbGwg
aW1wbGVtZW50ZWQgaXQgdG9tb3Jyb3csIGl0IHdvdWxkIHRha2UgeWVhcnMgYmVmb3JlIGEgc3Vi
c3RhbnRpYWwgbnVtYmVyIG9mIGRldmljZXMgc3VwcG9ydGVkIGl0Lg0KDQpJIGhhdmUgYSBESENQ
djYgUEQgYXBwIHJ1bm5pbmcgb24gQW5kcm9pZCB0b2RheS4gSXQgaXMgcmVhbGx5IGp1c3QgYSBm
ZXcgY2xpZW50LXNpZGUNCm1lc3NhZ2VzLCBhbmQgdGhlbiB5b3UgZ2V0IGEgcHJlZml4IGZvciBw
cm92aXNpb25pbmcgYWRkcmVzc2VzIGFuZC9vciBmb3IgZnVydGhlcg0Kc3ViLWRlbGVnYXRpb24u
DQoNClRoYW5rcyDigJMgRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQoNCg==

--_000_2134F8430051B64F815C691A62D9831832F30F94XCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE
O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm
Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8
L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUgNDoyNCBBTTxicj4NCjxiPlRvOjwvYj4gTWFy
ayBTbWl0aDxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+OyB2Nm9wc0BpZXRmLm9yZzsgQnJ6b3pvd3NraSwgSm9objxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBob3cgLzYzIGhlbHBzIHRldGhlcmluZyAod2Fz
OiBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl
ci1ob3N0LTAwLnR4dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAyMywgMjAxNSBhdCA1OjU1IFBN
LCBNYXJrIFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIGNvZGUg
ZXhpc3QgdGhhdCBhbHJlYWR5IGRvZXMgdGhpcz8gSWYgaXQgZG9lc24ndCwgd2h5IHdvdWxkbid0
IGl0PGJyPg0KYmUgYmV0dGVyIHRvIGltcGxlbWVudCBESENQdjYtUEQsIHRoZSBleGlzdGluZywg
dGVzdGVkIGFuZCBwcm92ZW48YnI+DQptZWNoYW5pc20gdG8gZG8gdGhpcyBzb3J0IG9mIHRoaW5n
PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+QmVjYXVzZSB0aGlzIGlzIGFuIG9wZXJhdGlvbmFsIHdvcmtpbmcgZ3JvdXAsIGFuZCB0
aGUgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIHNvbHV0aW9uLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBwb3B1bGFyIG9w
ZXJhdGluZyBzeXN0ZW0gY3VycmVudGx5IGltcGxlbWVudHMgREhDUHY2IFBEIG9uIHdpZmksIGFu
ZCBldmVuIGlmIHRoZXkgYWxsIGltcGxlbWVudGVkIGl0IHRvbW9ycm93LCBpdCB3b3VsZCB0YWtl
IHllYXJzIGJlZm9yZSBhIHN1YnN0YW50aWFsIG51bWJlciBvZiBkZXZpY2VzIHN1cHBvcnRlZCBp
dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJG
NTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPkkgaGF2ZSBhIERIQ1B2
NiBQRCBhcHAgcnVubmluZyBvbiBBbmRyb2lkIHRvZGF5LiBJdCBpcyByZWFsbHkganVzdCBhIGZl
dyBjbGllbnQtc2lkZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNv
bG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5tZXNzYWdl
cywgYW5kIHRoZW4geW91IGdldCBhIHByZWZpeCBmb3IgcHJvdmlzaW9uaW5nIGFkZHJlc3NlcyBh
bmQvb3IgZm9yIGZ1cnRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmls
bC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+c3Vi
LWRlbGVnYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29s
b3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNv
LXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHls
ZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_2134F8430051B64F815C691A62D9831832F30F94XCHBLV504nwnosb_--


From nobody Tue Oct 27 10:17:15 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01E01ACCFB for ; Tue, 27 Oct 2015 10:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwxOQzkcRgfi for ; Tue, 27 Oct 2015 10:17:12 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52F31ACCF9 for ; Tue, 27 Oct 2015 10:17:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9RHHBuo026281; Tue, 27 Oct 2015 12:17:11 -0500
Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9RHH5b2026261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 27 Oct 2015 12:17:06 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-412.sw.nos.boeing.com ([169.254.12.14]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 10:17:05 -0700
From: "Templin, Fred L" 
To: Lorenzo Colitti , Mark Smith 
Thread-Topic: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
Thread-Index: AQHREKoDwPvj4n+DlEaKgsVfDR4JT55/cGTQgAAjPAA=
Date: Tue, 27 Oct 2015 17:17:04 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F311FEXCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= , "Brzozowski, John" 
Subject: Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 17:17:14 -0000

--_000_2134F8430051B64F815C691A62D9831832F311FEXCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Tm8gcG9wdWxhciBvcGVyYXRpbmcgc3lzdGVtIGN1cnJlbnRseSBpbXBsZW1lbnRzIERIQ1B2NiBQ
RCBvbiB3aWZpLCBhbmQgZXZlbiBpZiB0aGV5IGFsbCBpbXBsZW1lbnRlZCBpdCB0b21vcnJvdywg
aXQgd291bGQgdGFrZSB5ZWFycyBiZWZvcmUgYSBzdWJzdGFudGlhbCBudW1iZXIgb2YgZGV2aWNl
cyBzdXBwb3J0ZWQgaXQuDQoNCkFjdHVhbGx5LCBmb3JnZXQgbXkgbGl0dGxlIGhvbWVncm93biBh
cHAg4oCTIElTQyBESENQIGNsaWVudCBhbHJlYWR5IGhhcw0KREhDUHY2IFBEIGFuZCBydW5zIG9u
IGEgbnVtYmVyIG9mIE9TZXMuIEFtIEkgbWlzc2luZyB0aGUgcG9pbnQ/DQoNClRoYW5rcyDigJMg
RnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2
b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNClNlbnQ6
IFR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUgODoxMSBBTQ0KVG86IExvcmVuem8gQ29saXR0aTsg
TWFyayBTbWl0aA0KQ2M6IHY2b3BzQGlldGYub3JnOyDnpZ7mmI7pgZTlk4k7IEJyem96b3dza2ks
IEpvaG4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGhvdyAvNjMgaGVscHMgdGV0aGVyaW5nICh3YXM6
IEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
LWhvc3QtMDAudHh0KQ0KDQpIaSBMb3JlbnpvLA0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1
ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUgNDoyNCBBTQ0KVG86IE1hcmsgU21pdGgNCkNjOiDnpZ7m
mI7pgZTlk4k7IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IEJyem96b3dz
a2ksIEpvaG4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGhvdyAvNjMgaGVscHMgdGV0aGVyaW5nICh3
YXM6IEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt
cGVyLWhvc3QtMDAudHh0KQ0KDQpPbiBGcmksIE9jdCAyMywgMjAxNSBhdCA1OjU1IFBNLCBNYXJr
IFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwu
Y29tPj4gd3JvdGU6DQpEb2VzIGNvZGUgZXhpc3QgdGhhdCBhbHJlYWR5IGRvZXMgdGhpcz8gSWYg
aXQgZG9lc24ndCwgd2h5IHdvdWxkbid0IGl0DQpiZSBiZXR0ZXIgdG8gaW1wbGVtZW50IERIQ1B2
Ni1QRCwgdGhlIGV4aXN0aW5nLCB0ZXN0ZWQgYW5kIHByb3Zlbg0KbWVjaGFuaXNtIHRvIGRvIHRo
aXMgc29ydCBvZiB0aGluZz8NCg0KQmVjYXVzZSB0aGlzIGlzIGFuIG9wZXJhdGlvbmFsIHdvcmtp
bmcgZ3JvdXAsIGFuZCB0aGUgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIHNvbHV0
aW9uLg0KDQpObyBwb3B1bGFyIG9wZXJhdGluZyBzeXN0ZW0gY3VycmVudGx5IGltcGxlbWVudHMg
REhDUHY2IFBEIG9uIHdpZmksIGFuZCBldmVuIGlmIHRoZXkgYWxsIGltcGxlbWVudGVkIGl0IHRv
bW9ycm93LCBpdCB3b3VsZCB0YWtlIHllYXJzIGJlZm9yZSBhIHN1YnN0YW50aWFsIG51bWJlciBv
ZiBkZXZpY2VzIHN1cHBvcnRlZCBpdC4NCg0KSSBoYXZlIGEgREhDUHY2IFBEIGFwcCBydW5uaW5n
IG9uIEFuZHJvaWQgdG9kYXkuIEl0IGlzIHJlYWxseSBqdXN0IGEgZmV3IGNsaWVudC1zaWRlDQpt
ZXNzYWdlcywgYW5kIHRoZW4geW91IGdldCBhIHByZWZpeCBmb3IgcHJvdmlzaW9uaW5nIGFkZHJl
c3NlcyBhbmQvb3IgZm9yIGZ1cnRoZXINCnN1Yi1kZWxlZ2F0aW9uLg0KDQpUaGFua3Mg4oCTIEZy
ZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOmZyZWQubC50ZW1wbGluQGJvZWlu
Zy5jb20+DQoNCg0K

--_000_2134F8430051B64F815C691A62D9831832F311FEXCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE
O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8g
cG9wdWxhciBvcGVyYXRpbmcgc3lzdGVtIGN1cnJlbnRseSBpbXBsZW1lbnRzIERIQ1B2NiBQRCBv
biB3aWZpLCBhbmQgZXZlbiBpZiB0aGV5IGFsbCBpbXBsZW1lbnRlZCBpdCB0b21vcnJvdywgaXQg
d291bGQgdGFrZSB5ZWFycyBiZWZvcmUgYSBzdWJzdGFudGlhbCBudW1iZXIgb2YgZGV2aWNlcyBz
dXBwb3J0ZWQgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFjdHVhbGx5
LCBmb3JnZXQgbXkgbGl0dGxlIGhvbWVncm93biBhcHAg4oCTIElTQyBESENQIGNsaWVudCBhbHJl
YWR5IGhhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ESENQdjYgUEQgYW5kIHJ1bnMgb24gYSBudW1iZXIg
b2YgT1Nlcy4gQW0gSSBtaXNzaW5nIHRoZSBwb2ludD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDigJMgRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5mcmVk
LmwudGVtcGxpbkBib2VpbmcuY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs
dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3Vu
Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZW1wbGluLCBGcmVkIEw8YnI+DQo8
Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyNywgMjAxNSA4OjExIEFNPGJyPg0KPGI+VG86
PC9iPiBMb3JlbnpvIENvbGl0dGk7IE1hcmsgU21pdGg8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGll
dGYub3JnOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij47IEJyem96b3dza2ksIEpvaG48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gaG93
IC82MyBoZWxwcyB0ZXRoZXJpbmcgKHdhczogRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2
b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQpPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41
cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgWzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPkxvcmVuem8gQ29saXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5
LCBPY3RvYmVyIDI3LCAyMDE1IDQ6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgU21pdGg8YnI+
DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuelnuaYjumBlOWTiTwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjsNCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8
L2E+OyBCcnpvem93c2tpLCBKb2huPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGhv
dyAvNjMgaGVscHMgdGV0aGVyaW5nICh3YXM6IEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtamptYi12
Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0KTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy
aSwgT2N0IDIzLCAyMDE1IGF0IDU6NTUgUE0sIE1hcmsgU21pdGggJmx0OzxhIGhyZWY9Im1haWx0
bzptYXJrenp6c21pdGhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFya3p6enNtaXRoQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2Vz
IGNvZGUgZXhpc3QgdGhhdCBhbHJlYWR5IGRvZXMgdGhpcz8gSWYgaXQgZG9lc24ndCwgd2h5IHdv
dWxkbid0IGl0PGJyPg0KYmUgYmV0dGVyIHRvIGltcGxlbWVudCBESENQdjYtUEQsIHRoZSBleGlz
dGluZywgdGVzdGVkIGFuZCBwcm92ZW48YnI+DQptZWNoYW5pc20gdG8gZG8gdGhpcyBzb3J0IG9m
IHRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QmVjYXVzZSB0aGlzIGlzIGFuIG9wZXJhdGlvbmFsIHdvcmtpbmcgZ3JvdXAs
IGFuZCB0aGUgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIHNvbHV0aW9uLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBwb3B1
bGFyIG9wZXJhdGluZyBzeXN0ZW0gY3VycmVudGx5IGltcGxlbWVudHMgREhDUHY2IFBEIG9uIHdp
ZmksIGFuZCBldmVuIGlmIHRoZXkgYWxsIGltcGxlbWVudGVkIGl0IHRvbW9ycm93LCBpdCB3b3Vs
ZCB0YWtlIHllYXJzIGJlZm9yZSBhIHN1YnN0YW50aWFsIG51bWJlciBvZiBkZXZpY2VzIHN1cHBv
cnRlZCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTciPkkgaGF2ZSBhIERIQ1B2NiBQRCBhcHAgcnVu
bmluZyBvbiBBbmRyb2lkIHRvZGF5LiBJdCBpcyByZWFsbHkganVzdCBhIGZldyBjbGllbnQtc2lk
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMkY1NTk3Ij5tZXNzYWdlcywgYW5kIHRoZW4geW91IGdldCBhIHByZWZpeCBm
b3IgcHJvdmlzaW9uaW5nIGFkZHJlc3NlcyBhbmQvb3IgZm9yIGZ1cnRoZXI8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJG
NTU5NyI+c3ViLWRlbGVnYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTciPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MkY1NTk3Ij5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5NyI+PGEgaHJlZj0ibWFpbHRv
OmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20iPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208L2E+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2134F8430051B64F815C691A62D9831832F311FEXCHBLV504nwnosb_--


From nobody Tue Oct 27 16:37:43 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC911B2F26; Tue, 27 Oct 2015 16:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WAlgpXjuco7; Tue, 27 Oct 2015 16:37:41 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFB91B2F25; Tue, 27 Oct 2015 16:37:41 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-33-56300ac3af24
Received: from PACDCEXHUB01.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 2F.71.04607.3CA00365; Tue, 27 Oct 2015 19:37:39 -0400 (EDT)
Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 27 Oct 2015 19:36:44 -0400
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX15.cable.comcast.com (147.191.102.82) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 27 Oct 2015 19:36:43 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1044.021; Tue, 27 Oct 2015 19:36:43 -0400
From: "Brzozowski, John" 
To: Fernando Gont , v6ops 
Thread-Topic: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDv4tnEv4j9p2tUCHm9xx0gT8FJ5+cMcAgAByQICAAUq1AA==
Date: Tue, 27 Oct 2015 23:36:43 +0000
Message-ID: 
References: <20151019195001.22760.70127.idtracker@ietfa.amsl.com>  <562C398F.5090308@si6networks.com>  <562EE0FD.5000609@si6networks.com>
In-Reply-To: <562EE0FD.5000609@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <548EB64FCC9B7847B3C841E76368AFF2@cable.comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsXiEq4ko3uYyyDMoHOujcXd7y9ZLJ6sesNm cfrYXmYHZo8lS34yeXw41MMewBTFZZOSmpNZllqkb5fAlbFtygzGgj0iFRe/d7I0MP4Q7mLk 5JAQMJG4NfEoO4QtJnHh3nq2LkYuDiGBXUwSx158YYFwDjBKTL35hBHCOcgosX3ZemYI5ySj xK5jjWD9bAI2Eq8//GQEsUUEHCWWv3kMFmcWKJVofvWKGcQWFkiX6LlyiB2iJkPiyOVuVgjb SeLXZAibRUBVonnmUTYQm1fAXuLNnoXsEMu+M0os7t/CApLgFNCXuDL3ENgyRqDDv59awwSx TFzi1pP5TBAPCUgs2XOeGcIWlXj5+B/YAlEBPYn2U//ZIOIGEluX7mOBsBUktu/fBmRzAM3R lFi/Sx9ipIPEpP47jBC2osSU7ofsELcJSpyc+QSsXAho5LwH0hBTxCUOH9nBOoFRdhaSg2Yh DJ2FZOgsJENnIRm6gJF1FaNcQWJySnJuRn5piYGhXnJiUk6qXnJ+bnJicQmI3sQITg7yy3cw 3nvhdIhRgINRiYf34B/9MCHWxLLiytxDjBIczEoivD3ZQCHelMTKqtSi/Pii0pzU4kOM0hws SuK8m+/9ChUSSE8sSc1OTS1ILYLJMnFwSjUwStTe1DgjKx7/M+bkq3+CLyye7dI4Us2h5vor Z9L1DIdEQUPuYv0vN9+07T+2vH7FO+snhWa/d05gyq+N/3qKxeZP7MPbJ7sPn9a5xtSW1j7T fNJ8yav7VdbceG9W+EnyjvgsKcMnn62/TnbbvfWkzbRDqzo/HxQNZ/7GVrfHKvOF87TLU1hC 7yuxFGckGmoxFxUnAgAK3mXmCgMAAA==
Archived-At: 
Cc: "draft-jjmb-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 23:37:42 -0000

RmVybmFuZG8sDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiAgSSB0aG91Z2h0IHdlIGRpZCBh
biBPSyBqb2IgZnJhbWluZyB0aGUgc2NvcGUgYW5kDQptb3RpdmF0aW9uIG9mIHRoZSBkb2N1bWVu
dC4gIEdpdmVuIHlvdXIgZmVlZGJhY2ssIEd1bnRlciBhbmQgSSB3aWxsIHRha2UNCmFub3RoZXIg
cGFzcyBhbmQgc2VlIGlmIHdlIGNhbiBmdXJ0aGVyIGNsYXJpZnkuDQoNCkpvaG4NCisxLTQ4NC05
NjItMDA2MA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRmVybmFu
ZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAy
NywgMjAxNSBhdCAwMjoyNw0KVG86IEpvaG4gSmFzb24gQnJ6b3pvd3NraSA8am9obl9icnpvem93
c2tpQGNhYmxlLmNvbWNhc3QuY29tPiwgdjZvcHMNCjx2Nm9wc0BpZXRmLm9yZz4NCkNjOiAiZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmciDQo8ZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFmdC1qam1i
LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCg0KPkhpLCBKb2huLA0K
Pg0KPk9uIDEwLzI3LzIwMTUgMDY6MjIgQU0sIEJyem96b3dza2ksIEpvaG4gd3JvdGU6DQo+PiAN
Cj4+IFRoZXJlIGlzIG5vdCBhIOKAnHByb2JsZW3igJ0gcGVyIHNlLCBtb3N0IG9mIHRoZSBkb2N1
bWVudCBvcmJpdHMgYXJvdW5kIGENCj4+YmVzdA0KPj4gcHJhY3RpY2UgZm9yIGhvdyBJUHY2IGNh
biBhbmQgaXMgYmVpbmcgZGVwbG95ZWQgZm9yIGEgbGFyZ2Ugc2NhbGUgV2ktRmkNCj4+IHNlcnZp
Y2UuICBCYXNlZCBvbiBleHBlcmllbmNlIGRlcGxveWluZyBJUHY2IGVsc2V3aGVyZSB3ZSBoYXZl
IHNlZW4NCj4+IGNoYWxsZW5nZXMgaW4gYXJlYXMgcGVydGFpbmluZyB0byByb3V0ZXIgYW5kIG5l
aWdoYm9yIGRpc2NvdmVyeSBhbmQNCj4+c2hhcmVkDQo+PiBtZWRpYSBsaWtlIFdpLUZpLg0KPg0K
PlRoaXMgc2hvdWxkIGJlIHN0YXRlZCBtb3JlIGNsZWFybHkuDQo+DQo+Rm9yIGV4YW1wbGUsIGlm
IHRoaXMgaXMgImd1aWRlbGluZXMgb24gaG93IHRvIGRvIFgiLCBpdCBzaG91bGQgYmUNCj5jbGVh
cmx5IHN0YXRlZC4uIEJlc2lkZXMsIHRoZSBjaGFsbGVuZ2VzIHlvdSBtZW50aW9uZWQgc2hvdWxk
IGJlIHNwZWxsZWQNCj5vdXQuIC0tIGFyZSB0aGV5IGlzc3VlcyByZWdhcmRpbmcgbXVsdGljYXN0
IHVzZSBpbiBORD8gU29tZXRoaW5nIGVsc2U/DQo+DQo+DQo+PiBTaW5jZSBub3QgZW5hYmxpbmcg
SVB2NiBpcyBub3QgYW4gb3B0aW9uIGFuIGFwcHJvYWNoDQo+PiB3YXMgZGV2ZWxvcGVkIHRvIGVu
c3VyZSB0aGUgc2FtZSBjYW4gYmUgZW5hYmxlZCB3aXRob3V0IGltcGFjdGluZyB0aGUNCj4+IHF1
YWxpdHkgYW5kIHBlcmZvcm1hbmNlIG9mIHRoZSBzZXJ2aWNlLiAgVGhlIEktRCBzaW1wbHkgZG9j
dW1lbnRzIHRoZQ0KPj4gYXBwcm9hY2ggdGhhdCB3aWxsIGJlIHVzZWQgdG8gYWxvbmcgd2l0aCB0
aGUgY29ycmVzcG9uZGluZyBwcm90b2NvbHMNCj4+Yml0cy4NCj4NCj5UaGF0J3MgY2VydGFpbmx5
IGZpbmUuIE15IHBvaW50IGlzIHRoYXQgdGhpcyB3YXMgbm90IGNsZWFyIHRvIG1lIHdoZW4NCj5y
ZWFkaW5nIHRoZSBkb2N1bWVudC4NCj4NCj5UaGFua3MhDQo+DQo+Q2hlZXJzLA0KPi0tIA0KPkZl
cm5hbmRvIEdvbnQNCj5TSTYgTmV0d29ya3MNCj5lLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNv
bQ0KPlBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAw
RDU1IDFENEUgNzQ5Mg0KPg0KPg0KPg0KPg0KPg0KDQo=


From nobody Tue Oct 27 16:40:50 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8413D1B2F53 for ; Tue, 27 Oct 2015 16:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvupF58LiEsx for ; Tue, 27 Oct 2015 16:40:47 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142FD1B2F51 for ; Tue, 27 Oct 2015 16:40:47 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-0f-56300b7d2a7d
Received: from pacdcexhub05.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 12.B1.04607.D7B00365; Tue, 27 Oct 2015 19:40:46 -0400 (EDT)
Received: from VAADCEX10.cable.comcast.com (147.191.102.77) by pacdcexhub05.cable.comcast.com (24.40.56.122) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 27 Oct 2015 19:39:51 -0400
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX10.cable.comcast.com (147.191.102.77) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 27 Oct 2015 19:39:50 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1044.021; Tue, 27 Oct 2015 19:39:50 -0400
From: "Brzozowski, John" 
To: "Templin, Fred L" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRERDFEgwrza9uEkWJkCKFFwE/Pg==
Date: Tue, 27 Oct 2015 23:39:49 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com>  <56290B90.8000400@gmail.com>  <5629EE64.1060402@gmail.com>  <2134F8430051B64F815C691A62D9831832F2DBAD@XCH-BLV-504.nw.nos.boeing.com>  <2134F8430051B64F815C691A62D9831832F2E2BD@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F2F984@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F2F984@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsXiEq4ko1vHbRBm8GMGm8X5U1NYLE4f28vs wOTx++AbZo8lS34yBTBFcdmkpOZklqUW6dslcGVsONHEXPAgs+Ll+b/sDYwt6V2MHBwSAiYS UzcZdTFyApliEhfurWfrYuTiEBLYxSQx9/c0KOcAo8SXpwuZIJyDjBJbFq1mhXBOMkq0/vrG BtLPJmAj8frDT0YQW0QgTGLyuQUsILawQLTEji39bBDxGIlZLxqZIGw9ictr9zOBnMEioCrx foIeSJhXwF5iQd9yRoj5d1glHs2dzgqS4BQIlZjwZRXYHEagW7+fWgM2h1lAXOLWk/lMED8I SCzZc54ZwhaVePn4H1ivKNCu9lP/2SDiBhJbl+5jgbAVJX7Nu8IGcgOzgKbE+l36ECMdJN68 +cQGYStKTOl+yA5xm6DEyZlPWEDKhYBGznsgDTFFXOLwkR2sExhlZiE5aBbC0FlIhs5CMnQW kqELGFlXMcoVJCanJOdm5JeWGBjqJScm5aTqJefnJicWl4DoTYzguJdfvoPx3gunQ4wCHIxK PLwH/+iHCbEmlhVX5h5ilOBgVhLh7ckGCvGmJFZWpRblxxeV5qQWH2KU5mBREufdfO9XqJBA emJJanZqakFqEUyWiYNTqoHRUezNwwxHI7Zo9vjXtemaSiXR7u3VufrXEljnfm3iv+Xls5pz TuIu7bV37hiu/PlXeLO466L3brM3S6c/3BvGxZ4vozLV5ctJ/b8Vp9kYApYZpT00cVrYkDxH MaDysvEP3rfsN8zOL4qd6xXPEvzV2kW76M8Fi0b5quPhJnoiTK+Yg85VqyqxFGckGmoxFxUn AgDLzwUa9wIAAA==
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Oct 2015 23:40:49 -0000

VGhhbmsgeW91IEZyZWQsIHNpbmNlcmVseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYmVsb3cu
DQoNCkkgYWdyZWUgd2l0aCB5b3VyIHR3byBidWxsZXRzIGJlbG93Lg0KDQpJIGFncmVlIHRoYXQg
REhDUHY2IFBEIGlzIHdpZGVseSB1c2UsIGhvd2V2ZXIsIEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNp
ZGVyDQp0aGUgcG9zc2liaWxpdHkgdGhhdCBtb3JlIHRoYW4gb25lIGFwcHJvYWNoIG1heWJlIGFw
cHJvcHJpYXRlL25lZWRlZC4NCg0KSm9obg0KKzEtNDg0LTk2Mi0wMDYwDQoNCg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9y
Zz4gb24gYmVoYWxmIG9mIEZyZWQgVGVtcGxpbg0KPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+
DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMjYsIDIwMTUgYXQgMTU6MjcNClRvOiBKb2huIEphc29u
IEJyem96b3dza2kgPGpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbT4sIHY2b3BzDQo8
djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246DQpk
cmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCg0KPlRv
cC1wb3N0aW5nIG15IG93biBtZXNzYWdlIGZyb20gbGFzdCBGcmlkYXksIEkgcmVhbGl6ZWQgYWZ0
ZXIgY2xpY2tpbmcNCj5zZW5kDQo+dGhhdCBJIHdhcyBvdXQgb2YgbGluZSBhbmQgd2FudCB0byBh
cG9sb2dpemUgdG8gSm9obiBmb3IgdGhlIHRvbmUgb2YgdGhlDQo+bm90ZS4NCj5Kb2huIGtub3dz
IGFuZCB1bmRlcnN0YW5kcyB0aGUgY29tbXVuaXR5IFdpRmkgc2VydmljZSB1c2UgY2FzZSBpbiB3
YXlzDQo+dGhhdCBJIGRvIG5vdCwgc28gaXQgd2FzIGluYXBwcm9wcmlhdGUgZm9yIG1lIHRvIHBy
b2Zlc3Mga25vd2xlZGdlIG9mIHRoZQ0KPnVzZSBjYXNlIHRoYXQgSSBkbyBub3QgaGF2ZS4NCj4N
Cj5UaGF0IHNhaWQsIEkgdGhpbmsgdGhlcmUgYXJlIHR3byBhcmVhcyB0aGF0IG5lZWQgZnVydGhl
ciBkaXNjdXNzaW9uOg0KPg0KPjEpIFVzZSBvZiBTTEFBQyBQRCB2cyBESENQdjYgUEQNCj4yKSBB
cHBsaWNhYmlsaXR5IHRvIG90aGVyIGRvbWFpbnMNCj4NCj5SZWdhcmRpbmcgMSksIHRoZXJlIHNl
ZW1zIHRvIGJlIGEgZ3Jvd2luZyBpbnRlcmVzdCBpbiBTTEFBQy1iYXNlZCBwcmVmaXgNCj5kZWxl
Z2F0aW9uIGFzIGFuIGVhc3kgbWVhbnMgZm9yIG11bHRpLWFkZHJlc3NpbmcgaW4gc29tZSBlbnZp
cm9ubWVudHMuDQo+SG93ZXZlciwgSU1ITyBESENQdjYgUEQgaXMgc3RpbGwgdGhlIG1vcmUgYXBw
cm9wcmlhdGUgbWV0aG9kIGZvciBtYW55DQo+dXNlIGNhc2VzIGluY2x1ZGluZyBlbnRlcnByaXNl
L2NvcnBvcmF0ZSwgYXZpYXRpb24gbmV0d29ya3MsIGV0Yy4gVGhlDQo+cmVsYXRpdmVzIG1lcml0
cyBvZiBib3RoIGFwcHJvYWNoZXMgc2hvdWxkIHRoZXJlZm9yZSBiZSBleGFtaW5lZA0KPmFjY29y
ZGluZyB0byB0aGVpciBpbnRlbmRlZCB1c2UgY2FzZXMuDQo+DQo+UmVnYXJkaW5nIDIpLCBKb2hu
J3MgZG9jdW1lbnQgaW5kaWNhdGVzIGFuIGludGVyZXN0IGluIGV4cGxvcmluZyBvdGhlcg0KPmRv
bWFpbnMgb2YgYXBwbGljYWJpbGl0eSBzdWNoIGFzIGNvcnBvcmF0ZS9lbnRlcnByaXNlIGFuZCBj
YW1wdXMuIEJ1dCwNCj50aG9zZSBhcmUgdGhlIHVzZSBjYXNlcyBBRVJPIGhhcyBiZWVuIHByaW1h
cmlseSBmb2N1c2VkIG9uIGZvciBhIGxvbmcNCj50aW1lIGFzIGRvY3VtZW50ZWQgaGVyZToNCj4N
Cj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9lbnQv
DQo+DQo+VGhhdCBpcyBhbGwgSSBoYXZlIHRvIHNheSBmb3Igbm93Lg0KPg0KPlRoYW5rcyAtIEZy
ZWQNCj5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBMDQo+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjMs
IDIwMTUgNTo0NiBQTQ0KPj4gVG86IEJyem96b3dza2ksIEpvaG47IHY2b3BzQGlldGYub3JnDQo+
PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246DQo+PmRyYWZ0LWpqbWItdjZv
cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KPj4gDQo+PiBIaSBKb2huLA0K
Pj4gDQo+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+IEZyb206IEJyem96b3dz
a2ksIEpvaG4gW21haWx0bzpKb2huX0Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb21dDQo+PiA+
IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMywgMjAxNSA0OjU2IFBNDQo+PiA+IFRvOiBUZW1wbGlu
LCBGcmVkIEw7IHY2b3BzQGlldGYub3JnDQo+PiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDog
SS1EIEFjdGlvbjoNCj4+ZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv
c3QtMDAudHh0DQo+PiA+DQo+PiA+DQo+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
PiA+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRnJl
ZCBUZW1wbGluDQo+PiA+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPj4gPiBEYXRlOiBG
cmlkYXksIE9jdG9iZXIgMjMsIDIwMTUgYXQgMTI6NTUNCj4+ID4gVG86IHY2b3BzIDx2Nm9wc0Bp
ZXRmLm9yZz4NCj4+ID4gU3ViamVjdDogUmU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9uOg0KPj4g
PiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMC50eHQNCj4+
ID4NCj4+ID4gPkhpLA0KPj4gPiA+DQo+PiA+ID5JIHJlYWQgdGhpcyBkcmFmdCBpbiBtb3JlIGRl
dGFpbCwgYW5kIEkgYW0gbGVmdCB3aXRoIG1hbnkgcXVlc3Rpb25zLg0KPj4gPiA+Rmlyc3QsDQo+
PiA+ID5JIGRvbid0IHNlZSBhbnkgcHJvdmlzaW9ucyBmb3IgbW9iaWxpdHkgb3Igcm91dGUgb3B0
aW1pemF0aW9uLiBJbg0KPj50ZXJtcyBvZg0KPj4gPiA+bW9iaWxpdHksIHRoZSBVRSdzIElQdjYg
cHJlZml4IGFwcGVhcnMgdG8gYmUgdGV0aGVyZWQgdG8gdGhlIGN1cnJlbnQNCj4+QVANCj4+ID4g
PnBvaW50IGFuZCBjYW5ub3QgbW92ZSB3aXRoIHRoZSBVRSBhcyBpdCBtb3ZlcyBmcm9tIEFQIHRv
IEFQLg0KPj4gPiBbamptYl0gYXMgdGhlIGRyYWZ0IHNpdGVzIEFQcyBhcmUgbGFyZ2VseSB0cmFu
c3BhcmVudC4gIE1vYmlsaXR5IGlzDQo+PiA+IHN1cHBvcnQgYmV0d2VlbiBBcHMNCj4+IA0KPj4g
VGhlIGRyYWZ0IGRvZXNuJ3Qgc2F5IGhvdyB0aGF0IGlzIGRvbmU7IGl0IGp1c3Qgc2F5cyB0aGF0
IHRoZXJlIGlzIGEgR1JFDQo+PiB0dW5uZWwgYmV0d2VlbiB0aGUgQVAgYW5kIHRoZSBXTEFOLUdX
LiBXaXJlbGVzcyBzb2x1dGlvbnMgbmVlZA0KPj4gdG8gc3BlYWsgdG8gbW9iaWxpdHkgYXMgYSBt
YXR0ZXIgb2YgY291cnNlLiBVbmxlc3Mgd2UgYXJlIHRyeWluZyB0bw0KPj4gZnVydGhlciBlbmdl
bmRlciBhIHBvcHVsYXRpb24gb2YgY291Y2ggcG90YXRvZXMgdGhhdCBuZXZlciBsZWF2ZQ0KPj4g
dGhlaXIgb3duIGxpdmluZyByb29tcy4NCj4+IA0KPj4gPiBob3dldmVyLCBXTEFOLUdXIHRvIFdM
QU4tR1cgd2lsbCByZXN1bHQgaW4gYSByZW51bWJlcmluZy4NCj4+IA0KPj4gUm9hbWluZyBiZXR3
ZWVuIFdMQU4tR1dzIGRvZXMgbm90IG5lZWQgdG8gcmVzdWx0IGluIGENCj4+IHJlbnVtYmVyaW5n
IGV2ZW50LCB3aGljaCB3b3VsZCBiZSB2ZXJ5IHVuZm9ydHVuYXRlLg0KPj4gUmVudW1iZXJpbmcg
bmV2ZXIgaGFwcGVucyB3aXRoIEFFUk8sIGFuZCBVRXMgZ2V0IHRvDQo+PiB1c2UgdGhlaXIgc2Ft
ZSBkZWxlZ2F0ZWQgcHJlZml4ZXMgd2hlcmV2ZXIgdGhleSBoYXBwZW4NCj4+IHRvIHBvcCB1cCBp
biB0aGUgbmV0d29yay4NCj4+IA0KPj4gPiBBcyBmYXIgYXMgcm91dGUgb3B0aW1pemF0aW9uIGlz
IGNvbmNlcm5lZCBJIGFtIG5vdCBzdXJlIGhvdw0KPj4gPiBlbHNlIHdlIGNhbiBvcHRpbWl6ZSBy
b3V0aW5nIHRvIGEgZGVmYXVsdCBnYXRld2F5Lg0KPj4gDQo+PiBSb3V0ZSBvcHRpbWl6YXRpb24g
aXMgYnJva2VyZWQgYnkgdGhlIG5ldHdvcmsgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KPj4gY2xp
ZW50cyBhbmQgYWxzbyB0byByZW1vdmUgdHJhZmZpYyBjb25jZW50cmF0aW9uIGZyb20gcGVyZm9y
bWFuY2UNCj4+IGNyaXRpY2FsIG5ldHdvcmsgZWxlbWVudHMuIEFFUk8gc3BlY2lmaWVzIGEgbWVh
bnMgZm9yIGNsaWVudCB0byBjbGllbnQNCj4+IHJvdXRlIG9wdGltaXphdGlvbiB0aGF0IHJlbW92
ZXMgdGhlIGRlZmF1bHQgZ2F0ZXdheSBmcm9tIHRoZSBwYXRoLg0KPj4gDQo+PiA+ID5JbiB0ZXJt
cw0KPj4gPiA+b2Ygcm91dGUgb3B0aW1pemF0aW9uLCBldmVyeXRoaW5nIG5lZWRzIHRvIGdvIHRo
cm91Z2ggdGhlIFdMQU4tR1cNCj4+ID4gPmFuZCBjYW5ub3QgZ28gZGlyZWN0bHkgZnJvbSBVRSB0
byBVRSBldmVuIGlmIHRoZSB0d28gVUVzIGFyZSByaWdodA0KPj5uZXh0DQo+PiA+ID50byBvbmUg
YW5vdGhlci4NCj4+ID4gW2pqbWJdIHRoaXMgaXMgYWN0dWFsbHkgZGVsaWJlcmF0ZSBhbmQgY29u
c2lkZXJlZCBhIGZlYXR1cmUuICBBbHNvDQo+Pm5vdGUNCj4+ID4gdGhlIEwgYml0IGlzIHNldCB0
byAwIHRvIGZ1cnRoZXIgZW5jb3VyYWdlIHRoZSB1c2Ugb2YgdGhlIGRlZmF1bHQNCj4+Z2F0ZXdh
eQ0KPj4gPiAoV0xBTi1HVykgdG8gZmFjaWxpdGF0ZSBub2RlIHRvIEludGVybmV0IGFuZCBub2Rl
IHRvIG5vZGUNCj4+Y29tbXVuaWNhdGlvbnMuDQo+PiANCj4+IEFFUk8gcHJvdmlkZXMgcm91dGUg
b3B0aW1pemF0aW9uIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50IGFuZCBicm9rZXJlZA0KPj4gYnkg
dGhlIG5ldHdvcmsuIFRoZSBuZXR3b3JrIGNhbiBlaXRoZXIgcGVybWl0IG9yIGRlbnkgcm91dGUg
b3B0aW1pemF0aW9uDQo+PiBhcyBpdCBpcyBjb25maWd1cmVkIHRvIGRvIHNvLCBhbmQgcHJvdmlk
ZXMgYSB0cnVzdCBiYXNpcyBmb3IgY2xpZW50cyB0bw0KPj5lbmdhZ2UNCj4+IGluIHRoZSByb3V0
ZSBvcHRpbWl6YXRpb24uICAoQWxzbyBjaGVjayA2cmQgdGhhdCBwcm92aWRlcyBuYXR1cmFsIHJv
dXRlDQo+PiBvcHRpbWl6YXRpb24gYXMgYSBmdW5kYW1lbnRhbCBhc3BlY3Qgb2YgaXRzIGRlc2ln
bi4pIFJvdXRlIG9wdGltaXphdGlvbg0KPj4gb2ZmbG9hZHMgcGVyZm9ybWFuY2UtY3JpdGljYWwg
aW5mcmFzdHJ1Y3R1cmUgYW5kIHByb3ZpZGVzIGEgYmV0dGVyDQo+PmNsaWVudA0KPj4gdG8gY2xp
ZW50IGV4cGVyaWVuY2UuDQo+PiANCj4+ID4gPlRoZSBhcHByb2FjaCBhbHNvIHN0aWxsIHJlcXVp
cmVzIHRoZSBVRSB0byBkbyBEQUQgb3ZlciB0aGUgaW50ZXJmYWNlDQo+Pml0DQo+PiA+ID5yZWNl
aXZlcyB0aGUgSVB2NiBSQSB3aXRoIFBJTyBmcm9tLg0KPj4gPiBbamptYl0gdGhpcyBjb3VsZCBj
b25jZWl2YWJseSBiZSBvbWl0dGVkIG90aGVyIHRoYW4gdGhlIERBRCBmb3IgdGhlIFVFDQo+PiA+
IGxpbmsgbG9jYWwgYWRkcmVzcy4gIFBlcmhhcHMgd2UgY2FuIG9wdGltaXplIERBRCBieSBzZXR0
aW5nIGFkZGl0aW9uYWwNCj4+ID4gZmxhZ3MgaW4gdGhlIFJBLg0KPj4gDQo+PiBXaGF0IGFkZGl0
aW9uYWwgZmxhZ3Mgd291bGQgeW91IHNldCBpbiB0aGUgUkEgdGhhdCBhbiB1bm1vZGlmaWVkIGhv
c3QNCj4+IHdvdWxkIGJlIGFibGUgdG8gcmVjb2duaXplIGFzIGEgc2lnbmFsIG5vdCB0byBkbyBE
QUQ/DQo+PiANCj4+ID4gPkFwcHJvYWNoZXMgdGhhdCBwcm9wZXJseSBkZWxlZ2F0ZQ0KPj4gPiA+
YW4gSVB2NiBwcmVmaXggKGUuZy4sIERIQ1B2NiBQRCkgZG8gbm90IHJlcXVpcmUgREFEIG92ZXIg
dGhlDQo+PmludGVyZmFjZQ0KPj4gPiA+dGhlIHByZWZpeCBpcyByZWNlaXZlZCBvbiBiZWNhdXNl
IHRoZSBwcmVmaXggaXRzZWxmIG11c3Qgbm90IGJlDQo+PmFzc2lnbmVkDQo+PiA+ID50byB0aGF0
IGludGVyZmFjZS4NCj4+ID4gW2pqbWJdIHRoaXMgaXMgd2hhdCBpcyBwbGFubmVkIGZvciB3aGVu
L2lmIHdlIHN1cHBvcnQgUEQuDQo+PiANCj4+IFBEIGdpdmVzIHRoZSBub2RlIGEgcHJlZml4IHRo
YXQgdGhlIG5ldHdvcmsgY2VydGlmaWVzIHdpbGwgbm90IGJlIGdpdmVuDQo+PiB0byBhbnkgb3Ro
ZXIgbm9kZS4gVGhlIHByZWZpeCBpcyBub3QgdG8gYmUgYXNzaWduZWQgdG8gdGhlIGxpbmsgb3Zl
cg0KPj4gd2hpY2ggaXQgd2FzIHJlY2VpdmVkLCBzbyB0aGVyZSBpcyBubyBuZWVkIHRvIERBRCBm
b3IgYW55IG9mIHRoZQ0KPj4gYWRkcmVzc2VzIGFzc2lnbmVkIGZyb20gdGhlIHByZWZpeC4gQW5k
LCB0aGVyZSBjb3VsZCBiZSBtaWxsaW9ucw0KPj4gb2Ygc3VjaCBhZGRyZXNzZXMuDQo+PiANCj4+
ID4gPiBBbmQsIERIQ1B2NiBQRCBjbGllbnQgaXMgdHJpdmlhbCB0byBpbXBsZW1lbnQgdG9kYXkN
Cj4+ID4gPmFuZCBkb2VzIG5vdCBuZWVkIHRvIGJlIHB1c2hlZCBpbnRvIHRoZSBmYXIgZGlzdGFu
dCBmdXR1cmUuDQo+PiA+IFtqam1iXSB0aGUgaW5jcmVtZW50YWwgbmF0dXJlIG9mIHRoaXMgaGFz
IG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUNCj4+Y2xpZW50LA0KPj4gPiBoYXMgdG8gZG8gd2l0aCB0
d28gdGhpbmdzLiAgMSkgd2UgYXJlIGRvaW5nIHRoaXMgaW5jcmVtZW50YWxseSBhbmQgMikNCj4+
d2UNCj4+ID4gbmVlZCB0byBtYWtlIHN1cmUgdGhlIFdMQU4tR1cgaW1wbGVtZW50YXRpb25zIHN1
cHBvcnQgdGhpcw0KPj51bml2ZXJzYWxseSB0bw0KPj4gPiBhdm9pZCBwYXJ0aWFsIHN1cHBvcnQu
DQo+PiANCj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIG1lYW5pbmcgaGVyZSwgYnV0IHdoYXQg
bWF0dGVycyBpcyBhIHJvYnVzdA0KPj4gYW5kIGFjY2VwdGFibGUgZW5kIHVzZXIgZXhwZXJpZW5j
ZSB0aHJvdWdob3V0IGFsbCByb2xsb3V0IHBoYXNlcy4NCj4+IA0KPj4gPiA+VGhlIGFwcHJvYWNo
IGlzIGFsc28gYSBuZXR3b3JrLWJhc2VkIGFwcHJvYWNoIHVzaW5nIGluLXRoZS1uZXR3b3JrDQo+
PiA+ID50dW5uZWxpbmcsIGJ1dCB0aGVyZSBhcmUgYWxyZWFkeSBtYW55IHNvbHV0aW9ucyB0aGF0
IGRvIHRoaXMNCj4+aW5jbHVkaW5nDQo+PiA+ID5QTUlQdjYsIFByb3h5IEFFUk8sIGFuZCBDQVBX
QVAuIEEgYmV0dGVyIG1vYmlsaXR5IGFuZCByb3V0ZQ0KPj4gPiA+b3B0aW1pemF0aW9uIGV4cGVy
aWVuY2UgaXMgYWxzbyBwb3NzaWJsZSB3aGVuIHRoZSBlbmNhcHN1bGF0aW9uIGlzDQo+PiA+ID5y
ZW1vdmVkIGZyb20gdGhlIG5ldHdvcmsgYW5kIHBsYWNlZCBvbiB0aGUgVUUgc3VjaCBhcyBmb3Ig
Y2xpZW50DQo+PiA+ID5NSVB2NiBhbmQgY2xpZW50IEFFUk8uIEZvciBBRVJPIGluIHBhcnRpY3Vs
YXIsIGl0IGlzIGEgdmVyeSBzaW1wbGUNCj4+YXBwDQo+PiA+ID50aGF0IHJ1bnMgb24gdGhlIFVF
IHRoYXQgY2FuIGJlIGRvd25sb2FkZWQgYW5kIGludm9rZWQgaW4gYSBzaW1pbGFyDQo+PiA+ID5m
YXNoaW9uIGFzIGZvciBWUE4gY2xpZW50cyBsaWtlIE9wZW5WUE4uDQo+PiA+IFtqam1iXSBJIGhh
dmUgbm8gY29udHJvbCBvdmVyIHRoZSBjbGllbnRzIGFzIHN1Y2ggSSBjYW4gbm90IGVuZm9yY2UN
Cj4+dGhlDQo+PiA+IGluc3RhbGxhdGlvbiBvZiBzdWNoIHNvZnR3YXJlLiAgSSBhbSBxdWl0ZSBJ
IHdvdWxkIGdldCBhIHZlcnkNCj4+ZGlmZmVyZW50DQo+PiA+IGZyb20gdGhpcyBjcm93ZCBhbmQg
dGhlIHB1YmxpYyBpbiBnZW5lcmFsIGlmIEkgbWFuZGF0ZWQgYWRkaXRpb25hbA0KPj4gPiBzb2Z0
d2FyZS4NCj4+IA0KPj4gSWYgeW91IGRvbid0IHdhbnQgdG8gY29udHJvbCB0aGUgY2xpZW50cywg
dGhlbiBoYXZlIGEgbG9vayBhdCBQTUlQdjYsDQo+PiBQcm94eSBBRVJPIGFuZC9vciBDQVBXQVAu
DQo+PiANCj4+ID4gPkZpbmFsbHksIEkgYW0gYXNzdW1pbmcgdGhhdCBpbiBsYXJnZSBkZXBsb3lt
ZW50cyB0aGVyZSB3aWxsIGJlIG1hbnkNCj4+ID4gPldMQU4tR1dzIC0gZWFjaCBhc3NvY2lhdGVk
IHdpdGggcG90ZW50aWFsbHkgbWFueSBBUHMuDQo+PiA+IFtqam1iXSB5ZXMgbWFueSBBUHMgdG8g
YSBzaW5nbGUgV0xBTi1HVy4gIE11bHRpcGxlIFdMQU4tR1dzLiAgQW4gQVANCj4+d2lsbA0KPj4g
PiBhc3NvY2lhdGUgdG8gb25lIGFuZCBvbmx5IG9uZSBXTEFOLUdXLg0KPj4gDQo+PiBUaGF0IGlz
IGZpbmUsIGJ1dCB5b3Ugc3RpbGwgbmVlZCB0byBjYXJlIGZvciBtb2JpbGVzIHRoYXQganVtcCBm
cm9tIEFQDQo+PiB0byBBUCBhbmQgaW4gdGhlIHByb2Nlc3MgbWF5IHJvYW0gYmV0d2VlbiBXTEFO
LUdXcy4gVGhhdA0KPj4gcmVxdWlyZXMgYSBtb2JpbGl0eSBtYW5hZ2VtZW50IHNjaGVtZSB0aGF0
IEkgZG8gbm90IHNlZSBpbiB0aGUgZHJhZnQuDQo+PiANCj4+ID4gPkJ1dCwgdGhlcmUNCj4+ID4g
PmlzIG5vIGRpc2N1c3Npb24gb2YgaG93IG5ldHdvcmtpbmcgYmV0d2VlbiB0aGUgV0xBTi1HV3Mg
d2lsbA0KPj4gPiA+b2NjdXIgLSBlc3BlY2lhbGx5IGlmIFVFcyBhcmUgYWxsb3dlZCB0byByb2Ft
IGJldHdlZW4gZGlmZmVyZW50DQo+PiA+ID5XTEFOLUdXcy4NCj4+ID4gW2pqbWJdIGludGVybmV0
d29ya2luZyBiZXR3ZWVuIFVFcyBzZXJ2ZWQgYnkgZGlmZmVyZW50IFdMQU4tR1cgd2lsbCBiZQ0K
Pj4gPiBkb25lIHVzaW5nIGxheWVyIDMgcm91dGluZyBhcyB3ZSBrbm93IGl0IHRvZGF5LCB3aGVy
ZSBhcHBsaWNhYmxlLg0KPj4gDQo+PiBMYXllciAzIHJvdXRpbmcgaG93LCB0aG91Z2g/IElmIHlv
dSBpbmplY3QgbWlsbGlvbnMgdXBvbiBtaWxsaW9ucyBvZg0KPj4gVUUgcHJlZml4ZXMgaW50byB0
aGUgcm91dGluZyBzeXN0ZW0gaXQgaXMgYSByZWNpcGUgZm9yIGRpc2FzdGVyLiBVc2luZw0KPj4g
YSBwcml2YXRlIEJHUCBpbnN0YW5jZSBhcyBzcGVjaWZpZWQgaW4gQUVSTyBpcyBhIHdheSB0byBh
dm9pZCB0aGlzLg0KPj4gDQo+PiA+ID5UaGlzIGlzIGNvdmVyZWQgaW4gZGV0YWlsIGluIEFFUk8g
YW5kIG90aGVyIGFwcHJvYWNoZXMuDQo+PiA+IFtqam1iXSBJIGFtIHN1cmUgQUVSTyBpcyBhIGdy
ZWF0IHNvbHV0aW9uIGZvciB5b3VyIHVzZSBjYXNlLCBob3dldmVyLA0KPj4gPiB0aGVyZSBpcyBs
aXR0bGUgdG8gbm8gb3ZlcmxhcCBmb3Igb3VyIGRlcGxveW1lbnQgb2YgSVB2NiBmb3IgY29tbXVu
aXR5DQo+PiA+IFdpLUZpLg0KPj4gDQo+PiBNYW55IEFFUk8gdXNlIGNhc2VzIGFyZSBleGFtaW5l
ZCBpbiBSRkM2MTM5LCBidXQgdGhlIGxpc3QgdGhlcmUNCj4+IGlzIG5vdCBleGhhdXN0aXZlLiBU
aGUgdXNlIGNhc2UgZGVzY3JpYmVkIGluIHlvdXIgZHJhZnQgaXMgaW5kZWVkDQo+PiBhbm90aGVy
IHVzZSBjYXNlIGZvciBBRVJPLg0KPj4gDQo+PiBUaGFua3MgLSBGcmVkDQo+PiBmcmVkLmwudGVt
cGxpbkBiZW9pbmcuY29tDQo+PiANCj4+ID4gPlRoYW5rcyAtIEZyZWQNCj4+ID4gPmZyZWQubC50
ZW1wbGluQGJvZWluZy5jb20NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+djZvcHMgbWFpbGluZyBsaXN0
DQo+PiA+ID52Nm9wc0BpZXRmLm9yZw0KPj4gPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby92Nm9wcw0KPj4gPiA+DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3Bz
QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz
DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52
Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0K


From nobody Wed Oct 28 03:38:56 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC171A1B62 for ; Wed, 28 Oct 2015 03:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOGLcmCN5Tx0 for ; Wed, 28 Oct 2015 03:38:54 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF381A1B5F for ; Wed, 28 Oct 2015 03:38:53 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=43832 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZrO83-0000mR-AB; Wed, 28 Oct 2015 11:38:51 +0100
Date: Wed, 28 Oct 2015 11:38:51 +0100
From: Tore Anderson 
To: "v6ops@ietf.org" 
Message-ID: <20151028113851.530c649d@echo.ms.redpill-linpro.com>
In-Reply-To: <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 10:38:55 -0000

I've skimmed quickly through this draft.

1) Section 4.2 mentions that DAD is used, but it is not clear to me how
this will work for LLAs. If two UEs (potentially attached to different
APs) are using the same link-local address, how will they see each
others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
not relay DAD messages across the split BUM horizon, how will it deal
with the possiblity of two unique UEs both using the same LLA? I'm
guessing that in a large-scale deployment, the chances of two UEs
having statically configured, e.g., fe80::1 is quite likely.

2) Regarding the following text in Section 4.2:

>   o  M-flag =3D 0 (UE/subscriber address is not managed through DHCPv6),
>      this flag may be set to 1 in the future if/when DHCPv6 prefix
>      delegation support over Wi-Fi is desired)

As I understand it (and I do stress that), the M-flag indicates whether
or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
(IA_PD) is something different. Therefore, assuming that availability of
IA_PD is signalled using RA flags to begin with, then it is "other
configuration" and thus signalled with the O-flag, not the M-flag. I
know of at least one wireline ISP that has such a deployment, i.e.,
they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
using M=3D0 + O=3D1.

3) The draft describes tunneling traffic in a stateless manner. I take
that to mean that the APs and WLAN-GW will be incapable of performing
reassembly at tunnel egress (and by extension that they won't fragment
GRE packets on ingress either). That in turn means that you either 1)
need to allow for jumbo frames in the transport network between the
WLAN-GW and the APs, or 2) provide UEs with a reduced MTU (which
implies the RA MTU option should be used and possibly also TCP-MSS
clamping at the WLAN-GW). Since this is an operational guidance
document I believe this is something that should be discussed.

4) Is UE roaming between APs/BSSIDs supported, and if so how does this
work? As I understand it, the WLAN-GW will have 1 GRE interface per AP,
so if a UE roams from one AP to another, its MAC address and all of its
associated IPv6 addresses will (from the WLAN-GW's POV) move from one
GRE interface to another, which would in turn require the WLAN-GW to
somehow notice this and move the associated /64 and any NDP entries
from the previous GRE interface to the current one. Right? If so, some
discussion on how that happens would be appreciated (or at least a
statement that "secret vendor sauce is assumed to be applied here" if
that is indeed the case).

5) This is just a thought, but regarding the operational consideration
in section 5 regarding supporting privacy addresses: Would it be
possible for the WLAN-GW to simply send all traffic destined for the
UE's dedicated /64 to the UE's MAC address without maintaining ND
entries for each address in use? This way, a single UE could use
gazillions of IPv6 addresses without risking resource exhaustion in the
WLAN-GW. OTOH, maybe that would cause problems for UEs that are
providing tethering to downstream hosts using layer-2 bridging?

6) Some editorial nits I noticed (although I wasn't specifically
looking for them): Missing =C2=AB.=C2=BB at the end of page 7, s/Lawfull/La=
wful/
on page 12.

Tore


From nobody Wed Oct 28 03:44:17 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8911A6F84 for ; Wed, 28 Oct 2015 03:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level: 
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JKji99JjAEF for ; Wed, 28 Oct 2015 03:44:14 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8091A6F81 for ; Wed, 28 Oct 2015 03:44:13 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9SAiBmX019457 for ; Wed, 28 Oct 2015 11:44:11 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 326DC2048C4 for ; Wed, 28 Oct 2015 11:50:01 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C8E02048C1 for ; Wed, 28 Oct 2015 11:50:01 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9SAiAS6011777 for ; Wed, 28 Oct 2015 11:44:11 +0100
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com>
From: Alexandre Petrescu 
Message-ID: <5630A6FA.9020602@gmail.com>
Date: Wed, 28 Oct 2015 11:44:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 10:44:16 -0000

Le 27/10/2015 18:17, Templin, Fred L a écrit :
> No popular operating system currently implements DHCPv6 PD on wifi,
> and even if they all implemented it tomorrow, it would take years
> before a substantial number of devices supported it.
>
> Actually, forget my little homegrown app – ISC DHCP client already
> has
>
> DHCPv6 PD and runs on a number of OSes. Am I missing the point?

Absolutely not.

It is reasonable to expect community devices to be pre-installed with
DHCP-PD clients by the operator. Or otherwise the owners to download
DHCP-PD as part of a 'community advanced tethering' application from a
store.

We can ask the operator to show the IPv6 addressing architecture laid on
the operator topology, substituting "2001:db8::" where necessary.  I
suppose this will help.

Alex


>
> Thanks – Fred
>
> fred.l.templin@boeing.com
>
> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Templin,
> Fred L *Sent:* Tuesday, October 27, 2015 8:11 AM *To:* Lorenzo
> Colitti; Mark Smith *Cc:* v6ops@ietf.org; 神明é”哉; Brzozowski, John
> *Subject:* Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action:
>  draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
>
> Hi Lorenzo,
>
> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Lorenzo
> Colitti *Sent:* Tuesday, October 27, 2015 4:24 AM *To:* Mark Smith
> *Cc:* 神明é”哉; v6ops@ietf.org ; Brzozowski, John
> *Subject:* Re: [v6ops] how /63 helps tethering (was: Fwd: I-D Action:
>  draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt)
>
> On Fri, Oct 23, 2015 at 5:55 PM, Mark Smith  > wrote:
>
> Does code exist that already does this? If it doesn't, why wouldn't
> it be better to implement DHCPv6-PD, the existing, tested and proven
> mechanism to do this sort of thing?
>
> Because this is an operational working group, and the document
> describes an operational solution.
>
> No popular operating system currently implements DHCPv6 PD on wifi,
> and even if they all implemented it tomorrow, it would take years
> before a substantial number of devices supported it.
>
> I have a DHCPv6 PD app running on Android today. It is really just a
> few client-side
>
> messages, and then you get a prefix for provisioning addresses and/or
>  for further
>
> sub-delegation.
>
> Thanks – Fred
>
> fred.l.templin@boeing.com 
>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Wed Oct 28 08:49:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3690E1A8AC2 for ; Wed, 28 Oct 2015 08:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiaVUzQ2IxRA for ; Wed, 28 Oct 2015 08:49:42 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE111A8AA6 for ; Wed, 28 Oct 2015 08:49:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9SFnhL5031174; Wed, 28 Oct 2015 08:49:43 -0700
Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9SFnaRr030993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 Oct 2015 08:49:36 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.77]) with mapi id 14.03.0235.001; Wed, 28 Oct 2015 08:49:34 -0700
From: "Templin, Fred L" 
To: Tore Anderson , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREWzV/+MZsnq7pUCTitCxpFGwKp6BBjxg
Date: Wed, 28 Oct 2015 15:49:33 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F31F9B@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>
In-Reply-To: <20151028113851.530c649d@echo.ms.redpill-linpro.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 15:49:44 -0000

SGkgVG9yZSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBb
bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb3JlIEFuZGVyc29u
DQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyOCwgMjAxNSAzOjM5IEFNDQo+IFRvOiB2Nm9w
c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0
LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTAwLnR4dA0KPiANCj4gSSd2
ZSBza2ltbWVkIHF1aWNrbHkgdGhyb3VnaCB0aGlzIGRyYWZ0Lg0KPiANCj4gMSkgU2VjdGlvbiA0
LjIgbWVudGlvbnMgdGhhdCBEQUQgaXMgdXNlZCwgYnV0IGl0IGlzIG5vdCBjbGVhciB0byBtZSBo
b3cNCj4gdGhpcyB3aWxsIHdvcmsgZm9yIExMQXMuIElmIHR3byBVRXMgKHBvdGVudGlhbGx5IGF0
dGFjaGVkIHRvIGRpZmZlcmVudA0KPiBBUHMpIGFyZSB1c2luZyB0aGUgc2FtZSBsaW5rLWxvY2Fs
IGFkZHJlc3MsIGhvdyB3aWxsIHRoZXkgc2VlIGVhY2gNCj4gb3RoZXJzIERBRCBtZXNzYWdlcz8g
UHJveHktTkQgb24gdGhlIFdMQU4tR1c/IE9yIGlmIHRoZSBXTEFOLUdXIGRvZXMNCj4gbm90IHJl
bGF5IERBRCBtZXNzYWdlcyBhY3Jvc3MgdGhlIHNwbGl0IEJVTSBob3Jpem9uLCBob3cgd2lsbCBp
dCBkZWFsDQo+IHdpdGggdGhlIHBvc3NpYmxpdHkgb2YgdHdvIHVuaXF1ZSBVRXMgYm90aCB1c2lu
ZyB0aGUgc2FtZSBMTEE/IEknbQ0KPiBndWVzc2luZyB0aGF0IGluIGEgbGFyZ2Utc2NhbGUgZGVw
bG95bWVudCwgdGhlIGNoYW5jZXMgb2YgdHdvIFVFcw0KPiBoYXZpbmcgc3RhdGljYWxseSBjb25m
aWd1cmVkLCBlLmcuLCBmZTgwOjoxIGlzIHF1aXRlIGxpa2VseS4NCg0KRm9yIHByb3Blcmx5IGRl
bGVnYXRlZCBwcmVmaXhlcyAoaS5lLiwgcHJlZml4ZXMgdGhhdCBhcmUgZ3JhbnRlZCBieSB0aGUN
Cm5ldHdvcmsgZm9yIHRoZSBVRSdzIGV4Y2x1c2l2ZSB1c2UpLCBEQUQgb3ZlciB0aGUgbGluayBv
dmVyIHdoaWNoIHRoZQ0KcHJlZml4IHdhcyByZWNlaXZlZCBpcyBub3QgbmVjZXNzYXJ5LiBJZiB0
aGUgcHJlZml4IHdhcyBhZHZlcnRpc2VkIHRvDQptdWx0aXBsZSBVRXMsIHRoZW4gREFEIHdvdWxk
IHN0aWxsIGJlIHJlcXVpcmVkLg0KDQpUaGUgdHJvdWJsZSB3aXRoIChBPTE7IEw9MCkgaW4gUElP
IGFkdmVydGlzZW1lbnRzIGlzIHRoYXQgdGhlcmUgaXMNCm5vIHdheSBmb3IgYW4gdW5tb2RpZmll
ZCBVRSB0byBrbm93IHdoZXRoZXIgdGhlIHByZWZpeCBpcyBiZWluZw0KZ3JhbnRlZCBieSB0aGUg
bmV0d29yayBmb3IgaXRzIGV4Y2x1c2l2ZSB1c2UuIFJGQzQ4NjEgc2F5cyB0aGF0DQpMPTAgb25s
eSBtZWFucyB0aGF0IHRoZXJlIGlzICJubyBzdGF0ZW1lbnQgYWJvdXQgb24tbGluayBvciBvZmYt
bGluaw0KcHJvcGVydGllcyBvZiB0aGUgcHJlZml4Ii4gSXQgaXMgdGhlcmVmb3JlIHVucmVhc29u
YWJsZSBmb3IgdGhlIFVFDQp0byBhc3N1bWUgdGhhdCB0aGUgcHJlZml4IGlzIGJlaW5nIGdyYW50
ZWQgZm9yIGl0cyBleGNsdXNpdmUgdXNlLg0KDQo+IDIpIFJlZ2FyZGluZyB0aGUgZm9sbG93aW5n
IHRleHQgaW4gU2VjdGlvbiA0LjI6DQo+IA0KPiA+ICAgbyAgTS1mbGFnID0gMCAoVUUvc3Vic2Ny
aWJlciBhZGRyZXNzIGlzIG5vdCBtYW5hZ2VkIHRocm91Z2ggREhDUHY2KSwNCj4gPiAgICAgIHRo
aXMgZmxhZyBtYXkgYmUgc2V0IHRvIDEgaW4gdGhlIGZ1dHVyZSBpZi93aGVuIERIQ1B2NiBwcmVm
aXgNCj4gPiAgICAgIGRlbGVnYXRpb24gc3VwcG9ydCBvdmVyIFdpLUZpIGlzIGRlc2lyZWQpDQo+
IA0KPiBBcyBJIHVuZGVyc3RhbmQgaXQgKGFuZCBJIGRvIHN0cmVzcyB0aGF0KSwgdGhlIE0tZmxh
ZyBpbmRpY2F0ZXMgd2hldGhlcg0KPiBvciBub3QgKmFkZHJlc3NlcyogYXJlIGF2YWlsYWJsZSB2
aWEgREhDUHY2IChSRkMgNDg2MSBzNC4yKS4gUHJlZml4ZXMNCj4gKElBX1BEKSBpcyBzb21ldGhp
bmcgZGlmZmVyZW50LiBUaGVyZWZvcmUsIGFzc3VtaW5nIHRoYXQgYXZhaWxhYmlsaXR5IG9mDQo+
IElBX1BEIGlzIHNpZ25hbGxlZCB1c2luZyBSQSBmbGFncyB0byBiZWdpbiB3aXRoLCB0aGVuIGl0
IGlzICJvdGhlcg0KPiBjb25maWd1cmF0aW9uIiBhbmQgdGh1cyBzaWduYWxsZWQgd2l0aCB0aGUg
Ty1mbGFnLCBub3QgdGhlIE0tZmxhZy4gSQ0KPiBrbm93IG9mIGF0IGxlYXN0IG9uZSB3aXJlbGlu
ZSBJU1AgdGhhdCBoYXMgc3VjaCBhIGRlcGxveW1lbnQsIGkuZS4sDQo+IHRoZXkgc3VwcG9ydCBE
SENQdjYgSUFfUEQgYnV0IG5vdCBJQV9OQS9JQV9UQSwgYW5kIHRoZXkgc2lnbmFsIHRoaXMNCj4g
dXNpbmcgTT0wICsgTz0xLg0KDQpUaGlzIHN1cnByaXNlcyBtZSwgYnV0IEknbGwgdGFrZSB5b3Vy
IHdvcmQgZm9yIGl0LiBIb3dldmVyLCBvbiBzb21lIGxpbmtzDQpzdWNoIGFzIEFFUk8gaXQgc2hv
dWxkIGJlIHBvc3NpYmxlIHRvIGRvIERIQ1B2NiBQRCB3aXRob3V0IGZpcnN0IHJlY2VpdmluZw0K
YW4gUkEuDQoNCj4gMykgVGhlIGRyYWZ0IGRlc2NyaWJlcyB0dW5uZWxpbmcgdHJhZmZpYyBpbiBh
IHN0YXRlbGVzcyBtYW5uZXIuIEkgdGFrZQ0KPiB0aGF0IHRvIG1lYW4gdGhhdCB0aGUgQVBzIGFu
ZCBXTEFOLUdXIHdpbGwgYmUgaW5jYXBhYmxlIG9mIHBlcmZvcm1pbmcNCj4gcmVhc3NlbWJseSBh
dCB0dW5uZWwgZWdyZXNzIChhbmQgYnkgZXh0ZW5zaW9uIHRoYXQgdGhleSB3b24ndCBmcmFnbWVu
dA0KPiBHUkUgcGFja2V0cyBvbiBpbmdyZXNzIGVpdGhlcikuIFRoYXQgaW4gdHVybiBtZWFucyB0
aGF0IHlvdSBlaXRoZXIgMSkNCj4gbmVlZCB0byBhbGxvdyBmb3IganVtYm8gZnJhbWVzIGluIHRo
ZSB0cmFuc3BvcnQgbmV0d29yayBiZXR3ZWVuIHRoZQ0KPiBXTEFOLUdXIGFuZCB0aGUgQVBzLCBv
ciAyKSBwcm92aWRlIFVFcyB3aXRoIGEgcmVkdWNlZCBNVFUgKHdoaWNoDQo+IGltcGxpZXMgdGhl
IFJBIE1UVSBvcHRpb24gc2hvdWxkIGJlIHVzZWQgYW5kIHBvc3NpYmx5IGFsc28gVENQLU1TUw0K
PiBjbGFtcGluZyBhdCB0aGUgV0xBTi1HVykuIFNpbmNlIHRoaXMgaXMgYW4gb3BlcmF0aW9uYWwg
Z3VpZGFuY2UNCj4gZG9jdW1lbnQgSSBiZWxpZXZlIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgc2hv
dWxkIGJlIGRpc2N1c3NlZC4NCg0KRG9jdW1lbnRzIHRoYXQgZGlzY3VzcyB0dW5uZWwgZnJhZ21l
bnRhdGlvbiBhcmUgUkZDNzY3NiwgDQpkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscywgYW5kIEFF
Uk8uIEFsc28sIENBUFdBUCBkb2VzIGZyYWdtZW50YXRpb24NCmFuZCByZWFzc2VtYmx5IHRvIGVu
c3VyZSBzdWZmaWNpZW50IE1UVSwgYW5kIEkgYW0gbm90IHlldCBjb252aW5jZWQNCnRoYXQgSm9o
bidzIHVzZSBjYXNlIGNhbm5vdCBiZSBzYXRpc2ZpZWQgYnkgQ0FQV0FQLg0KDQpGcmFnbWVudGF0
aW9uIG5lZWQgb25seSBiZSBhcHBsaWVkIGluIHRoZSBwYXRoIGZyb20gdGhlIFdMQU4tR1cNCnRv
IHRoZSBBUCwgYW5kIG5vdCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uIFRoaXMgaXMgYmVjYXVz
ZSB0aGUgQVAgY2FuDQpzaWduYWwgYSByZWR1Y2VkIE1UVSB0byB0aGUgVUVzIHdpdGhvdXQgcmlz
ayBvZiBQTVRVRCBmYWlsdXJlcy4NCg0KPiA0KSBJcyBVRSByb2FtaW5nIGJldHdlZW4gQVBzL0JT
U0lEcyBzdXBwb3J0ZWQsIGFuZCBpZiBzbyBob3cgZG9lcyB0aGlzDQo+IHdvcms/IEFzIEkgdW5k
ZXJzdGFuZCBpdCwgdGhlIFdMQU4tR1cgd2lsbCBoYXZlIDEgR1JFIGludGVyZmFjZSBwZXIgQVAs
DQo+IHNvIGlmIGEgVUUgcm9hbXMgZnJvbSBvbmUgQVAgdG8gYW5vdGhlciwgaXRzIE1BQyBhZGRy
ZXNzIGFuZCBhbGwgb2YgaXRzDQo+IGFzc29jaWF0ZWQgSVB2NiBhZGRyZXNzZXMgd2lsbCAoZnJv
bSB0aGUgV0xBTi1HVydzIFBPVikgbW92ZSBmcm9tIG9uZQ0KPiBHUkUgaW50ZXJmYWNlIHRvIGFu
b3RoZXIsIHdoaWNoIHdvdWxkIGluIHR1cm4gcmVxdWlyZSB0aGUgV0xBTi1HVyB0bw0KPiBzb21l
aG93IG5vdGljZSB0aGlzIGFuZCBtb3ZlIHRoZSBhc3NvY2lhdGVkIC82NCBhbmQgYW55IE5EUCBl
bnRyaWVzDQo+IGZyb20gdGhlIHByZXZpb3VzIEdSRSBpbnRlcmZhY2UgdG8gdGhlIGN1cnJlbnQg
b25lLiBSaWdodD8gSWYgc28sIHNvbWUNCj4gZGlzY3Vzc2lvbiBvbiBob3cgdGhhdCBoYXBwZW5z
IHdvdWxkIGJlIGFwcHJlY2lhdGVkIChvciBhdCBsZWFzdCBhDQo+IHN0YXRlbWVudCB0aGF0ICJz
ZWNyZXQgdmVuZG9yIHNhdWNlIGlzIGFzc3VtZWQgdG8gYmUgYXBwbGllZCBoZXJlIiBpZg0KPiB0
aGF0IGlzIGluZGVlZCB0aGUgY2FzZSkuDQoNClRoaXMgaXMgdGhlIHNhbWUgcXVlc3Rpb24gSSBh
c2tlZCBhYm91dCBtb2JpbGl0eSBhbmQgcm91dGUgb3B0aW1pemF0aW9uLA0KYW5kIHdoZXJlIEkg
cmVhbGl6ZWQgdGhhdCBJIG5lZWRlZCB0byBiYWNrIG9mZiBhbmQgYnVtcCB1cCB0byBhIGhpZ2hl
cg0KbGV2ZWwuIFRoZSBwcm9ibGVtIGlzIHRoYXQgd2UganVzdCBkb27igJl0IHVuZGVyc3RhbmQg
ZW5vdWdoIGFib3V0DQpKb2huJ3MgdXNlIGNhc2UgKHlldCkgdG8ga25vdyB3aGV0aGVyIG9yIG5v
dCBmdWxsIG1vYmlsaXR5IG1hbmFnZW1lbnQNCndpbGwgYmUgaW1wb3J0YW50LCBvciB3aGV0aGVy
IHNvbWUgbGltaXRlZCBmb3JtIG9mIG1vYmlsaXR5IHN1cHBvcnQNCihvciBubyBzdXBwb3J0IGF0
IGFsKSB3aWxsIGJlIHN1ZmZpY2llbnQuIEkgdGhpbmsgSm9obidzIHVzZSBjYXNlIG5lZWRzDQpt
dWNoIG1vcmUgdGhvcm91Z2ggZGlzY3Vzc2lvbiBiZWZvcmUgYW55IHBhcnRpY3VsYXIgc29sdXRp
b24gY2FuDQpiZSBhcHBsaWVkLg0KDQo+IDUpIFRoaXMgaXMganVzdCBhIHRob3VnaHQsIGJ1dCBy
ZWdhcmRpbmcgdGhlIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb24NCj4gaW4gc2VjdGlvbiA1IHJl
Z2FyZGluZyBzdXBwb3J0aW5nIHByaXZhY3kgYWRkcmVzc2VzOiBXb3VsZCBpdCBiZQ0KPiBwb3Nz
aWJsZSBmb3IgdGhlIFdMQU4tR1cgdG8gc2ltcGx5IHNlbmQgYWxsIHRyYWZmaWMgZGVzdGluZWQg
Zm9yIHRoZQ0KPiBVRSdzIGRlZGljYXRlZCAvNjQgdG8gdGhlIFVFJ3MgTUFDIGFkZHJlc3Mgd2l0
aG91dCBtYWludGFpbmluZyBORA0KPiBlbnRyaWVzIGZvciBlYWNoIGFkZHJlc3MgaW4gdXNlPyBU
aGlzIHdheSwgYSBzaW5nbGUgVUUgY291bGQgdXNlDQo+IGdhemlsbGlvbnMgb2YgSVB2NiBhZGRy
ZXNzZXMgd2l0aG91dCByaXNraW5nIHJlc291cmNlIGV4aGF1c3Rpb24gaW4gdGhlDQo+IFdMQU4t
R1cuIE9UT0gsIG1heWJlIHRoYXQgd291bGQgY2F1c2UgcHJvYmxlbXMgZm9yIFVFcyB0aGF0IGFy
ZQ0KPiBwcm92aWRpbmcgdGV0aGVyaW5nIHRvIGRvd25zdHJlYW0gaG9zdHMgdXNpbmcgbGF5ZXIt
MiBicmlkZ2luZz8NCg0KT25seSBpZiB0aGUgcHJlZml4IGlzIHByb3Blcmx5IGRlbGVnYXRlZCB0
byB0aGUgVUUsIHN1Y2ggYXMgd2l0aA0KREhDUHY2IFBELg0KDQpUaGFua3MgLSBGcmVkDQpmcmVk
LmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gNikgU29tZSBlZGl0b3JpYWwgbml0cyBJIG5vdGlj
ZWQgKGFsdGhvdWdoIEkgd2Fzbid0IHNwZWNpZmljYWxseQ0KPiBsb29raW5nIGZvciB0aGVtKTog
TWlzc2luZyDCqy7CuyBhdCB0aGUgZW5kIG9mIHBhZ2UgNywgcy9MYXdmdWxsL0xhd2Z1bC8NCj4g
b24gcGFnZSAxMi4NCj4gDQo+IFRvcmUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRm
Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo=


From nobody Wed Oct 28 09:05:30 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BFF1A8BB3 for ; Wed, 28 Oct 2015 09:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPiq4q7LgMZq for ; Wed, 28 Oct 2015 09:05:28 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7ED01A90FB for ; Wed, 28 Oct 2015 09:03:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9SG3l8x004289; Wed, 28 Oct 2015 11:03:47 -0500
Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9SG3j63004267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 Oct 2015 11:03:45 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.51]) with mapi id 14.03.0235.001; Wed, 28 Oct 2015 09:03:45 -0700
From: "Templin, Fred L" 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] how /63 helps tethering
Thread-Index: AQHREZo4S1VysLkjKU+J4tBqEGgHhw==
Date: Wed, 28 Oct 2015 16:03:44 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F31FFF@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com> <5630A6FA.9020602@gmail.com>
In-Reply-To: <5630A6FA.9020602@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] how /63 helps tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 16:05:30 -0000

SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBb
bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0
cmVzY3UNCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI4LCAyMDE1IDM6NDQgQU0NCj4gVG86
IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGhvdyAvNjMgaGVscHMgdGV0
aGVyaW5nDQo+IA0KPiANCj4gDQo+IExlIDI3LzEwLzIwMTUgMTg6MTcsIFRlbXBsaW4sIEZyZWQg
TCBhIMOpY3JpdCA6DQo+ID4gTm8gcG9wdWxhciBvcGVyYXRpbmcgc3lzdGVtIGN1cnJlbnRseSBp
bXBsZW1lbnRzIERIQ1B2NiBQRCBvbiB3aWZpLA0KPiA+IGFuZCBldmVuIGlmIHRoZXkgYWxsIGlt
cGxlbWVudGVkIGl0IHRvbW9ycm93LCBpdCB3b3VsZCB0YWtlIHllYXJzDQo+ID4gYmVmb3JlIGEg
c3Vic3RhbnRpYWwgbnVtYmVyIG9mIGRldmljZXMgc3VwcG9ydGVkIGl0Lg0KPiA+DQo+ID4gQWN0
dWFsbHksIGZvcmdldCBteSBsaXR0bGUgaG9tZWdyb3duIGFwcCDigJMgSVNDIERIQ1AgY2xpZW50
IGFscmVhZHkNCj4gPiBoYXMNCj4gPg0KPiA+IERIQ1B2NiBQRCBhbmQgcnVucyBvbiBhIG51bWJl
ciBvZiBPU2VzLiBBbSBJIG1pc3NpbmcgdGhlIHBvaW50Pw0KPiANCj4gQWJzb2x1dGVseSBub3Qu
DQo+IA0KPiBJdCBpcyByZWFzb25hYmxlIHRvIGV4cGVjdCBjb21tdW5pdHkgZGV2aWNlcyB0byBi
ZSBwcmUtaW5zdGFsbGVkIHdpdGgNCj4gREhDUC1QRCBjbGllbnRzIGJ5IHRoZSBvcGVyYXRvci4g
T3Igb3RoZXJ3aXNlIHRoZSBvd25lcnMgdG8gZG93bmxvYWQNCj4gREhDUC1QRCBhcyBwYXJ0IG9m
IGEgJ2NvbW11bml0eSBhZHZhbmNlZCB0ZXRoZXJpbmcnIGFwcGxpY2F0aW9uIGZyb20gYQ0KPiBz
dG9yZS4NCg0KVGhpcyBnb2VzIGJhY2sgdG8gdGhlIHBvaW50IGFib3V0IGluc3VmZmljaWVudCBp
bmZvcm1hdGlvbiBhYm91dCBKb2huJ3MNCnVzZSBjYXNlLiBEb2VzIGhpcyB1c2UgY2FzZSBleHBl
Y3QgY29tcGxldGVseSB1bm1vZGlmaWVkIENPVFMgVUVzDQpzdWNoIGFzIHRoZSBlbmQgdXNlciB3
b3VsZCBidXkgYXQgYSBjb25zdW1lciBlbGVjdHJvbmljcyBzdG9yZT8gT3IsDQp3aWxsIHRoZXJl
IGJlIG9wcG9ydHVuaXR5IHRvIGluc3RhbGwgYSBzbWFsbCBwaWVjZSBvZiBzb2Z0d2FyZSwgZWl0
aGVyDQpieSB0aGUgb3BlcmF0b3Igb3IgZGlyZWN0bHkgYnkgdGhlIGVuZCB1c2VyPyBXZSBzaW1w
bHkgZG9uJ3Qga25vdw0KZW5vdWdoIGFib3V0IHRoZSB1c2UgY2FzZSwgYW5kIEkgd291bGQgZW5j
b3VyYWdlIEpvaG4gdG8gcHJvdmlkZQ0KbW9yZSBkZXRhaWxzLg0KDQo+IFdlIGNhbiBhc2sgdGhl
IG9wZXJhdG9yIHRvIHNob3cgdGhlIElQdjYgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgbGFpZCBv
bg0KPiB0aGUgb3BlcmF0b3IgdG9wb2xvZ3ksIHN1YnN0aXR1dGluZyAiMjAwMTpkYjg6OiIgd2hl
cmUgbmVjZXNzYXJ5LiAgSQ0KPiBzdXBwb3NlIHRoaXMgd2lsbCBoZWxwLg0KDQpUaGUgb3BlcmF0
b3IncyBzZXJ2aWNlIHByZWZpeCAoZS5nLiwgYSAvMzIgb3Igc29tZXRoaW5nKSBzaG91bGQgYmUg
d2VsbA0Ka25vd24uIFVFIHByZWZpeGVzIHNob3VsZCBiZSBkZXJpdmVkIGZyb20gdGhlIHNlcnZp
Y2UgcHJlZml4IGFuZA0KZGVsZWdhdGVkIGFjY29yZGluZyB0byB0aGUgVUUncyBuZWVkcywgYW5k
IG5vdCBuZWNlc3NhcmlseSBib3VuZA0KdG8gdGhlIG9wZXJhdG9yJ3MgdG9wb2xvZ3kuDQoNClRo
YW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBBbGV4DQo+IA0KPiAN
Cj4gPg0KPiA+IFRoYW5rcyDigJMgRnJlZA0KPiA+DQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5n
LmNvbQ0KPiA+DQo+ID4gKkZyb206KnY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y
Z10gKk9uIEJlaGFsZiBPZiAqVGVtcGxpbiwNCj4gPiBGcmVkIEwgKlNlbnQ6KiBUdWVzZGF5LCBP
Y3RvYmVyIDI3LCAyMDE1IDg6MTEgQU0gKlRvOiogTG9yZW56bw0KPiA+IENvbGl0dGk7IE1hcmsg
U21pdGggKkNjOiogdjZvcHNAaWV0Zi5vcmc7IOelnuaYjumBlOWTiTsgQnJ6b3pvd3NraSwgSm9o
bg0KPiA+ICpTdWJqZWN0OiogUmU6IFt2Nm9wc10gaG93IC82MyBoZWxwcyB0ZXRoZXJpbmcgKHdh
czogRndkOiBJLUQgQWN0aW9uOg0KPiA+ICBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXBy
ZWZpeC1wZXItaG9zdC0wMC50eHQpDQo+ID4NCj4gPiBIaSBMb3JlbnpvLA0KPiA+DQo+ID4gKkZy
b206KnY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAq
TG9yZW56bw0KPiA+IENvbGl0dGkgKlNlbnQ6KiBUdWVzZGF5LCBPY3RvYmVyIDI3LCAyMDE1IDQ6
MjQgQU0gKlRvOiogTWFyayBTbWl0aA0KPiA+ICpDYzoqIOelnuaYjumBlOWTiTsgdjZvcHNAaWV0
Zi5vcmcgPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IEJyem96b3dza2ksIEpvaG4NCj4gPiAqU3Vi
amVjdDoqIFJlOiBbdjZvcHNdIGhvdyAvNjMgaGVscHMgdGV0aGVyaW5nICh3YXM6IEZ3ZDogSS1E
IEFjdGlvbjoNCj4gPiAgZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv
c3QtMDAudHh0KQ0KPiA+DQo+ID4gT24gRnJpLCBPY3QgMjMsIDIwMTUgYXQgNTo1NSBQTSwgTWFy
ayBTbWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbQ0KPiA+IDxtYWlsdG86bWFya3p6enNtaXRo
QGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gRG9lcyBjb2RlIGV4aXN0IHRoYXQgYWxyZWFk
eSBkb2VzIHRoaXM/IElmIGl0IGRvZXNuJ3QsIHdoeSB3b3VsZG4ndA0KPiA+IGl0IGJlIGJldHRl
ciB0byBpbXBsZW1lbnQgREhDUHY2LVBELCB0aGUgZXhpc3RpbmcsIHRlc3RlZCBhbmQgcHJvdmVu
DQo+ID4gbWVjaGFuaXNtIHRvIGRvIHRoaXMgc29ydCBvZiB0aGluZz8NCj4gPg0KPiA+IEJlY2F1
c2UgdGhpcyBpcyBhbiBvcGVyYXRpb25hbCB3b3JraW5nIGdyb3VwLCBhbmQgdGhlIGRvY3VtZW50
DQo+ID4gZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIHNvbHV0aW9uLg0KPiA+DQo+ID4gTm8gcG9w
dWxhciBvcGVyYXRpbmcgc3lzdGVtIGN1cnJlbnRseSBpbXBsZW1lbnRzIERIQ1B2NiBQRCBvbiB3
aWZpLA0KPiA+IGFuZCBldmVuIGlmIHRoZXkgYWxsIGltcGxlbWVudGVkIGl0IHRvbW9ycm93LCBp
dCB3b3VsZCB0YWtlIHllYXJzDQo+ID4gYmVmb3JlIGEgc3Vic3RhbnRpYWwgbnVtYmVyIG9mIGRl
dmljZXMgc3VwcG9ydGVkIGl0Lg0KPiA+DQo+ID4gSSBoYXZlIGEgREhDUHY2IFBEIGFwcCBydW5u
aW5nIG9uIEFuZHJvaWQgdG9kYXkuIEl0IGlzIHJlYWxseSBqdXN0IGENCj4gPiBmZXcgY2xpZW50
LXNpZGUNCj4gPg0KPiA+IG1lc3NhZ2VzLCBhbmQgdGhlbiB5b3UgZ2V0IGEgcHJlZml4IGZvciBw
cm92aXNpb25pbmcgYWRkcmVzc2VzIGFuZC9vcg0KPiA+ICBmb3IgZnVydGhlcg0KPiA+DQo+ID4g
c3ViLWRlbGVnYXRpb24uDQo+ID4NCj4gPiBUaGFua3Mg4oCTIEZyZWQNCj4gPg0KPiA+IGZyZWQu
bC50ZW1wbGluQGJvZWluZy5jb20gPG1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPg0K
PiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0KPiANCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs
aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdjZvcHMNCg==


From nobody Wed Oct 28 10:54:56 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F651B5B58 for ; Wed, 28 Oct 2015 10:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqwQtuZWARvr for ; Wed, 28 Oct 2015 10:54:53 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A093F1B5B53 for ; Wed, 28 Oct 2015 10:54:53 -0700 (PDT)
Received: by igdg1 with SMTP id g1so113152708igd.1 for ; Wed, 28 Oct 2015 10:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cFvumT4NEdudqo7T2LrRoOwCZ7Hi+Hn2RscoT4wtB/I=; b=ze5+pQVPfKCo7/HWTHv+0b8mRhcm3B8MO7HrYYTaQEEyLNK6NLl1nKOd7VPKrEEx7+ 8SUkuOw47gQDeeG5YGJDbhcOsWQ3wamQ14N7t/tlfgz2C0KKbDkiltGfZggtIPLCaqzE 2j6TPe+dUFUlINkRlChpBpb3704sSdXYkuhgJwHw9DDOaxv4kupjr3dV+TGWDf0yL5lK SbmOZXzjOOE67ijh7ATX1MwkbtcyLzoscQN6g3mWgNhFXQljiz1XS4UxRpuD6D2avBlG MnFfSCO4WPtWe5BdBwy0YdMXrbowfmR+ABgWvTVp8cB3IQ3idSI7WytCrPzYUiSgNLDP yhDQ==
MIME-Version: 1.0
X-Received: by 10.50.43.161 with SMTP id x1mr4425151igl.64.1446054893051; Wed, 28 Oct 2015 10:54:53 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Wed, 28 Oct 2015 10:54:52 -0700 (PDT)
In-Reply-To: <20151028113851.530c649d@echo.ms.redpill-linpro.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>
Date: Wed, 28 Oct 2015 10:54:52 -0700
X-Google-Sender-Auth: 1QyRJjzHvQlRdKV9OITVlP3G4ec
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Tore Anderson 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 17:54:55 -0000

At Wed, 28 Oct 2015 11:38:51 +0100,
Tore Anderson  wrote:

> As I understand it (and I do stress that), the M-flag indicates whether
> or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
> (IA_PD) is something different. Therefore, assuming that availability of
> IA_PD is signalled using RA flags to begin with, then it is "other
> configuration" and thus signalled with the O-flag, not the M-flag. I
> know of at least one wireline ISP that has such a deployment, i.e.,
> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
> using M=0 + O=1.

Interesting point.  Personally I've been assuming that the O-flag
being on implies (if anything) a "stateless" DHCPv6 service.  That's
significant in this context, since the client would send an
Information-request message for stateless services, while prefix
delegation requires a DHCPv6 session beginning with a Solicit message.
I'm not sure how widely my assumption is shared, but, in any case,
the specifications are actually unclear as you indicated above.

(And, of course, there is another level of issue that the semantics of
MO flags is too unclear in general in the first place...)

--
JINMEI, Tatuya


From nobody Wed Oct 28 11:21:59 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9CE1ACD60 for ; Wed, 28 Oct 2015 11:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.711
X-Spam-Level: 
X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-t8X3os6qj2 for ; Wed, 28 Oct 2015 11:21:57 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9081ACD46 for ; Wed, 28 Oct 2015 11:21:57 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EF2FBD788E; Wed, 28 Oct 2015 11:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=itcPg4BwG3RuG6q2hKwxBQiaJRE=; b= LURCgIgWXSqVyGKvAVobi6MDlktzlV46UGa8Z/KA3fDd/oV132gIy5bDpRXU/Ac1 A076JDaEBGOZtsu2vASDCEUmqMHvh+wNutqEEpJFEpgDMO+xOy5l/PL5A0STrn5H Wg95XC0lnPllid4lDNIhk3QnT+NPFvyXcFrHyspzgmg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=UmLk4Rd1E4XU+SXS+psQbhwXQ5 D39Qx3kML1uNaiy0M34xU7oATMUgSfgVRqTqvDDofGCjoV5clQM4ZY6Iep7k5XeJ BKS1za2D0YJjUGbOVJ05Gq9iu0ZuLvLZPQogFRievN2AUGTk0s2FYfr3KhxkkPWU sdB9a7g1uIyo9/xlQ=
Received: from h.hanazo.no (122x216x24x202.ap122.ftth.ucom.ne.jp [122.216.24.202]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C6DEFD788D; Wed, 28 Oct 2015 11:21:55 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3C7FB7EE2A8; Thu, 29 Oct 2015 03:21:48 +0900 (JST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_52093619-1E63-4908-A6C0-7F8B6BA4E693"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Thu, 29 Oct 2015 03:21:47 +0900
Message-Id: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> 
To: =?utf-8?B?56We5piO6YGU5ZOJ?= , Tore Anderson 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 18:21:59 -0000

--Apple-Mail=_52093619-1E63-4908-A6C0-7F8B6BA4E693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> As I understand it (and I do stress that), the M-flag indicates =
whether
>> or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
>> (IA_PD) is something different. Therefore, assuming that availability =
of
>> IA_PD is signalled using RA flags to begin with, then it is "other
>> configuration" and thus signalled with the O-flag, not the M-flag. I
>> know of at least one wireline ISP that has such a deployment, i.e.,
>> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
>> using M=3D0 + O=3D1.
>=20
> Interesting point.  Personally I've been assuming that the O-flag
> being on implies (if anything) a "stateless" DHCPv6 service.  That's
> significant in this context, since the client would send an
> Information-request message for stateless services, while prefix
> delegation requires a DHCPv6 session beginning with a Solicit message.
> I'm not sure how widely my assumption is shared, but, in any case,
> the specifications are actually unclear as you indicated above.
>=20
> (And, of course, there is another level of issue that the semantics of
> MO flags is too unclear in general in the first place...)

DHCPv6 PD availability is not signalled through M/O bits or RAs at all.
two reasons for that; firstly routers don't typically process Router =
Advertisements, secondly we would have needed more flags.

Best regards,
Ole

--Apple-Mail=_52093619-1E63-4908-A6C0-7F8B6BA4E693
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWMRI7AAoJEL7aWKiYQt92jAUQAKPx1Dj+0o1vwMNB+xe93lsZ
Dst/bikxUuW2zwq/3wBImNaFLNiEJhpisd7BJxHpmz67wf1uAWAMLj54mpBUjkj0
B+8+0YgIqcO8Uyd27Kk07mFfHcsoTn19ihgrOKjOdJHIWaIj/qSEDZNnNUjrtXHA
1T52BREEW0X4F2gvapvLr50U76wVgHTaR33tsfvPFqAOx+0g1PfiPDd9v/7AaWtv
tCg/ClkWt1FePouJcu3gPh8lqhzvlBR6rk6THlIOrZ7tmGZvmG5dgGKR7UCsEFPl
4E+k7d5ulMgpO/lzbkVK3yKjDi8i317OCFZ0fIwROJxtE0GfEhjk6Qnfg5d86OyR
TqK4K0flEFyLZgNBux1jaOVOlD7pdo55cIRNafKq0C/90cgoZnku2cGCVMtZQ7yu
NTN66xdmb2k0q3HmykNTNbCwVfNmGdt7O0HUNpwoY57RnN+PegL95QUsA8cjlix8
Z7JINv9Jcb+j8pw+gaFPxOLC1zzUXFFODUbWSIXkR7Z1sxcdVmZBDaAIedSK7Ega
5BRCJfxiETMSpGy8Imr7uDyeKp7D7k9f5H6EatIBT4nmzNVcxZX5QPt6rs/4U1mV
vG4b3t291c6mMacNXU0WD/qhDBrgTgL1XzGzB11DAx5Pd3ahtIor4Y6w5q8zailY
8rDJvgGSScyMx9XtFJK7
=jG8G
-----END PGP SIGNATURE-----

--Apple-Mail=_52093619-1E63-4908-A6C0-7F8B6BA4E693--


From nobody Wed Oct 28 11:45:54 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700141AC40A for ; Wed, 28 Oct 2015 11:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIAL-rsG8K5Q for ; Wed, 28 Oct 2015 11:45:51 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E200B1A89F2 for ; Wed, 28 Oct 2015 11:45:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9SIjpR0023646; Wed, 28 Oct 2015 11:45:51 -0700
Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9SIjkPr023256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 Oct 2015 11:45:47 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.188]) with mapi id 14.03.0235.001; Wed, 28 Oct 2015 11:45:46 -0700
From: "Templin, Fred L" 
To: "otroan@employees.org" , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Tore Anderson 
Thread-Topic: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREa2Sm1mgWd2hdkuy16sTHimGbZ6BOlFQ
Date: Wed, 28 Oct 2015 18:45:45 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F32203@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 18:45:53 -0000

Hi Ole,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of otroan@employees=
.org
> Sent: Wednesday, October 28, 2015 11:22 AM
> To: =1B$B?@L@C#:H=1B(B; Tore Anderson
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-=
host-00.txt
>=20
> >> As I understand it (and I do stress that), the M-flag indicates whethe=
r
> >> or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
> >> (IA_PD) is something different. Therefore, assuming that availability =
of
> >> IA_PD is signalled using RA flags to begin with, then it is "other
> >> configuration" and thus signalled with the O-flag, not the M-flag. I
> >> know of at least one wireline ISP that has such a deployment, i.e.,
> >> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
> >> using M=3D0 + O=3D1.
> >
> > Interesting point.  Personally I've been assuming that the O-flag
> > being on implies (if anything) a "stateless" DHCPv6 service.  That's
> > significant in this context, since the client would send an
> > Information-request message for stateless services, while prefix
> > delegation requires a DHCPv6 session beginning with a Solicit message.
> > I'm not sure how widely my assumption is shared, but, in any case,
> > the specifications are actually unclear as you indicated above.
> >
> > (And, of course, there is another level of issue that the semantics of
> > MO flags is too unclear in general in the first place...)
>=20
> DHCPv6 PD availability is not signalled through M/O bits or RAs at all.

+1=20

> two reasons for that; firstly routers don't typically process Router Adve=
rtisements, secondly we would have needed more flags.

I agree with non-requirement for RAs, but there is also a use case where th=
e
"requesting router" is actually a host. The host acts as a requesting route=
r
from the standpoint of DHCPv6 PD, but when it receives a prefix it assigns
it to a loopback interface. The host disables IP forwarding, and assigns
addresses constructed from the delegated prefix to the interface over
which the delegation was received. It can assign millions of such addresses=
,
and never need to do DAD for any of them because the prefix is delegated
for the hosts exclusive use. The host initially has only a default route po=
inting
to the delegating router, but can discover more-specific routes via Redirec=
ts.

The only difference when the requesting router is actually a router is that
it turns on IP forwarding and sub-delegates the delegated prefix to its
downstream-attached networks. All other prefix delegation messaging
is exactly the same as the host case.

Thanks - Fred
fred.l.templin@beoing.com

> Best regards,
> Ole


From nobody Wed Oct 28 12:32:52 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC31ACD9C for ; Wed, 28 Oct 2015 12:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKrjHbk1V7RQ for ; Wed, 28 Oct 2015 12:32:50 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DF71ACD96 for ; Wed, 28 Oct 2015 12:32:49 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=33801 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZrWSc-0008Ea-Uu; Wed, 28 Oct 2015 20:32:38 +0100
Date: Wed, 28 Oct 2015 20:32:38 +0100
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20151028203238.3f1dc47d@envy.fud.no>
In-Reply-To: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 19:32:51 -0000

* otroan@employees.org

> DHCPv6 PD availability is not signalled through M/O bits or RAs at
> all.

For what it's worth, what gave me this understanding are two things:

1) From RFC 7084:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.

Since O is redundant (implicitly 1) whenever M=1 (RFC4861 section 4.2)
I think a reasonable intepretation of this is that it is DHCPv6 PD is
considered part of what is considered "other configuration", whose
availability is signalled with the O flag.

2) RFC 4861 section 4.2 itself:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].
[...]
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.

What DHCPv6 options the term "other configuration" encompasses isn't
limited in any way. It is IMHO therefore reasonable to interpret this
as *any* configuration available via DHCPv6, except for "addresses". So
I read the above as follows:

M flag: signals availability of addresses
O flag: signals availability of everything that is not
addresses (which would include prefixes)

> two reasons for that; firstly routers don't typically process Router
> Advertisements, secondly we would have needed more flags.

Well, as described by RFC 7084, CE routers (which are the primary
consumers of DHCPv6-PD to the best of my knowledge) *do* process RAs,
and if the O flag can be interpreted to mean "everything except
addresses", the two flags are all that is needed.

Tore


From nobody Wed Oct 28 12:34:14 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE311ACDA1 for ; Wed, 28 Oct 2015 12:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7nFz0fYsyAL for ; Wed, 28 Oct 2015 12:34:11 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681031ACD9C for ; Wed, 28 Oct 2015 12:34:11 -0700 (PDT)
Received: by pacfv9 with SMTP id fv9so16163305pac.3 for ; Wed, 28 Oct 2015 12:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XjdMkXfj/VJWhrnNzfX8jPpawQVlr6r8TuBJahOHYIQ=; b=aKOnl8g96Gp9hM0wGswD/WJeJOmxRoR8am8ChUtjlEi24hpn026VfNvOvgst6XgD86 DmI8GCjlktqlUouiocRHa/+QJftQsM2CXHXx92RqqdPEM8RpRaZ6oOTmJuHVCQuZQRfc RvohpoZUrWInY7au3PUzXkPmK+OMWdmC189x+f0J4xH+J8QGsrcdtYJ0KJmdQ+wkY3iY J+1BUHNAPXIWkodS8jbxOnyoTDylvEcgQSw1Mkt+qVlbc4RaQhjwdm0+V9rLg1YOqsTD ZOVXc1ig71Aa35NtXzCFP4hF2lYbB9kMujCMxe7pj5dx1+MvIQUjeGmS0DTirsbnKbha hpsA==
X-Received: by 10.66.242.138 with SMTP id wq10mr55715606pac.2.1446060851055; Wed, 28 Oct 2015 12:34:11 -0700 (PDT)
Received: from ?IPv6:2406:e007:5401:1:28cc:dc4c:9703:6781? ([2406:e007:5401:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id gv1sm46900574pbc.38.2015.10.28.12.34.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 12:34:09 -0700 (PDT)
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Tore Anderson 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5631232E.4020701@gmail.com>
Date: Thu, 29 Oct 2015 08:34:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 19:34:12 -0000

On 29/10/2015 06:54, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:
> At Wed, 28 Oct 2015 11:38:51 +0100,
> Tore Anderson  wrote:
>=20
>> As I understand it (and I do stress that), the M-flag indicates whethe=
r
>> or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
>> (IA_PD) is something different. Therefore, assuming that availability =
of
>> IA_PD is signalled using RA flags to begin with, then it is "other
>> configuration" and thus signalled with the O-flag, not the M-flag. I
>> know of at least one wireline ISP that has such a deployment, i.e.,
>> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
>> using M=3D0 + O=3D1.
>=20
> Interesting point.  Personally I've been assuming that the O-flag
> being on implies (if anything) a "stateless" DHCPv6 service.  That's
> significant in this context, since the client would send an
> Information-request message for stateless services, while prefix
> delegation requires a DHCPv6 session beginning with a Solicit message.
> I'm not sure how widely my assumption is shared, but, in any case,
> the specifications are actually unclear as you indicated above.
>=20
> (And, of course, there is another level of issue that the semantics of
> MO flags is too unclear in general in the first place...)

"If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information."

So Tore is slightly wrong: if the M flag is set, the O flag contains
no information, whatever value it has. Don't even test it.

If the M flag is clear, and the O flag is set, you can't get addresses.
You can get some things from DHCPv6, but you don't know what. Maybe
IA_PD is available, maybe not.

If M=3DO=3D0, DHCPv6 is a waste of space.

Or:

if M=3D=3D1
  {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
   /*try to get IA_PD from DHCPv6 if you want*/;
   /*try to get other DHCPv6 options if you want*/;}
   else {/*get addresses using SLAAC*/;
        if O=3D=3D1
          {/*try to get IA_PD from DHCPv6 if you want*/;
           /*try to get other DHCPv6 options if you want*/;}}


    Brian


From nobody Wed Oct 28 12:55:53 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6421ACE15 for ; Wed, 28 Oct 2015 12:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z49cMV9BJwfJ for ; Wed, 28 Oct 2015 12:55:51 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B471ACE14 for ; Wed, 28 Oct 2015 12:55:51 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=33838 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZrWp0-0000Om-2k; Wed, 28 Oct 2015 20:55:46 +0100
Date: Wed, 28 Oct 2015 20:55:45 +0100
From: Tore Anderson 
To: "Templin, Fred L" 
Message-ID: <20151028205545.04283e05@envy.fud.no>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F31F9B@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832F31F9B@XCH-BLV-504.nw.nos.boeing.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 19:55:53 -0000

* Templin, Fred L

> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson
> > 1) Section 4.2 mentions that DAD is used, but it is not clear to me how
> > this will work for LLAs. If two UEs (potentially attached to different
> > APs) are using the same link-local address, how will they see each
> > others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
> > not relay DAD messages across the split BUM horizon, how will it deal
> > with the possiblity of two unique UEs both using the same LLA? I'm
> > guessing that in a large-scale deployment, the chances of two UEs
> > having statically configured, e.g., fe80::1 is quite likely.
> 
> For properly delegated prefixes (i.e., prefixes that are granted by the
> network for the UE's exclusive use), DAD over the link over which the
> prefix was received is not necessary. If the prefix was advertised to
> multiple UEs, then DAD would still be required.
> 
> The trouble with (A=1; L=0) in PIO advertisements is that there is
> no way for an unmodified UE to know whether the prefix is being
> granted by the network for its exclusive use. RFC4861 says that
> L=0 only means that there is "no statement about on-link or off-link
> properties of the prefix". It is therefore unreasonable for the UE
> to assume that the prefix is being granted for its exclusive use.

Hi Fred,

Please not that I am talking specifically about LLAs. Those aren't
advertised in RA or DHCPv6.

I do understand that each UE is expected to be alone in its unique
GUA /64, making DAD for those addresses redundant.

However this is not the case for LLAs, unless I have misunderstood the
I-D - from the WLAN-GW's point of view, every UE attacached to a single
AP will belong to the same link (the same Soft-GRE tunnel interface,
that is). Thus there is a possibility of address conflicts.

Tore


From nobody Wed Oct 28 13:03:50 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2C1ACE46 for ; Wed, 28 Oct 2015 13:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsDpRLcsYma0 for ; Wed, 28 Oct 2015 13:03:48 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EC81ACE3F for ; Wed, 28 Oct 2015 13:03:46 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=33850 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZrWwf-0000XW-I9; Wed, 28 Oct 2015 21:03:41 +0100
Date: Wed, 28 Oct 2015 21:03:41 +0100
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20151028210341.3d48204e@envy.fud.no>
In-Reply-To: <20151028203238.3f1dc47d@envy.fud.no>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>   <20151028203238.3f1dc47d@envy.fud.no>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 20:03:49 -0000

* Tore Anderson

> What DHCPv6 options the term "other configuration" encompasses isn't
> limited in any way. It is IMHO therefore reasonable to interpret this
> as *any* configuration available via DHCPv6, except for "addresses". So
> I read the above as follows:
>=20
> M flag: signals availability of addresses
> O flag: signals availability of everything that is not
> addresses (which would include prefixes)

Correcting myself:

M=3D1: signals that addresses are certainly available, and that other
stuff in addition to addresses *might* be available.
O=3D1: signals that at least some other stuff, that is, *not* addresses,
is available via DHCPv6.
M=3DO=3D0: possibly nothing is available via DHCPv6 (but it could still be,
both addresses and/or other stuff - it might just be that the RA
originator is unaware of it)

=C2=ABOther stuff=C2=BB here might include prefixes, or it might not. Only =
way to
know for sure is for the client to ask for it.

Tore


From nobody Wed Oct 28 14:31:47 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4A1B5E86 for ; Wed, 28 Oct 2015 14:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbxLjKx2aRQO for ; Wed, 28 Oct 2015 14:31:44 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20701B5E89 for ; Wed, 28 Oct 2015 14:31:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9SLVjlK015873; Wed, 28 Oct 2015 16:31:45 -0500
Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9SLVZbD015354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 Oct 2015 16:31:36 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.163]) with mapi id 14.03.0235.001;  Wed, 28 Oct 2015 14:31:33 -0700
From: "Templin, Fred L" 
To: Tore Anderson 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREWzV/+MZsnq7pUCTitCxpFGwKp6BBjxggADBh4D//6PnMA==
Date: Wed, 28 Oct 2015 21:31:33 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F32388@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832F31F9B@XCH-BLV-504.nw.nos.boeing.com> <20151028205545.04283e05@envy.fud.no>
In-Reply-To: <20151028205545.04283e05@envy.fud.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Oct 2015 21:31:46 -0000

Hi Tore,

> -----Original Message-----
> From: Tore Anderson [mailto:tore@fud.no]
> Sent: Wednesday, October 28, 2015 12:56 PM
> To: Templin, Fred L
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix=
-per-host-00.txt
>=20
> * Templin, Fred L
>=20
> > > -----Original Message-----
> > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderso=
n
> > > 1) Section 4.2 mentions that DAD is used, but it is not clear to me h=
ow
> > > this will work for LLAs. If two UEs (potentially attached to differen=
t
> > > APs) are using the same link-local address, how will they see each
> > > others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
> > > not relay DAD messages across the split BUM horizon, how will it deal
> > > with the possiblity of two unique UEs both using the same LLA? I'm
> > > guessing that in a large-scale deployment, the chances of two UEs
> > > having statically configured, e.g., fe80::1 is quite likely.
> >
> > For properly delegated prefixes (i.e., prefixes that are granted by the
> > network for the UE's exclusive use), DAD over the link over which the
> > prefix was received is not necessary. If the prefix was advertised to
> > multiple UEs, then DAD would still be required.
> >
> > The trouble with (A=3D1; L=3D0) in PIO advertisements is that there is
> > no way for an unmodified UE to know whether the prefix is being
> > granted by the network for its exclusive use. RFC4861 says that
> > L=3D0 only means that there is "no statement about on-link or off-link
> > properties of the prefix". It is therefore unreasonable for the UE
> > to assume that the prefix is being granted for its exclusive use.
>=20
> Hi Fred,
>=20
> Please not that I am talking specifically about LLAs. Those aren't
> advertised in RA or DHCPv6.
>=20
> I do understand that each UE is expected to be alone in its unique
> GUA /64, making DAD for those addresses redundant.

Yes, but that can only happen if the prefix is properly delegated to
the UE and not also advertised to other UEs. I don't think there is
a way for the UE to tell that based only on the (A, L) bits in a PIO.

> However this is not the case for LLAs, unless I have misunderstood the
> I-D - from the WLAN-GW's point of view, every UE attacached to a single
> AP will belong to the same link (the same Soft-GRE tunnel interface,
> that is). Thus there is a possibility of address conflicts.

OK, I see your point: if it is a shared link where LLA duplication is possi=
ble
then DAD for the LLAs is needed, yes. AERO is a shared link where LLA
duplication is not possible; hence, AERO avoids DAD even for LLAs.

Thanks - Fred
fred.l.templin@boeing.com

> Tore


From nobody Thu Oct 29 03:57:59 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A911B2D21 for ; Thu, 29 Oct 2015 03:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58sLdz86t3qc for ; Thu, 29 Oct 2015 03:57:52 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE671B2D20 for ; Thu, 29 Oct 2015 03:57:52 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TAvn2t030734 for ; Thu, 29 Oct 2015 11:57:50 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 692E5204F7E for ; Thu, 29 Oct 2015 12:03:41 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 616F4204D00 for ; Thu, 29 Oct 2015 12:03:41 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TAvmLN020644 for ; Thu, 29 Oct 2015 11:57:50 +0100
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  
From: Alexandre Petrescu 
Message-ID: <5631FBAC.1010107@gmail.com>
Date: Thu, 29 Oct 2015 11:57:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 10:57:58 -0000

Le 28/10/2015 19:21, otroan@employees.org a écrit :
>>> As I understand it (and I do stress that), the M-flag indicates
>>> whether or not *addresses* are available via DHCPv6 (RFC 4861
>>> s4.2). Prefixes (IA_PD) is something different. Therefore,
>>> assuming that availability of IA_PD is signalled using RA flags
>>> to begin with, then it is "other configuration" and thus
>>> signalled with the O-flag, not the M-flag. I know of at least one
>>> wireline ISP that has such a deployment, i.e., they support
>>> DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this using M=0
>>>  + O=1.
>>
>> Interesting point.  Personally I've been assuming that the O-flag
>> being on implies (if anything) a "stateless" DHCPv6 service.
>> That's significant in this context, since the client would send an
>>  Information-request message for stateless services, while prefix
>> delegation requires a DHCPv6 session beginning with a Solicit
>> message. I'm not sure how widely my assumption is shared, but, in
>> any case, the specifications are actually unclear as you indicated
>>  above.
>>
>> (And, of course, there is another level of issue that the semantics
>> of MO flags is too unclear in general in the first place...)
>
> DHCPv6 PD availability is not signalled through M/O bits or RAs at
> all. two reasons for that; firstly routers don't typically process
> Router Advertisements, secondly we would have needed more flags.

This (DHCP-PD availability not conveyed) looks like a lack in
specification.

There is another such lack illustrated by practical experience: there is
no easy way for a UE to learn whether the network in front of it
supports PD or just DHCP.  There are some suggestions in DHC WG (e.g.
Solicit with IA_PD and check Advertise for IA==Noaddrsavail, subject
"Two comments..." in archives 23 July 2015) but no spec.

Maybe a better spec would persuade operators to deploy PD?  Have the
operators felt this lack?

>> firstly routers don't typically process Router Advertisements,

But it's mostly Routers that would need a prefix from DHCP-PD.

Alex

>
> Best regards, Ole
>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Oct 29 03:58:41 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA01C1B2D25 for ; Thu, 29 Oct 2015 03:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Ajh5EJob2s for ; Thu, 29 Oct 2015 03:58:38 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF09E1B2D22 for ; Thu, 29 Oct 2015 03:58:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TAwX7P020839 for ; Thu, 29 Oct 2015 11:58:35 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C2B1C204D00 for ; Thu, 29 Oct 2015 12:04:26 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BAC03200CA6 for ; Thu, 29 Oct 2015 12:04:26 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TAwZLI021284 for ; Thu, 29 Oct 2015 11:58:35 +0100
To: v6ops@ietf.org
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> 
From: Alexandre Petrescu 
Message-ID: <5631FBDB.6060307@gmail.com>
Date: Thu, 29 Oct 2015 11:58:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 10:58:39 -0000

Le 28/10/2015 18:54, 神明é”哉 a écrit :
> At Wed, 28 Oct 2015 11:38:51 +0100,
> Tore Anderson  wrote:
>
>> As I understand it (and I do stress that), the M-flag indicates whether
>> or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
>> (IA_PD) is something different. Therefore, assuming that availability of
>> IA_PD is signalled using RA flags to begin with, then it is "other
>> configuration" and thus signalled with the O-flag, not the M-flag. I
>> know of at least one wireline ISP that has such a deployment, i.e.,
>> they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
>> using M=0 + O=1.
>
> Interesting point.  Personally I've been assuming that the O-flag
> being on implies (if anything) a "stateless" DHCPv6 service.  That's
> significant in this context, since the client would send an
> Information-request message for stateless services, while prefix
> delegation requires a DHCPv6 session beginning with a Solicit message.
> I'm not sure how widely my assumption is shared, but, in any case,
> the specifications are actually unclear as you indicated above.

I agree.

Alex

>
> (And, of course, there is another level of issue that the semantics of
> MO flags is too unclear in general in the first place...)
>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Oct 29 04:33:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0198E1B2D5C for ; Thu, 29 Oct 2015 04:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qlhGPtkBlkP for ; Thu, 29 Oct 2015 04:33:05 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7961B2D59 for ; Thu, 29 Oct 2015 04:33:05 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TBWwM8001670; Thu, 29 Oct 2015 12:32:58 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F24B420503B; Thu, 29 Oct 2015 12:38:49 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E470E204D00; Thu, 29 Oct 2015 12:38:49 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TBWvR2017517; Thu, 29 Oct 2015 12:32:58 +0100
To: "Templin, Fred L" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com> <5630A6FA.9020602@gmail.com> <2134F8430051B64F815C691A62D9831832F31FFF@XCH-BLV-504.nw.nos.boeing.com>
From: Alexandre Petrescu 
Message-ID: <563203E9.4030405@gmail.com>
Date: Thu, 29 Oct 2015 12:32:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2134F8430051B64F815C691A62D9831832F31FFF@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] how /63 helps tethering - addressing architecture
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 11:33:07 -0000

Fred,

Le 28/10/2015 17:03, Templin, Fred L a écrit :
[...]
>> We can ask the operator to show the IPv6 addressing architecture laid on
>> the operator topology, substituting "2001:db8::" where necessary.  I
>> suppose this will help.
>
> The operator's service prefix (e.g., a /32 or something) should be well
> known. UE prefixes should be derived from the service prefix and
> delegated according to the UE's needs, and not necessarily bound
> to the operator's topology.

I agree.  It sounds like a good start for designing an IPv6 address 
architecture for a jjmb-like topology.

But it should be done carefully, in order to allow for future use of 
Prefix Delegation for future tethering UEs.  If not done carefully at 
the start, the addressing architecture risks forbidding Prefix 
Delegation later (because in IPv6 there is no NAT to extend the network, 
and there is a boundary at /64).

May I explain.

In the straighforward way 2001:db8:1::/48 is assigned for access through 
AP1, 2001:db8:2::/48 through AP2 and so on; for UEs we reserve 
2001:db8:1:1::/64 to 1:n through AP1 and so on.  But later we realize we 
have no space left for allocating /64 prefixes to future tethering UEs. 
  It is illustrated:

                                          +-----+
                                          | AAA |
                                          +-----+
                                             /
                                          Radius
                                           / 2001:db8:ffff:1::/64
                                     +----+
                                     | CP |
                 +----+              +---------+
UE1..UEn-802.11-| AP |---Soft_GRE---| WLAN-GW |----Internet/WAN
                 +----+              +---------+    2001:db8::/32
           2001:db8:1:1::/64              |
           2001:db8:1:2::/64           IP/HTTP
               ...                        | 2001:db8:ffff:2::/64
           2001:db8:1:n::/64   +---------------------+
                               | HTTP Captive Portal |
                               +---------------------+


A better way is to refine from the start a part of the prefix to reserve 
it for future prefix allocations for tethering UEs.

                                              +-----+
                                              | AAA |
                                              +-----+
PD-allocated                                   /
2001:db8:0201:1::/64                         Radius
2001:db8:0201:2::/64                         / 2001:db8:ff00:1::/64
   ...                                   +----+
2001:db8:0201:n::/64                    | CP |
                     +----+              +---------+
         UE--802.11--| AP |---Soft_GRE---| WLAN-GW |----Internet/WAN
                     +----+              +---------+    2001:db8::/32
            2001:db8:0101:1::/64              |
            2001:db8:0101:2::/64           IP/HTTP
                   ...                        | 2001:db8:ff00:2::/64
            2001:db8:0101:n::/64   +---------------------+
                                   | HTTP Captive Portal |
                                   +---------------------+

I do not know what is the IPv6 addressing architecture on the jjmb 
topology, and I hope it is ready for Prefix Delegation to tethering UEs.

Alex


From nobody Thu Oct 29 06:23:32 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F53A1A6F7C for ; Thu, 29 Oct 2015 06:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpSa2XNzCAWp for ; Thu, 29 Oct 2015 06:23:28 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748641A6F6E for ; Thu, 29 Oct 2015 06:23:27 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CAB2862D9F for ; Thu, 29 Oct 2015 14:23:25 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9352C60298 for ; Thu, 29 Oct 2015 14:23:25 +0100 (CET)
Received: (qmail 88773 invoked by uid 1007); 29 Oct 2015 14:23:25 +0100
Date: Thu, 29 Oct 2015 14:23:25 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151029132325.GM70452@Space.Net>
References: <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5629EED2.8050000@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 13:23:30 -0000

Hi,

On Fri, Oct 23, 2015 at 10:24:50AM +0200, Alexandre Petrescu wrote:
> Let me start by a negation, as much as I dont like them.  We saw in
> other discussions, the number in "/64" is not relevant to size or number
> of devices.  Even if 2^64 looks like a big number, it does not mean we
> can put that many devices in a subnet, obstacled by link layer
> characteristics.
> 
> Then, using a "/63" rather than a "/64" prefix assigned (for a certain
> interpretation of the word 'assigned') to a device may allow it to
> tether cleanly: a smartphone receiving a /63 will be able to create two
> "/64"s out of it.  It will 'assign' one so created '/64' for its
> bluetooth interface and another one deeper in its LAN.

No, it can't.  If the smartphone sees "there is a /63 on this link", it
has no knowlege on whether it can "just so" take one of the /64s to
use for something else - someone else might be sharing the link, and
have the same idea.

So, /63 on a link is totally useless, in addition to being not defined
for SLAAC.

(If you *know* that this is a link just for you and nobody else, like
a PPP link or a 3G PDP context, this could be done - but is still not
overly useful, as you can do the tethering thing already perfectly well
with the single /64 you get there)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Thu Oct 29 06:44:03 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4B1A8702 for ; Thu, 29 Oct 2015 06:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEoehJN0CwcK for ; Thu, 29 Oct 2015 06:44:00 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3EA1A86FD for ; Thu, 29 Oct 2015 06:43:59 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TDhrwD020561; Thu, 29 Oct 2015 14:43:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ABCDD204E21; Thu, 29 Oct 2015 14:49:48 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9BCDD204559; Thu, 29 Oct 2015 14:49:48 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TDhtw2005389; Thu, 29 Oct 2015 14:43:56 +0100
To: Gert Doering 
References: <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <5632229B.3070208@gmail.com>
Date: Thu, 29 Oct 2015 14:43:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151029132325.GM70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 13:44:01 -0000

Gert - have you noticed jjmb is 'prefix-per-host'?

Le 29/10/2015 14:23, Gert Doering a écrit :
> Hi,
>
> On Fri, Oct 23, 2015 at 10:24:50AM +0200, Alexandre Petrescu wrote:
>> Let me start by a negation, as much as I dont like them.  We saw in
>> other discussions, the number in "/64" is not relevant to size or number
>> of devices.  Even if 2^64 looks like a big number, it does not mean we
>> can put that many devices in a subnet, obstacled by link layer
>> characteristics.
>>
>> Then, using a "/63" rather than a "/64" prefix assigned (for a certain
>> interpretation of the word 'assigned') to a device may allow it to
>> tether cleanly: a smartphone receiving a /63 will be able to create two
>> "/64"s out of it.  It will 'assign' one so created '/64' for its
>> bluetooth interface and another one deeper in its LAN.
>
> No, it can't.  If the smartphone sees "there is a /63 on this link", it
> has no knowlege on whether it can "just so" take one of the /64s to
> use for something else - someone else might be sharing the link, and
> have the same idea.

Except when that link is a point-to-point link[*] not a shared link. 
And this is precisely the case with the prefix-per-host concepts which 
are assumed in the jjmb draft: they make point-to-point links laid over 
underlying shared links.

[*] the actual distinguishing characteristic for point-to-point vs 
'shared' links is the kind of route present in the gateway for this 
prefix: 'C'onnected qualifier for route on Cisco, or '*'-vs-address in a 
routing table for linux are the right indicators of that characteristic.

If the route at the gateway points the /63 to a next-hop value as an 
address, then it is certainly possible for the UE to derive two /64s out 
of that /63 and make subnets in its LAN.  Remember that a 
'prefix-per-host' concept can not work if the gateway does not have such 
a route pointing to an address (rather than '*'); this is so because 
there must be a means for the gateway to know _which_ prefix belongs to 
_which_ host.

If on the other hand the route at the gateway points a /63 to a '*' then 
yes, that '/63' can not be used by the UE to form /64s for its LANs. 
But this does not allow for 'prefix-per-host' concepts.

> So, /63 on a link is totally useless, in addition to being not defined
> for SLAAC.

I can agree /63 on-link is maybe undefined, although I am sure linux 
implementations do make addresses out of a /63 with SLAAC.

A /63 totally useless - maybe we should think of it in terms of IPv6 
addressing architecture.  I think an IPv6 addressing architecture may be 
such designed that does not allow to even think that a UE may need a 
/63, and that /64 is all what users desire.

>
> (If you *know* that this is a link just for you and nobody else, like
> a PPP link or a 3G PDP context, this could be done - but is still not
> overly useful, as you can do the tethering thing already perfectly well
> with the single /64 you get there)

That kind of tethering only allows for _one_ subnet in the LAN.

One couldn't tether to 2-3 subnets present in one's car for example.  Or 
small ship, or whenever more than just smartphone+tablet formula.

Alex


>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Oct 29 07:06:03 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3A1B2EAB for ; Thu, 29 Oct 2015 07:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-FK-zsyTEhS for ; Thu, 29 Oct 2015 07:06:00 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229D61B2EA8 for ; Thu, 29 Oct 2015 07:05:59 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E13AC62DC5 for ; Thu, 29 Oct 2015 15:05:56 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8C46F6082D for ; Thu, 29 Oct 2015 15:05:56 +0100 (CET)
Received: (qmail 92058 invoked by uid 1007); 29 Oct 2015 15:05:56 +0100
Date: Thu, 29 Oct 2015 15:05:56 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151029140556.GN70452@Space.Net>
References: <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lPY6w/dILDkXzu1l"
Content-Disposition: inline
In-Reply-To: <5632229B.3070208@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:06:02 -0000

--lPY6w/dILDkXzu1l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Oct 29, 2015 at 02:43:55PM +0100, Alexandre Petrescu wrote:
> Gert - have you noticed jjmb is 'prefix-per-host'?

Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC"?

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--lPY6w/dILDkXzu1l
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVjInxN9WwGXkzn/FAQIzgQ/+JMYJVYOHwDpul79WoQLULRNmQUaUQksZ
Hi3hnfeZpHjUDmfWYtWrHTXhGQXGM5VsOXorLjlixNzXdI/AWs1+wJTy7PRqJCK5
Xh5PA/9VIqK6StxmQJwDfc772rysaZKPPhfueupCvX2DMc2x/7r5fxr106Jzrv8X
vXQ7inawyA4u+aczLmTDgp2s3RLf8gQPFzk+UdjA4pAtZnCq8xrSG1lAjGBzlLxb
9/J3SVhqA067affAMwsu3fqRd427HPxRqmJzUx6rHtyonQLw48w6myQUzCgnw1Ch
DODdViE3mQGKObwIviI1GLGsbFaIKkr8qwun1Q0fe0CZPp3Zs7G7BpWutsJsJdWY
IKCIuk+rvArF4xlzbW2vPOoCPB31gHv7yXNLsfYXF98ihXhczSjMYOCtA1FtJI09
RV8tYJLhbw5Dr6AZD5rueTabExGCNmNNN4C3xgsEmA5+SZEX/mmsL+ddAD3gAGPI
aGTM//DHfvPKWJigjzgOLGQ5DhhuO8gUnXmmIIlbcUbTrZU+t/8bGmJdnUzAxscv
fTMofQ/TdxInYaLyZs2MiMXPbtUBpgd9+4B0SWKvBzFi0K8XD1q/1dcXbTuwYKJi
WlhOrCU5qEufFurdDZlcFBCs1Kd1uHurgDpYU+ECP0WByNkg3gDuYeMF40u8kFWx
ya5PqcH2Z4U=
=xhRw
-----END PGP SIGNATURE-----

--lPY6w/dILDkXzu1l--


From nobody Thu Oct 29 07:14:54 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB51B2ED0 for ; Thu, 29 Oct 2015 07:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdUuQxVDRsWy for ; Thu, 29 Oct 2015 07:14:51 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CF71B2ECF for ; Thu, 29 Oct 2015 07:14:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TEEm7W007239; Thu, 29 Oct 2015 15:14:48 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF42E2051F8; Thu, 29 Oct 2015 15:20:39 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9E9C207C4C; Thu, 29 Oct 2015 15:20:39 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TEElwR004392; Thu, 29 Oct 2015 15:14:48 +0100
To: Gert Doering 
References: <20151022164925.GU70452@Space.Net> <56291556.2010907@gmail.com>  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com> <20151029140556.GN70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <563229D7.9080401@gmail.com>
Date: Thu, 29 Oct 2015 15:14:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151029140556.GN70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:14:53 -0000

Le 29/10/2015 15:05, Gert Doering a écrit :
> Hi,
>
> On Thu, Oct 29, 2015 at 02:43:55PM +0100, Alexandre Petrescu wrote:
>> Gert - have you noticed jjmb is 'prefix-per-host'?
>
> Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC"?

If done it helps with tethering.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Oct 29 07:16:48 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB631B2ED7 for ; Thu, 29 Oct 2015 07:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdPDtB_G8UE for ; Thu, 29 Oct 2015 07:16:46 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D291B2ED6 for ; Thu, 29 Oct 2015 07:16:46 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CAD9562DC5 for ; Thu, 29 Oct 2015 15:16:44 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 350A06082D for ; Thu, 29 Oct 2015 15:16:43 +0100 (CET)
Received: (qmail 93139 invoked by uid 1007); 29 Oct 2015 15:16:43 +0100
Date: Thu, 29 Oct 2015 15:16:43 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151029141643.GO70452@Space.Net>
References:  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com> <20151029140556.GN70452@Space.Net> <563229D7.9080401@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xbxyguyUcy/oJisi"
Content-Disposition: inline
In-Reply-To: <563229D7.9080401@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:16:47 -0000

--xbxyguyUcy/oJisi
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Oct 29, 2015 at 03:14:47PM +0100, Alexandre Petrescu wrote:
> Le 29/10/2015 15:05, Gert Doering a =E9crit :
> > On Thu, Oct 29, 2015 at 02:43:55PM +0100, Alexandre Petrescu wrote:
> >> Gert - have you noticed jjmb is 'prefix-per-host'?
> >
> > Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC=
"?
>=20
> If done it helps with tethering.

No, as you have already discovered. =20

And note that "a gateway routing a /63 over a point-to-point link" is=20
NOT the same as "a /63 put on-link by means of RA".

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--xbxyguyUcy/oJisi
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVjIqSt9WwGXkzn/FAQJebQ//ZovWQsA4fQN9p5wNDCOJ2vrsQG901Y4A
BQ6AJVfnc3Gseyq4OG9SfEnPdJsQJFtRZ7+BdCYjvf+fJc9PH+vEYpjtD3kCji+n
ZlVjvssZcR6ESd9sk/NY/FebGUV2wdAKzPBiHVgC0dcUJtNJIMtZJYekSmcCvDYg
cjWh+DgFCDwSZThsUky6V737hhZo+iKPvdBpeErN1cO675eX6osAXo5O48WAefnJ
W2F/h/kjnBV2B2lpclEd+kJxQqTyCDv2Q8lC0Oi/OMsHnJ+ZlStFCUd7HNn7BaeJ
537TH3CmWBHvQe1PZIMkPTx2yKP3uXmUiVo0wVa3ZL/NBEqmfutQcnMSuEHrwOFs
KDH0zI8W1O6ASKtCuz+EX2Cojxzz1/y1oT8hVlqb57YwXv5Af9h/z1hit8guyNO0
aFYwQ8+MlVlsR+z9OyiGzhEeVV7VL3pByY03OGQLOGjQhlGIWNp9mXOibg143lOb
GIM+e1WpeURVrqEveirJ4Rl2WaI0Ncv9fnzP+REyWGp1MjCRHmxF3UxU23HrDYQF
nuyo5xLLSmsJoYppIaJ9zZK+dxOquMB649yZj5IoeTQRHwsxvntGA/Emq1cc32hI
dAcdDtJPSd6gWGYFqxWFBPxujkHiUDxwjKtLgx4INesgkVaCbF87hRfSYcBLJCRp
s3I90lvYRws=
=eYPm
-----END PGP SIGNATURE-----

--xbxyguyUcy/oJisi--


From nobody Thu Oct 29 07:33:16 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95BD1B2F15 for ; Thu, 29 Oct 2015 07:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNivrbHSpM2H for ; Thu, 29 Oct 2015 07:33:11 -0700 (PDT)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394191B2F0E for ; Thu, 29 Oct 2015 07:33:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TEXDqY014964; Thu, 29 Oct 2015 07:33:13 -0700
Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TEXCbc014958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Oct 2015 07:33:12 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.201]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 07:33:08 -0700
From: "Templin, Fred L" 
To: Alexandre Petrescu 
Thread-Topic: [v6ops] how /63 helps tethering - addressing architecture
Thread-Index: AQHREla7zfg2tClrTUqcVVgnBeyeig==
Date: Thu, 29 Oct 2015 14:33:09 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F3397A@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com> <5630A6FA.9020602@gmail.com> <2134F8430051B64F815C691A62D9831832F31FFF@XCH-BLV-504.nw.nos.boeing.com> <563203E9.4030405@gmail.com>
In-Reply-To: <563203E9.4030405@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] how /63 helps tethering - addressing architecture
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:33:14 -0000

SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k
cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50
OiBUaHVyc2RheSwgT2N0b2JlciAyOSwgMjAxNSA0OjMzIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVk
IEwNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGhvdyAvNjMg
aGVscHMgdGV0aGVyaW5nIC0gYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUNCj4gDQo+IEZyZWQsDQo+
IA0KPiBMZSAyOC8xMC8yMDE1IDE3OjAzLCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiBb
Li4uXQ0KPiA+PiBXZSBjYW4gYXNrIHRoZSBvcGVyYXRvciB0byBzaG93IHRoZSBJUHY2IGFkZHJl
c3NpbmcgYXJjaGl0ZWN0dXJlIGxhaWQgb24NCj4gPj4gdGhlIG9wZXJhdG9yIHRvcG9sb2d5LCBz
dWJzdGl0dXRpbmcgIjIwMDE6ZGI4OjoiIHdoZXJlIG5lY2Vzc2FyeS4gIEkNCj4gPj4gc3VwcG9z
ZSB0aGlzIHdpbGwgaGVscC4NCj4gPg0KPiA+IFRoZSBvcGVyYXRvcidzIHNlcnZpY2UgcHJlZml4
IChlLmcuLCBhIC8zMiBvciBzb21ldGhpbmcpIHNob3VsZCBiZSB3ZWxsDQo+ID4ga25vd24uIFVF
IHByZWZpeGVzIHNob3VsZCBiZSBkZXJpdmVkIGZyb20gdGhlIHNlcnZpY2UgcHJlZml4IGFuZA0K
PiA+IGRlbGVnYXRlZCBhY2NvcmRpbmcgdG8gdGhlIFVFJ3MgbmVlZHMsIGFuZCBub3QgbmVjZXNz
YXJpbHkgYm91bmQNCj4gPiB0byB0aGUgb3BlcmF0b3IncyB0b3BvbG9neS4NCj4gDQo+IEkgYWdy
ZWUuICBJdCBzb3VuZHMgbGlrZSBhIGdvb2Qgc3RhcnQgZm9yIGRlc2lnbmluZyBhbiBJUHY2IGFk
ZHJlc3MNCj4gYXJjaGl0ZWN0dXJlIGZvciBhIGpqbWItbGlrZSB0b3BvbG9neS4NCj4gDQo+IEJ1
dCBpdCBzaG91bGQgYmUgZG9uZSBjYXJlZnVsbHksIGluIG9yZGVyIHRvIGFsbG93IGZvciBmdXR1
cmUgdXNlIG9mDQo+IFByZWZpeCBEZWxlZ2F0aW9uIGZvciBmdXR1cmUgdGV0aGVyaW5nIFVFcy4g
IElmIG5vdCBkb25lIGNhcmVmdWxseSBhdA0KPiB0aGUgc3RhcnQsIHRoZSBhZGRyZXNzaW5nIGFy
Y2hpdGVjdHVyZSByaXNrcyBmb3JiaWRkaW5nIFByZWZpeA0KPiBEZWxlZ2F0aW9uIGxhdGVyIChi
ZWNhdXNlIGluIElQdjYgdGhlcmUgaXMgbm8gTkFUIHRvIGV4dGVuZCB0aGUgbmV0d29yaywNCj4g
YW5kIHRoZXJlIGlzIGEgYm91bmRhcnkgYXQgLzY0KS4NCj4gDQo+IE1heSBJIGV4cGxhaW4uDQo+
IA0KPiBJbiB0aGUgc3RyYWlnaGZvcndhcmQgd2F5IDIwMDE6ZGI4OjE6Oi80OCBpcyBhc3NpZ25l
ZCBmb3IgYWNjZXNzIHRocm91Z2gNCj4gQVAxLCAyMDAxOmRiODoyOjovNDggdGhyb3VnaCBBUDIg
YW5kIHNvIG9uOyBmb3IgVUVzIHdlIHJlc2VydmUNCj4gMjAwMTpkYjg6MToxOjovNjQgdG8gMTpu
IHRocm91Z2ggQVAxIGFuZCBzbyBvbi4gIEJ1dCBsYXRlciB3ZSByZWFsaXplIHdlDQo+IGhhdmUg
bm8gc3BhY2UgbGVmdCBmb3IgYWxsb2NhdGluZyAvNjQgcHJlZml4ZXMgdG8gZnV0dXJlIHRldGhl
cmluZyBVRXMuDQoNCk5vdCB3aGF0IEkgaGFkIGluIG1pbmQuIElmIHRoZSB0dW5uZWwgd2VyZSB0
byBleHRlbmQgYWxsIHRoZSB3YXkgdG8gdGhlDQpVRSwgdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0
byBhc3NpZ24gMjAwMTpkYjg6Kjo6LzQ4IHByZWZpeGVzIHRvIGFuDQpBUC4gVGhlcmUgd291bGQg
YmUgb25seSB0aGUgLzMyIChvciBzaW1pbGFyKSBvcGVyYXRvcidzIHNlcnZpY2UgcHJlZml4DQph
bmQgdGhlIC82NCAob3Igc2ltaWxhcikgVUUgcHJlZml4ZXMuIENvbXBsZXRlIGRlLWFnZ3JlZ2F0
aW9uLiBUaGlzDQphbGxvd3MgVUVzIHRvIHNlYW1sZXNzbHkgcm9hbSBiZXR3ZWVuIEFQcyBhbmQg
ZXZlbiBiZXR3ZWVuDQpXTEFOLUdXcyB3aXRob3V0IG5lZWRpbmcgdG8gcmVudW1iZXIuDQoNCkFs
bCBpdCB3b3VsZCB0YWtlIHdvdWxkIGJlIHRvIGluc3RhbGwgYSBsaXR0bGUgYXBwIG9uIHRoZSBV
RSAtIGVpdGhlciBieQ0KdGhlIG9wZXJhdG9yLCBvciBieSB0aGUgdXNlciB2aXNpdGluZyBhIHdl
YnNpdGUuIFRoZW4sIERIQ1B2Ni1QRCBhbmQNCm11bHRpLWFkZHJlc3NpbmcgYXJlIG1hZGUgYXZh
aWxhYmxlIHdpdGggZnVsbCBzdXBwb3J0IGZvciBtb2JpbGl0eSBhbmQNCnJvdXRlIG9wdGltaXph
dGlvbi4gSWYgdGhlcmUgYXJlIGFueSBxdWVzdGlvbnMgb24gaG93IHRoaXMgd29ya3MsDQplaXRo
ZXIgbGV0IG1lIGtub3cgb3IgaGF2ZSBhIGxvb2sgYXQgdGhlIEFFUk8gZHJhZnQuDQoNClRoYW5r
cyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAgIEl0IGlzIGlsbHVzdHJh
dGVkOg0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t
LS0tKw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFBQSB8
DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLSsNCj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYWRpdXMNCj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gMjAwMTpkYjg6ZmZmZjoxOjovNjQNCj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tKw0KPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBDUCB8DQo+ICAgICAgICAgICAgICAgICAgKy0t
LS0rICAgICAgICAgICAgICArLS0tLS0tLS0tKw0KPiBVRTEuLlVFbi04MDIuMTEtfCBBUCB8LS0t
U29mdF9HUkUtLS18IFdMQU4tR1cgfC0tLS1JbnRlcm5ldC9XQU4NCj4gICAgICAgICAgICAgICAg
ICArLS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgIDIwMDE6ZGI4OjovMzINCj4gICAg
ICAgICAgICAyMDAxOmRiODoxOjE6Oi82NCAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgIDIw
MDE6ZGI4OjE6Mjo6LzY0ICAgICAgICAgICBJUC9IVFRQDQo+ICAgICAgICAgICAgICAgIC4uLiAg
ICAgICAgICAgICAgICAgICAgICAgIHwgMjAwMTpkYjg6ZmZmZjoyOjovNjQNCj4gICAgICAgICAg
ICAyMDAxOmRiODoxOm46Oi82NCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IEhUVFAgQ2FwdGl2ZSBQb3J0YWwgfA0KPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gDQo+IA0K
PiBBIGJldHRlciB3YXkgaXMgdG8gcmVmaW5lIGZyb20gdGhlIHN0YXJ0IGEgcGFydCBvZiB0aGUg
cHJlZml4IHRvIHJlc2VydmUNCj4gaXQgZm9yIGZ1dHVyZSBwcmVmaXggYWxsb2NhdGlvbnMgZm9y
IHRldGhlcmluZyBVRXMuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKy0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCBBQUEgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKy0tLS0tKw0KPiBQRC1hbGxvY2F0ZWQgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC8NCj4gMjAwMTpkYjg6MDIwMToxOjovNjQgICAgICAgICAgICAgICAgICAg
ICAgICAgUmFkaXVzDQo+IDIwMDE6ZGI4OjAyMDE6Mjo6LzY0ICAgICAgICAgICAgICAgICAgICAg
ICAgIC8gMjAwMTpkYjg6ZmYwMDoxOjovNjQNCj4gICAgLi4uICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICArLS0tLSsNCj4gMjAwMTpkYjg6MDIwMTpuOjovNjQgICAgICAgICAgICAg
ICAgICAgIHwgQ1AgfA0KPiAgICAgICAgICAgICAgICAgICAgICArLS0tLSsgICAgICAgICAgICAg
ICstLS0tLS0tLS0rDQo+ICAgICAgICAgIFVFLS04MDIuMTEtLXwgQVAgfC0tLVNvZnRfR1JFLS0t
fCBXTEFOLUdXIHwtLS0tSW50ZXJuZXQvV0FODQo+ICAgICAgICAgICAgICAgICAgICAgICstLS0t
KyAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgMjAwMTpkYjg6Oi8zMg0KPiAgICAgICAgICAg
ICAyMDAxOmRiODowMTAxOjE6Oi82NCAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAyMDAx
OmRiODowMTAxOjI6Oi82NCAgICAgICAgICAgSVAvSFRUUA0KPiAgICAgICAgICAgICAgICAgICAg
Li4uICAgICAgICAgICAgICAgICAgICAgICAgfCAyMDAxOmRiODpmZjAwOjI6Oi82NA0KPiAgICAg
ICAgICAgICAyMDAxOmRiODowMTAxOm46Oi82NCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBIVFRQIENhcHRpdmUgUG9ydGFs
IHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKw0KPiANCj4gSSBkbyBub3Qga25vdyB3aGF0IGlzIHRoZSBJUHY2IGFkZHJlc3Npbmcg
YXJjaGl0ZWN0dXJlIG9uIHRoZSBqam1iDQo+IHRvcG9sb2d5LCBhbmQgSSBob3BlIGl0IGlzIHJl
YWR5IGZvciBQcmVmaXggRGVsZWdhdGlvbiB0byB0ZXRoZXJpbmcgVUVzLg0KPiANCj4gQWxleA0K
DQo=


From nobody Thu Oct 29 07:38:17 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBE81A88F1 for ; Thu, 29 Oct 2015 07:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a0fVFGRsFMG for ; Thu, 29 Oct 2015 07:38:13 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7491A88EB for ; Thu, 29 Oct 2015 07:38:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TEc9x5016303; Thu, 29 Oct 2015 15:38:10 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2E5E120521F; Thu, 29 Oct 2015 15:44:02 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 19164205007; Thu, 29 Oct 2015 15:44:02 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TEc9cv012980; Thu, 29 Oct 2015 15:38:10 +0100
To: Gert Doering 
References:  <562957D8.4040001@gmail.com> <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com> <20151029140556.GN70452@Space.Net> <563229D7.9080401@gmail.com> <20151029141643.GO70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <56322F51.7010600@gmail.com>
Date: Thu, 29 Oct 2015 15:38:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151029141643.GO70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:38:15 -0000

Le 29/10/2015 15:16, Gert Doering a écrit :
> Hi,
>
> On Thu, Oct 29, 2015 at 03:14:47PM +0100, Alexandre Petrescu wrote:
>> Le 29/10/2015 15:05, Gert Doering a écrit :
>>> On Thu, Oct 29, 2015 at 02:43:55PM +0100, Alexandre Petrescu wrote:
>>>> Gert - have you noticed jjmb is 'prefix-per-host'?
>>>
>>> Yes, and what exactly does this have to do with "/63 in RAs, with SLAAC"?
>>
>> If done it helps with tethering.
>
> No, as you have already discovered.
>
> And note that "a gateway routing a /63 over a point-to-point link" is
> NOT the same as "a /63 put on-link by means of RA".

I can agree.

But "a /63 put on-link by means of RA" can not happen without "a gateway 
routing that /63 to that link (be it '*' or address)".

If someone puts a /63 (or /64 for that matter) on-link and does not 
route to it then someone disconnects it from the Internet.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Oct 29 07:40:11 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057091B2F1D for ; Thu, 29 Oct 2015 07:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a5ehK6KxrZA for ; Thu, 29 Oct 2015 07:40:08 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981911B2ED8 for ; Thu, 29 Oct 2015 07:40:05 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B51AA62DC4 for ; Thu, 29 Oct 2015 15:40:03 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 32C5560A5D for ; Thu, 29 Oct 2015 15:40:03 +0100 (CET)
Received: (qmail 95316 invoked by uid 1007); 29 Oct 2015 15:40:03 +0100
Date: Thu, 29 Oct 2015 15:40:03 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20151029144002.GR70452@Space.Net>
References: <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com> <20151029140556.GN70452@Space.Net> <563229D7.9080401@gmail.com> <20151029141643.GO70452@Space.Net> <56322F51.7010600@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QYVFs1t3HuQX5nvE"
Content-Disposition: inline
In-Reply-To: <56322F51.7010600@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:40:10 -0000

--QYVFs1t3HuQX5nvE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Oct 29, 2015 at 03:38:09PM +0100, Alexandre Petrescu wrote:
> > And note that "a gateway routing a /63 over a point-to-point link" is
> > NOT the same as "a /63 put on-link by means of RA".
>=20
> I can agree.
>=20
> But "a /63 put on-link by means of RA" can not happen without "a gateway=
=20
> routing that /63 to that link (be it '*' or address)".
>=20
> If someone puts a /63 (or /64 for that matter) on-link and does not=20
> route to it then someone disconnects it from the Internet.

You totally do not seem to understand the difference between "routing=20
across a link" and "*on* a link", like "with ND for every address in it".

I will now totally ignore you, which I should have done much earlier.

Apologies to the list for contributing noise.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--QYVFs1t3HuQX5nvE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVjIvwt9WwGXkzn/FAQJf/w/5AauZb1L8GScAlJcuBNnyEMi4MO7BnC9d
qiV3MtIyOyh2eNMZsb4+bONRHIqIa/9fxeICaO9tyLPgPrMRFAsdjpzzqUSaMM1t
WXJOIHgAqSzW3Og3FQJrXjcCj63egcEng/4C2uuwHJNHRtEAaanH2uzGsvs0E/M8
mVV4Xtm3UQoM6CjLFxCGyACiyy+UaQzKePY4Pjyktq3i8q7LeyRbD1Bs9Zmt4HlI
kL5VAuApsxuXnR8TR44DCETdZCDnoHYmMbTLwMNgIjWn52LbVf6I2T8rP9VHs8sc
3GcU+m4dH1yzmf7vydQ2lr8ilzsalV1Yig/EMCi+Xwz1yInQyqBX5yD1X31NNXZW
D70sNaNdl/G7c1KMuRyW9j1sq1PkifFOvGKHhoMxWjN97RAn+6sRVMvb/yO5YJ1V
JbYcF6/yi21PKl+54fXBz8RDPCEwodUEGuPjBLllknJfnFiba9AsUoLCbgJtPDaO
K7S9nw96EEAy/SQBlEcERQZD8MademKuegCb55jeLiLoQ3rkmrP/LKL+1AOwL1Og
wqfBW0ote5itw0BSQi254Qcs7+9Fh75MXKl3DpCot+1CHTj4KHyZsTbe6VFE04Uu
OSpRCvER8McfSj132M3WeYxM6W9xxZA9eP+dZMvpLLYPYU84LzjKd+7mUwkEesTl
i/Au8ZErxKM=
=R5+q
-----END PGP SIGNATURE-----

--QYVFs1t3HuQX5nvE--


From nobody Thu Oct 29 07:53:23 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA761A8756 for ; Thu, 29 Oct 2015 07:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0glZrA8sfeFr for ; Thu, 29 Oct 2015 07:53:20 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B601A8755 for ; Thu, 29 Oct 2015 07:53:19 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t9TErF7i016602; Thu, 29 Oct 2015 15:53:17 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30E4B205201; Thu, 29 Oct 2015 15:59:09 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 252F72050C4; Thu, 29 Oct 2015 15:59:09 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t9TErGMC023789; Thu, 29 Oct 2015 15:53:17 +0100
To: Gert Doering 
References: <562985AA.7030202@gont.com.ar> <5629975E.6040702@gmail.com> <20151023065543.GA70452@Space.Net> <5629EED2.8050000@gmail.com> <20151029132325.GM70452@Space.Net> <5632229B.3070208@gmail.com> <20151029140556.GN70452@Space.Net> <563229D7.9080401@gmail.com> <20151029141643.GO70452@Space.Net> <56322F51.7010600@gmail.com> <20151029144002.GR70452@Space.Net>
From: Alexandre Petrescu 
Message-ID: <563232DC.70403@gmail.com>
Date: Thu, 29 Oct 2015 15:53:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151029144002.GR70452@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 14:53:22 -0000

Le 29/10/2015 15:40, Gert Doering a écrit :
> Hi,
>
> On Thu, Oct 29, 2015 at 03:38:09PM +0100, Alexandre Petrescu wrote:
>>> And note that "a gateway routing a /63 over a point-to-point link" is
>>> NOT the same as "a /63 put on-link by means of RA".
>>
>> I can agree.
>>
>> But "a /63 put on-link by means of RA" can not happen without "a gateway
>> routing that /63 to that link (be it '*' or address)".
>>
>> If someone puts a /63 (or /64 for that matter) on-link and does not
>> route to it then someone disconnects it from the Internet.
>
> You totally do not seem to understand the difference between "routing
> across a link" and "*on* a link", like "with ND for every address in it".

I dont know what makes you think I dont understand...

In the jjmb draft context, advertising a prefix on a link can not happen 
without routing to that prefix.

Putting a /63 in an RA, means that the UE will benefit of that prefix 
being routed to it.

Putting a /64 in the RA (nothing else than that precise figure "64"), 
means that the UE can not use anything else than just that /64.  If more 
is needed, then a new routing entry must be added in the gateway for 
this additional prefix.

I think an operator that does not want to deploy DHCP-PD will not want 
to add these new prefixes in the gateways either.

As for statements about ignoring somebody: it's called killfiling 
someone and your MUA is free to do so.  I wonder why it did not do it 
until now.

Alex

>
> I will now totally ignore you, which I should have done much earlier.
>
> Apologies to the list for contributing noise.
>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Oct 29 09:00:22 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37B61A8904 for ; Thu, 29 Oct 2015 09:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZnGH3sj5XGd for ; Thu, 29 Oct 2015 09:00:19 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF6B1A8982 for ; Thu, 29 Oct 2015 09:00:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TG0Hsr060229; Thu, 29 Oct 2015 09:00:17 -0700
Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TG0668059792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Oct 2015 09:00:06 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.149]) with mapi id 14.03.0235.001;  Thu, 29 Oct 2015 09:00:05 -0700
From: "Templin, Fred L" 
To: Alexandre Petrescu 
Thread-Topic: [v6ops] how /63 helps tethering - addressing architecture
Thread-Index: AQHREla7zfg2tClrTUqcVVgnBeyeip6DFmuw
Date: Thu, 29 Oct 2015 16:00:05 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F33BF3@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com>  <5628E3DA.4010905@gmail.com> <021A1305-537D-468D-B1DD-791EDE6E81F1@employees.org> <56290F0B.5090702@gmail.com> <20151022164925.GU70452@Space.Net>  <5629EEF3.3080404@gmail.com>   <2134F8430051B64F815C691A62D9831832F30F94@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F311FE@XCH-BLV-504.nw.nos.boeing.com> <5630A6FA.9020602@gmail.com> <2134F8430051B64F815C691A62D9831832F31FFF@XCH-BLV-504.nw.nos.boeing.com> <563203E9.4030405@gmail.com> <2134F8430051B64F815C691A62D9831832F3397A@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F3397A@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] how /63 helps tethering - addressing architecture
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 16:00:21 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0bzp2
Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBMDQo+IFNl
bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI5LCAyMDE1IDc6MzMgQU0NCj4gVG86IEFsZXhhbmRyZSBQ
ZXRyZXNjdQ0KPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gaG93
IC82MyBoZWxwcyB0ZXRoZXJpbmcgLSBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZQ0KPiANCj4gSGkg
QWxleCwNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBBbGV4
YW5kcmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiA+
IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI5LCAyMDE1IDQ6MzMgQU0NCj4gPiBUbzogVGVtcGxp
biwgRnJlZCBMDQo+ID4gQ2M6IHY2b3BzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFt2Nm9w
c10gaG93IC82MyBoZWxwcyB0ZXRoZXJpbmcgLSBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZQ0KPiA+
DQo+ID4gRnJlZCwNCj4gPg0KPiA+IExlIDI4LzEwLzIwMTUgMTc6MDMsIFRlbXBsaW4sIEZyZWQg
TCBhIMOpY3JpdCA6DQo+ID4gWy4uLl0NCj4gPiA+PiBXZSBjYW4gYXNrIHRoZSBvcGVyYXRvciB0
byBzaG93IHRoZSBJUHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGxhaWQgb24NCj4gPiA+PiB0
aGUgb3BlcmF0b3IgdG9wb2xvZ3ksIHN1YnN0aXR1dGluZyAiMjAwMTpkYjg6OiIgd2hlcmUgbmVj
ZXNzYXJ5LiAgSQ0KPiA+ID4+IHN1cHBvc2UgdGhpcyB3aWxsIGhlbHAuDQo+ID4gPg0KPiA+ID4g
VGhlIG9wZXJhdG9yJ3Mgc2VydmljZSBwcmVmaXggKGUuZy4sIGEgLzMyIG9yIHNvbWV0aGluZykg
c2hvdWxkIGJlIHdlbGwNCj4gPiA+IGtub3duLiBVRSBwcmVmaXhlcyBzaG91bGQgYmUgZGVyaXZl
ZCBmcm9tIHRoZSBzZXJ2aWNlIHByZWZpeCBhbmQNCj4gPiA+IGRlbGVnYXRlZCBhY2NvcmRpbmcg
dG8gdGhlIFVFJ3MgbmVlZHMsIGFuZCBub3QgbmVjZXNzYXJpbHkgYm91bmQNCj4gPiA+IHRvIHRo
ZSBvcGVyYXRvcidzIHRvcG9sb2d5Lg0KPiA+DQo+ID4gSSBhZ3JlZS4gIEl0IHNvdW5kcyBsaWtl
IGEgZ29vZCBzdGFydCBmb3IgZGVzaWduaW5nIGFuIElQdjYgYWRkcmVzcw0KPiA+IGFyY2hpdGVj
dHVyZSBmb3IgYSBqam1iLWxpa2UgdG9wb2xvZ3kuDQo+ID4NCj4gPiBCdXQgaXQgc2hvdWxkIGJl
IGRvbmUgY2FyZWZ1bGx5LCBpbiBvcmRlciB0byBhbGxvdyBmb3IgZnV0dXJlIHVzZSBvZg0KPiA+
IFByZWZpeCBEZWxlZ2F0aW9uIGZvciBmdXR1cmUgdGV0aGVyaW5nIFVFcy4gIElmIG5vdCBkb25l
IGNhcmVmdWxseSBhdA0KPiA+IHRoZSBzdGFydCwgdGhlIGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJl
IHJpc2tzIGZvcmJpZGRpbmcgUHJlZml4DQo+ID4gRGVsZWdhdGlvbiBsYXRlciAoYmVjYXVzZSBp
biBJUHY2IHRoZXJlIGlzIG5vIE5BVCB0byBleHRlbmQgdGhlIG5ldHdvcmssDQo+ID4gYW5kIHRo
ZXJlIGlzIGEgYm91bmRhcnkgYXQgLzY0KS4NCj4gPg0KPiA+IE1heSBJIGV4cGxhaW4uDQo+ID4N
Cj4gPiBJbiB0aGUgc3RyYWlnaGZvcndhcmQgd2F5IDIwMDE6ZGI4OjE6Oi80OCBpcyBhc3NpZ25l
ZCBmb3IgYWNjZXNzIHRocm91Z2gNCj4gPiBBUDEsIDIwMDE6ZGI4OjI6Oi80OCB0aHJvdWdoIEFQ
MiBhbmQgc28gb247IGZvciBVRXMgd2UgcmVzZXJ2ZQ0KPiA+IDIwMDE6ZGI4OjE6MTo6LzY0IHRv
IDE6biB0aHJvdWdoIEFQMSBhbmQgc28gb24uICBCdXQgbGF0ZXIgd2UgcmVhbGl6ZSB3ZQ0KPiA+
IGhhdmUgbm8gc3BhY2UgbGVmdCBmb3IgYWxsb2NhdGluZyAvNjQgcHJlZml4ZXMgdG8gZnV0dXJl
IHRldGhlcmluZyBVRXMuDQo+IA0KPiBOb3Qgd2hhdCBJIGhhZCBpbiBtaW5kLiBJZiB0aGUgdHVu
bmVsIHdlcmUgdG8gZXh0ZW5kIGFsbCB0aGUgd2F5IHRvIHRoZQ0KPiBVRSwgdGhlcmUgd291bGQg
YmUgbm8gbmVlZCB0byBhc3NpZ24gMjAwMTpkYjg6Kjo6LzQ4IHByZWZpeGVzIHRvIGFuDQo+IEFQ
LiBUaGVyZSB3b3VsZCBiZSBvbmx5IHRoZSAvMzIgKG9yIHNpbWlsYXIpIG9wZXJhdG9yJ3Mgc2Vy
dmljZSBwcmVmaXgNCj4gYW5kIHRoZSAvNjQgKG9yIHNpbWlsYXIpIFVFIHByZWZpeGVzLiBDb21w
bGV0ZSBkZS1hZ2dyZWdhdGlvbi4gVGhpcw0KPiBhbGxvd3MgVUVzIHRvIHNlYW1sZXNzbHkgcm9h
bSBiZXR3ZWVuIEFQcyBhbmQgZXZlbiBiZXR3ZWVuDQo+IFdMQU4tR1dzIHdpdGhvdXQgbmVlZGlu
ZyB0byByZW51bWJlci4NCj4gDQo+IEFsbCBpdCB3b3VsZCB0YWtlIHdvdWxkIGJlIHRvIGluc3Rh
bGwgYSBsaXR0bGUgYXBwIG9uIHRoZSBVRSAtIGVpdGhlciBieQ0KPiB0aGUgb3BlcmF0b3IsIG9y
IGJ5IHRoZSB1c2VyIHZpc2l0aW5nIGEgd2Vic2l0ZS4gVGhlbiwgREhDUHY2LVBEIGFuZA0KPiBt
dWx0aS1hZGRyZXNzaW5nIGFyZSBtYWRlIGF2YWlsYWJsZSB3aXRoIGZ1bGwgc3VwcG9ydCBmb3Ig
bW9iaWxpdHkgYW5kDQo+IHJvdXRlIG9wdGltaXphdGlvbi4gSWYgdGhlcmUgYXJlIGFueSBxdWVz
dGlvbnMgb24gaG93IHRoaXMgd29ya3MsDQo+IGVpdGhlciBsZXQgbWUga25vdyBvciBoYXZlIGEg
bG9vayBhdCB0aGUgQUVSTyBkcmFmdC4NCg0KTGV0IG1lIGFtZW5kIHdoYXQgSSBzYWlkIHNsaWdo
dGx5IGJ5IHNheWluZyB0aGUgY29tcGxldGVseSBkZS1hZ2dyZWdhdGVkDQphcHByb2FjaCBhcHBs
aWVzIGFsc28gd2hlbiB0aGUgdHVubmVsIGVuZHMgYXQgdGhlIEFQLiBJbiB0aGF0IGNhc2UsIFBy
b3h5DQpBRVJPIHdvdWxkIGJlIHVzZWQsIGFuZCB0aGUgVUVzIHdvdWxkIG5vdCBuZWVkIHRvIGlu
c3RhbGwgYW55IHNvZnR3YXJlLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2Vp
bmcuY29tDQoNCj4gVGhhbmtzIC0gRnJlZA0KPiBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+
IA0KPiA+ICAgSXQgaXMgaWxsdXN0cmF0ZWQ6DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0rDQo+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfCBBQUEgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICstLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAvDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgUmFkaXVzDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIC8gMjAwMTpkYjg6ZmZmZjoxOjovNjQNCj4gPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKy0tLS0rDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgQ1AgfA0KPiA+ICAgICAgICAgICAgICAgICAgKy0tLS0rICAgICAgICAgICAg
ICArLS0tLS0tLS0tKw0KPiA+IFVFMS4uVUVuLTgwMi4xMS18IEFQIHwtLS1Tb2Z0X0dSRS0tLXwg
V0xBTi1HVyB8LS0tLUludGVybmV0L1dBTg0KPiA+ICAgICAgICAgICAgICAgICAgKy0tLS0rICAg
ICAgICAgICAgICArLS0tLS0tLS0tKyAgICAyMDAxOmRiODo6LzMyDQo+ID4gICAgICAgICAgICAy
MDAxOmRiODoxOjE6Oi82NCAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgMjAwMTpkYjg6
MToyOjovNjQgICAgICAgICAgIElQL0hUVFANCj4gPiAgICAgICAgICAgICAgICAuLi4gICAgICAg
ICAgICAgICAgICAgICAgICB8IDIwMDE6ZGI4OmZmZmY6Mjo6LzY0DQo+ID4gICAgICAgICAgICAy
MDAxOmRiODoxOm46Oi82NCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgSFRUUCBDYXB0aXZlIFBvcnRhbCB8DQo+ID4gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4NCj4g
Pg0KPiA+IEEgYmV0dGVyIHdheSBpcyB0byByZWZpbmUgZnJvbSB0aGUgc3RhcnQgYSBwYXJ0IG9m
IHRoZSBwcmVmaXggdG8gcmVzZXJ2ZQ0KPiA+IGl0IGZvciBmdXR1cmUgcHJlZml4IGFsbG9jYXRp
b25zIGZvciB0ZXRoZXJpbmcgVUVzLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICstLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCBBQUEgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0rDQo+ID4gUEQtYWxsb2NhdGVkICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+ID4gMjAwMTpkYjg6MDIwMToxOjovNjQg
ICAgICAgICAgICAgICAgICAgICAgICAgUmFkaXVzDQo+ID4gMjAwMTpkYjg6MDIwMToyOjovNjQg
ICAgICAgICAgICAgICAgICAgICAgICAgLyAyMDAxOmRiODpmZjAwOjE6Oi82NA0KPiA+ICAgIC4u
LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0rDQo+ID4gMjAwMTpkYjg6
MDIwMTpuOjovNjQgICAgICAgICAgICAgICAgICAgIHwgQ1AgfA0KPiA+ICAgICAgICAgICAgICAg
ICAgICAgICstLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLSsNCj4gPiAgICAgICAgICBVRS0t
ODAyLjExLS18IEFQIHwtLS1Tb2Z0X0dSRS0tLXwgV0xBTi1HVyB8LS0tLUludGVybmV0L1dBTg0K
PiA+ICAgICAgICAgICAgICAgICAgICAgICstLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLSsg
ICAgMjAwMTpkYjg6Oi8zMg0KPiA+ICAgICAgICAgICAgIDIwMDE6ZGI4OjAxMDE6MTo6LzY0ICAg
ICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgMjAwMTpkYjg6MDEwMToyOjovNjQgICAgICAg
ICAgIElQL0hUVFANCj4gPiAgICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAg
ICAgICAgfCAyMDAxOmRiODpmZjAwOjI6Oi82NA0KPiA+ICAgICAgICAgICAgIDIwMDE6ZGI4OjAx
MDE6bjo6LzY0ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgSFRUUCBDYXB0aXZlIFBvcnRhbCB8DQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+DQo+
ID4gSSBkbyBub3Qga25vdyB3aGF0IGlzIHRoZSBJUHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJl
IG9uIHRoZSBqam1iDQo+ID4gdG9wb2xvZ3ksIGFuZCBJIGhvcGUgaXQgaXMgcmVhZHkgZm9yIFBy
ZWZpeCBEZWxlZ2F0aW9uIHRvIHRldGhlcmluZyBVRXMuDQo+ID4NCj4gPiBBbGV4DQo+IA0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBt
YWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby92Nm9wcw0K


From nobody Thu Oct 29 10:18:08 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B91B2FCB for ; Thu, 29 Oct 2015 10:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.525
X-Spam-Level: 
X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpwXcJg3IQQJ for ; Thu, 29 Oct 2015 10:18:05 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738B21B2FC0 for ; Thu, 29 Oct 2015 10:18:05 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-43-563254cba9f3
Received: from pacdcexhub04.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 9F.5F.04607.BC452365; Thu, 29 Oct 2015 13:18:04 -0400 (EDT)
Received: from VAADCEX16.cable.comcast.com (147.191.102.83) by pacdcexhub04.cable.comcast.com (24.40.56.121) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 29 Oct 2015 13:17:27 -0400
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX16.cable.comcast.com (147.191.102.83) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 29 Oct 2015 13:17:26 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1044.021; Thu, 29 Oct 2015 13:17:26 -0400
From: "Brzozowski, John" 
To: "otroan@employees.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= , Tore Anderson 
Thread-Topic: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREm2u7EnpTKekgECh/J1+n77SuQ==
Date: Thu, 29 Oct 2015 17:17:26 +0000
Message-ID: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.10]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42JxCVeS0T0TYhRmcPudiMWi3QfYLCa3rWCz 2HLwDqPF6WN7mR1YPA4e+8jo8bd3JrvHkiU/mTz2Pj3GFsASxWWTkpqTWZZapG+XwJWx6Og9 toJTEhV96/awNTD+EO9i5OSQEDCR2LljKQuELSZx4d56ti5GLg4hgV1MEnPXHmCBcA4wSnTf 3cwO4RxklOi7NY0VwjnJKNHTcxCsn03ARuL1h5+MIAkRgSZGiaXrvjN3MXJwMAuoSsz+ww9S IywQJrGs8yILSFhEIFxixZ0CkLCIgJ7ExTlv2EFsFqDqm3NvsoLYvAL2Ep9vfYXatYJJ4sGU FrBdnAKOEi8nX2YEsRmB7v5+ag0TiM0sIC5x68l8Joh/BCSW7DnPDGGLSrx8/A9sqCjQsvZT /9kg4gYSW5fug/pfXuLIhH8sECdrSqzfpQ8x0kHifWsvM4StKDGl+yE7xG2CEidnPgErFwIa Oe+BNMQUcYnDR3awTmCUnYXkoFkIQ2chGToLydBZSIYuYGRdxShXkJickpybkV9aYmCol5yY lJOql5yfm5xYXAKiNzGCE4f88h2M9144HWIU4GBU4uH95WEUJsSaWFZcmXuIUYKDWUmEd6k9 UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv5nu/QoUE0hNLUrNTUwtSi2CyTBycUg2M/MLNWY/U t29Yprb03oLgSP40nh39O4NdWZkY4lftTcrQ/7YxuEv+kOPmuUn7BR9bbAo/bdK1/NSms6oq Vxk0Tu2ZYxboX+nY5+xwW7xPtdbtQGxtZM4uj0Il6VRGn6ezJwpkJUn83r904TPT2b4TG5fd meQistf8E6fp5Q0Lt19b9f/w/HwNJZbijERDLeai4kQA0Y7CZhgDAAA=
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 17:18:06 -0000

U2VlIGJlbG93Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiB2Nm9wcyA8
djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE9sZSBUcsO4YW4NCjxvdHJvYW5A
ZW1wbG95ZWVzLm9yZz4NCkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciAyOCwgMjAxNSBhdCAxOToy
MQ0KVG86IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+LCBUb3JlIEFuZGVyc29uIDx0
b3JlQGZ1ZC5ubz4NCkNjOiB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2
b3BzXSBJLUQgQWN0aW9uOg0KZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy
LWhvc3QtMDAudHh0DQoNCj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQgKGFuZCBJIGRvIHN0cmVzcyB0
aGF0KSwgdGhlIE0tZmxhZyBpbmRpY2F0ZXMgd2hldGhlcg0KPj4+IG9yIG5vdCAqYWRkcmVzc2Vz
KiBhcmUgYXZhaWxhYmxlIHZpYSBESENQdjYgKFJGQyA0ODYxIHM0LjIpLiBQcmVmaXhlcw0KPj4+
IChJQV9QRCkgaXMgc29tZXRoaW5nIGRpZmZlcmVudC4gVGhlcmVmb3JlLCBhc3N1bWluZyB0aGF0
IGF2YWlsYWJpbGl0eQ0KPj4+b2YNCj4+PiBJQV9QRCBpcyBzaWduYWxsZWQgdXNpbmcgUkEgZmxh
Z3MgdG8gYmVnaW4gd2l0aCwgdGhlbiBpdCBpcyAib3RoZXINCj4+PiBjb25maWd1cmF0aW9uIiBh
bmQgdGh1cyBzaWduYWxsZWQgd2l0aCB0aGUgTy1mbGFnLCBub3QgdGhlIE0tZmxhZy4gSQ0KPj4+
IGtub3cgb2YgYXQgbGVhc3Qgb25lIHdpcmVsaW5lIElTUCB0aGF0IGhhcyBzdWNoIGEgZGVwbG95
bWVudCwgaS5lLiwNCj4+PiB0aGV5IHN1cHBvcnQgREhDUHY2IElBX1BEIGJ1dCBub3QgSUFfTkEv
SUFfVEEsIGFuZCB0aGV5IHNpZ25hbCB0aGlzDQo+Pj4gdXNpbmcgTT0wICsgTz0xLg0KPj4gDQo+
PiBJbnRlcmVzdGluZyBwb2ludC4gIFBlcnNvbmFsbHkgSSd2ZSBiZWVuIGFzc3VtaW5nIHRoYXQg
dGhlIE8tZmxhZw0KPj4gYmVpbmcgb24gaW1wbGllcyAoaWYgYW55dGhpbmcpIGEgInN0YXRlbGVz
cyIgREhDUHY2IHNlcnZpY2UuICBUaGF0J3MNCj4+IHNpZ25pZmljYW50IGluIHRoaXMgY29udGV4
dCwgc2luY2UgdGhlIGNsaWVudCB3b3VsZCBzZW5kIGFuDQo+PiBJbmZvcm1hdGlvbi1yZXF1ZXN0
IG1lc3NhZ2UgZm9yIHN0YXRlbGVzcyBzZXJ2aWNlcywgd2hpbGUgcHJlZml4DQo+PiBkZWxlZ2F0
aW9uIHJlcXVpcmVzIGEgREhDUHY2IHNlc3Npb24gYmVnaW5uaW5nIHdpdGggYSBTb2xpY2l0IG1l
c3NhZ2UuDQo+PiBJJ20gbm90IHN1cmUgaG93IHdpZGVseSBteSBhc3N1bXB0aW9uIGlzIHNoYXJl
ZCwgYnV0LCBpbiBhbnkgY2FzZSwNCj4+IHRoZSBzcGVjaWZpY2F0aW9ucyBhcmUgYWN0dWFsbHkg
dW5jbGVhciBhcyB5b3UgaW5kaWNhdGVkIGFib3ZlLg0KPj4gDQo+PiAoQW5kLCBvZiBjb3Vyc2Us
IHRoZXJlIGlzIGFub3RoZXIgbGV2ZWwgb2YgaXNzdWUgdGhhdCB0aGUgc2VtYW50aWNzIG9mDQo+
PiBNTyBmbGFncyBpcyB0b28gdW5jbGVhciBpbiBnZW5lcmFsIGluIHRoZSBmaXJzdCBwbGFjZS4u
LikNCltqam1iXSBJIHRoaW5rIHRoZSBhYm92ZSBpcyBmcm9tIFRvcmUuICBUb3JlIEkgdGhpbmsg
bW9zdCBwZW9wbGUgd2hvIGhhdmUNCmRlcGxveWVkIElQdjYgc2hhcmUgdGhlIHNhbWUgaW50ZXJw
cmV0YXRpb24sIGF0IGxlYXN0IEkgZG8uDQo+DQo+REhDUHY2IFBEIGF2YWlsYWJpbGl0eSBpcyBu
b3Qgc2lnbmFsbGVkIHRocm91Z2ggTS9PIGJpdHMgb3IgUkFzIGF0IGFsbC4NCltqam1iXSBJIHRo
aW5rIHRoaXMgbWF5IGJlIHlvdXIgaW50ZXJwcmV0YXRpb24sIHNpbmNlIHRoZSBiZWdpbm5pbmcg
b2YgdGhlDQpJUHY2IGRlcGxveW1lbnQgYXQgQ29tY2FzdCBhbmQgdGhlIHdvcmsgd2UgZGlkIHNw
ZWNpZnlpbmcgSVB2NiBmb3IgRE9DU0lTDQp3ZSBoYXZlIHVzZWQgdGhlIE0vTyB0byBzaWduYWwg
dGhlIHVzZSBvZiBESENQdjYuDQo+dHdvIHJlYXNvbnMgZm9yIHRoYXQ7IGZpcnN0bHkgcm91dGVy
cyBkb24ndCB0eXBpY2FsbHkgcHJvY2VzcyBSb3V0ZXINCj5BZHZlcnRpc2VtZW50cywgc2Vjb25k
bHkgd2Ugd291bGQgaGF2ZSBuZWVkZWQgbW9yZSBmbGFncy4NCltqam1iXSByb3V0ZXJzIGRvIHBy
b2Nlc3MgUkFzLCB0aHVzIGZhciB+NzUlKyBvZiBteSBjdXN0b21lcnMgYXJlIG5hdGl2ZQ0KZHVh
bCBzdGFjayBlbmFibGVkIHVzaW5nIHRoZXNlIHRlY2huaXF1ZXMgd2l0aG91dCBpbmNpZGVudC4g
IE5vIGFkZGl0aW9uYWwNCmZsYWdzIGFwcGVhciB0byBiZSByZXF1aXJlZC4NCj4NCj5CZXN0IHJl
Z2FyZHMsDQo+T2xlDQoNCg==


From nobody Thu Oct 29 12:40:00 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36A1A8F40 for ; Thu, 29 Oct 2015 12:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHU3zI_wVWsP for ; Thu, 29 Oct 2015 12:39:58 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05781A8F49 for ; Thu, 29 Oct 2015 12:39:57 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=35360 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zrt39-0001oM-RM; Thu, 29 Oct 2015 20:39:51 +0100
Date: Thu, 29 Oct 2015 20:39:51 +0100
From: Tore Anderson 
To: Brian E Carpenter 
Message-ID: <20151029203951.06a4d4fd@envy.fud.no>
In-Reply-To: <5631232E.4020701@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 19:39:59 -0000

* Brian E Carpenter

> So Tore is slightly wrong: if the M flag is set, the O flag contains
> no information, whatever value it has. Don't even test it.
>=20
> If the M flag is clear, and the O flag is set, you can't get addresses.
> You can get some things from DHCPv6, but you don't know what. Maybe
> IA_PD is available, maybe not.
>=20
> If M=3DO=3D0, DHCPv6 is a waste of space.
>=20
> Or:
>=20
> if M=3D=3D1
>   {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
>    /*try to get IA_PD from DHCPv6 if you want*/;
>    /*try to get other DHCPv6 options if you want*/;}
>    else {/*get addresses using SLAAC*/;
>         if O=3D=3D1
>           {/*try to get IA_PD from DHCPv6 if you want*/;
>            /*try to get other DHCPv6 options if you want*/;}}

Hi Brian,

I am in 100% agreement with you, but I have clearly failed to express
this correctly. What I have been meaning to say is that IA_PD is
considered part of the "other configuration" (a.k.a. "not addresses")
class of DHCPv6 options whose availability can be explicitly signaled
through O=3D1 *or* implicitly through M=3D1.

So your pseudo-code above reads correct to me, and matches RFC 7084
WPD-4 as well as the wording in section 4.2 of RFC 4861.

My original point is that my reading of
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt suggests a
different and incorrect interpretation of the flags, which implies the
following new pseudo-code (removing IA_PD from your =C2=ABif O=3D=3D1 {}=C2=
=BB block):

if M=3D=3D1
  {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
   /*try to get IA_PD from DHCPv6 if you want*/;
   /*try to get other DHCPv6 options if you want*/;}
   else {/*get addresses using SLAAC*/;
        if O=3D=3D1
          {/*try to get other DHCPv6 options if you want*/;}}

That is, the draft suggests that the availability of IA_PD is tied to
the value of the M flag exclusively, instead of the boolean expression
(M OR O). I on the other hand believe (M OR O) is the correct
interpretation. I think we're in agreement on this point?

Tore


From nobody Thu Oct 29 14:00:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D551ACD39 for ; Thu, 29 Oct 2015 14:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu-wLxSjlTVF for ; Thu, 29 Oct 2015 14:00:03 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D8A1ACD36 for ; Thu, 29 Oct 2015 14:00:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TL02HR013360; Thu, 29 Oct 2015 14:00:02 -0700
Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TKxvCn012794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Oct 2015 13:59:57 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.48]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 13:59:56 -0700
From: "Templin, Fred L" 
To: Tore Anderson , Brian E Carpenter 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREoGT/+MZsnq7pUCTitCxpFGwKp6C8WDg
Date: Thu, 29 Oct 2015 20:59:55 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no>
In-Reply-To: <20151029203951.06a4d4fd@envy.fud.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 21:00:05 -0000

SGksIEkgd29uJ3QgZGlzYWdyZWUgd2l0aCBCcmlhbiBhbmQgVG9yZSBidXQgb24gc29tZSBJUHY2
IGxpbmtzIHdhaXRpbmcgdG8NCnJlY2VpdmUgYW4gUkEgbWF5IGJlIHJlZHVuZGFudCBhbmQgdW5u
ZWNlc3NhcnkgYmVmb3JlIGRpcmVjdGx5DQphdHRlbXB0aW5nIERIQ1B2NiBQRC4gT24gdGhvc2Ug
bGlua3MsIERIQ1B2NiBtZXNzYWdpbmcgYWxvbmUgbWF5DQpiZSBhbGwgdGhhdCBpcyBuZWNlc3Nh
cnksIGFuZCBubyBSUy9SQSBpcyByZXF1aXJlZC4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRl
bXBsaW5AYm9laW5nLmNvbQ0K


From nobody Thu Oct 29 14:42:22 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F941B31E5 for ; Thu, 29 Oct 2015 14:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk1G6yaVDUtL for ; Thu, 29 Oct 2015 14:42:19 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493E71B31E4 for ; Thu, 29 Oct 2015 14:42:19 -0700 (PDT)
Received: by pacfv9 with SMTP id fv9so54025924pac.3 for ; Thu, 29 Oct 2015 14:42:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=cu8D9epwO7Igg3lT6rt4LOzYtip21trPidSG4a5YirA=; b=YWiK/RNagejXN/0VSScOvtdwmE2c+RcjKU/SfN3O36qAnztGKouINtjXF5AVBMZK+w MRcTN1Gost3DKVTlMXvV5QDmtYthH4wahJwNqmafgiiDShG2XIkOy4c1/luA34KvkJH2 rVWv52iK7pMlap+Eu9spDCBMXbOqUO+O74YqEJAoE+wdW9iek/yaDsyZmH6BXTX+bxnj ZoqZUiRP4W53qKZ7ODQWxqb+/8pG5zZ71QJ2PImwDFkGL2KxezQdWrBaMV2sxpPg1uZK SO9gcoIiuTA7OvAl4aShEi7MT2t2uzThP+GjNIrBd/e5etc21DjmHl4Yz4NbC8e3xiMM EZ6Q==
X-Received: by 10.66.63.37 with SMTP id d5mr4273124pas.99.1446154938763; Thu, 29 Oct 2015 14:42:18 -0700 (PDT)
Received: from ?IPv6:2406:e007:704e:1:28cc:dc4c:9703:6781? ([2406:e007:704e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id qn5sm4042573pac.41.2015.10.29.14.42.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 14:42:17 -0700 (PDT)
To: Tore Anderson 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <563292BE.2090000@gmail.com>
Date: Fri, 30 Oct 2015 10:42:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151029203951.06a4d4fd@envy.fud.no>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 21:42:20 -0000

below...

On 30/10/2015 08:39, Tore Anderson wrote:
> * Brian E Carpenter
>=20
>> So Tore is slightly wrong: if the M flag is set, the O flag contains
>> no information, whatever value it has. Don't even test it.
>>
>> If the M flag is clear, and the O flag is set, you can't get addresses=
=2E
>> You can get some things from DHCPv6, but you don't know what. Maybe
>> IA_PD is available, maybe not.
>>
>> If M=3DO=3D0, DHCPv6 is a waste of space.
>>
>> Or:
>>
>> if M=3D=3D1
>>   {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
>>    /*try to get IA_PD from DHCPv6 if you want*/;
>>    /*try to get other DHCPv6 options if you want*/;}
>>    else {/*get addresses using SLAAC*/;
>>         if O=3D=3D1
>>           {/*try to get IA_PD from DHCPv6 if you want*/;
>>            /*try to get other DHCPv6 options if you want*/;}}
>=20
> Hi Brian,
>=20
> I am in 100% agreement with you, but I have clearly failed to express
> this correctly. What I have been meaning to say is that IA_PD is
> considered part of the "other configuration" (a.k.a. "not addresses")
> class of DHCPv6 options whose availability can be explicitly signaled
> through O=3D1 *or* implicitly through M=3D1.
>=20
> So your pseudo-code above reads correct to me, and matches RFC 7084
> WPD-4 as well as the wording in section 4.2 of RFC 4861.
>=20
> My original point is that my reading of
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt suggests a
> different and incorrect interpretation of the flags, which implies the
> following new pseudo-code (removing IA_PD from your =C2=ABif O=3D=3D1 {=
}=C2=BB block):
>=20
> if M=3D=3D1
>   {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
>    /*try to get IA_PD from DHCPv6 if you want*/;
>    /*try to get other DHCPv6 options if you want*/;}
>    else {/*get addresses using SLAAC*/;
>         if O=3D=3D1
>           {/*try to get other DHCPv6 options if you want*/;}}
>=20
> That is, the draft suggests that the availability of IA_PD is tied to
> the value of the M flag exclusively, instead of the boolean expression
> (M OR O). I on the other hand believe (M OR O) is the correct
> interpretation. I think we're in agreement on this point?

Yes.

Somebody did mention that in practice, M=3D=3DO=3D=3D0 might actually mea=
n
"we run DHCPv6 but forgot to set the bits". But I don't know what to
do about that.

   Brian


From nobody Thu Oct 29 14:52:42 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651C21B3207 for ; Thu, 29 Oct 2015 14:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NjjSWE8_vdv for ; Thu, 29 Oct 2015 14:52:40 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3020B1B3205 for ; Thu, 29 Oct 2015 14:52:40 -0700 (PDT)
Received: by padhy1 with SMTP id hy1so46141050pad.0 for ; Thu, 29 Oct 2015 14:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=dEM2XiJEWzqtgPjVUxEj9YpFHklF+/oOFq5+buib6gU=; b=nXIxOXrZGdnMRwPqLCEYnx0a18C0wv2Havd3fWVJtwLS8lnMmypxXh8qZc/loLKPHF 2LEmsR4oQRrJv/KQVErke+WLeHkzA3zAMJG62fY730iA6w+9LDpj5cYRTLnWByETZdV4 MWAOzpf4KQCBkW1Hkh6amg2pjLaoTOsOVRNKNrgD8HF3F2isgC3e0E5t4mFHGHpBFSdi Cd3KxIlX0aW7kH2/rUrj+prJqYHSIovSFV2yMzCDjrao3E63HMUeHEp3UUnWRQrF94/9 DE40Lpc6gyffL09zc5bM3SVmIOa/K3+b/3k4Qp2HXPcr7pGjrXA9HF1j9ph8qtf9vyrl cMkg==
X-Received: by 10.67.30.74 with SMTP id kc10mr4277597pad.147.1446155559795; Thu, 29 Oct 2015 14:52:39 -0700 (PDT)
Received: from ?IPv6:2406:e007:704e:1:28cc:dc4c:9703:6781? ([2406:e007:704e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id tn2sm4150405pac.0.2015.10.29.14.52.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 14:52:38 -0700 (PDT)
To: "Templin, Fred L" , Tore Anderson 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5632952C.5030604@gmail.com>
Date: Fri, 30 Oct 2015 10:52:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 21:52:41 -0000

Fred,

On 30/10/2015 09:59, Templin, Fred L wrote:
> Hi, I won't disagree with Brian and Tore but on some IPv6 links waiting to
> receive an RA may be redundant and unnecessary before directly
> attempting DHCPv6 PD. On those links, DHCPv6 messaging alone may
> be all that is necessary, and no RS/RA is required.

How is an IPv6 stack fresh from the factory supposed to guess that?
Surely we don't want to add configuration knobs?

I think RA is a required feature. RFC 6434 says:

7.2.2.  Use of Router Advertisements in Managed Environments

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are expected to determine their default router information and on-
   link prefix information from received Router Advertisements.
...
12.2.  Neighbor Discovery for IPv6 - RFC 4861

   Sending Router Advertisements and processing Router Solicitations
   MUST be supported.

     Brian


From nobody Thu Oct 29 14:59:36 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391EE1B3224 for ; Thu, 29 Oct 2015 14:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-4zFofFLAwC for ; Thu, 29 Oct 2015 14:59:33 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0921B3223 for ; Thu, 29 Oct 2015 14:59:33 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0B5A5D788E; Thu, 29 Oct 2015 14:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=pdj3JgJ69N9mN0B0iBi9aWszh2U=; b= VRyj/i6flh2MADjq1+SwfxVIFDhe0Lj1NWNbpdwU6n1Gl4K2yvYSdGuixElxxt68 tTop6Swtx1/tGfxIcNA5W8hKjV6uwcK6e6btni1fIaaBX0Sd4PPDpBJgq4esTcbD iVE2W/5dv2q0KDX3G30f3EM8Cn2saBdmAsmsFlteS9w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=sR0pWNG/kKf50ZIyuVnrWnAilA UW74ww08WBLvV20WMEf3FCmhTidGcSLowL7LT3AnkFoDRMKyezYjGiPQJR4yC8h4 SXw9VUajItnvqgItdZf0Hq7ps2mvEf20N1rN+uPALZrpcqfxbPVsy4hQYeqI8V5u C1ulVXXYHOrda0CLw=
Received: from h.hanazo.no (122x216x24x202.ap122.ftth.ucom.ne.jp [122.216.24.202]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E17A9D788D; Thu, 29 Oct 2015 14:59:32 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 810C67F9E7C; Fri, 30 Oct 2015 06:59:28 +0900 (JST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A8A77BD1-8054-4D23-A469-D52960615CA1"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <5632952C.5030604@gmail.com>
Date: Fri, 30 Oct 2015 06:59:27 +0900
Message-Id: <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: Tore Anderson , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 21:59:35 -0000

--Apple-Mail=_A8A77BD1-8054-4D23-A469-D52960615CA1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Brian,

>> Hi, I won't disagree with Brian and Tore but on some IPv6 links waiting to
>> receive an RA may be redundant and unnecessary before directly
>> attempting DHCPv6 PD. On those links, DHCPv6 messaging alone may
>> be all that is necessary, and no RS/RA is required.
> 
> How is an IPv6 stack fresh from the factory supposed to guess that?
> Surely we don't want to add configuration knobs?
> 
> I think RA is a required feature. RFC 6434 says:
> 
> 7.2.2.  Use of Router Advertisements in Managed Environments
> 
>   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
>   are expected to determine their default router information and on-
>   link prefix information from received Router Advertisements.
> ...
> 12.2.  Neighbor Discovery for IPv6 - RFC 4861
> 
>   Sending Router Advertisements and processing Router Solicitations
>   MUST be supported.

in the general case:
it isn't required for router to router links.
nor is it required for DHCPv6 PD.

in the 7084 case:
we've tied the CE router's default routing to ND Router Discovery.

Best regards,
Ole

--Apple-Mail=_A8A77BD1-8054-4D23-A469-D52960615CA1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWMpbAAAoJEL7aWKiYQt92IwgP/2mO8ewDx2oq/bvFkCcaZNoD
6n2fYqqRBkTQmgtp+nLJZKpIqWZB9HvCsZiUrhR/pqLjCY7oWdT+W0M1j53wusNS
7KoyQ88z/XD+pYzd2HryL+4Hf5dJR9Hvus0uakn8LFEMegMCRxlJFqhx2yw+5ZHP
ClGjDOxayTT285VmCyEjYfufmo2YgpycNCTe3Ax8/zDq1gwy9U3vKE5lUmvm5QEF
1PPy3X2B485ptrNtRG+mOIqzQXFlbFHaSzidQtwln0DugfTZiBkmrog/GYdvPEae
tEk19fo2bVClU3nnHoiDnO4nBl0zogxmBAniUnS5nbSIZzBZR2rqZya7+QR75HO1
q7P6YRI/z1sp6KlUJtnhEqQgaosBuHmyy2JqtFGoGgdpw+5/xe3sDFPlxExVpQkD
WIvuHYExt6tT1KbNOnSys4/9KZQNhATqdTCqIH7hS/5ofoZwZokOl2ezHYoVQApo
KkGBxPPqIayBk75zSxJYYE9W+4DRTahKM+QYbeKzFt/RjJYdDVw/BkGp2I4ju+0K
Gg4dtJ5yvMmUbi4jKTcc6CJiLo8Zx6DUkiH6R5YDz18pz+yFVnOTRfuIXfMoaFC7
10JB6qWwSBUljI6s+0RffZwem4BZLj7o7I40Mb3ESlkANJQYJA9fcRV+8VOeKsBY
UT2Yj6gzR/lwODHeT8v6
=awCX
-----END PGP SIGNATURE-----

--Apple-Mail=_A8A77BD1-8054-4D23-A469-D52960615CA1--


From nobody Thu Oct 29 15:03:44 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516D1B323D for ; Thu, 29 Oct 2015 15:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjyeaxP2zwCZ for ; Thu, 29 Oct 2015 15:03:41 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A29B1B323A for ; Thu, 29 Oct 2015 15:03:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TM3f79010965; Thu, 29 Oct 2015 17:03:42 -0500
Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TM3XZ7010943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Oct 2015 17:03:34 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-412.sw.nos.boeing.com ([169.254.12.14]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 15:03:32 -0700
From: "Templin, Fred L" 
To: "otroan@employees.org" , Brian E Carpenter 
Thread-Topic: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREpWlfhRQDc9H8Umtd3rwf220Zw==
Date: Thu, 29 Oct 2015 22:03:31 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org>
In-Reply-To: <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , Tore Anderson , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 22:03:43 -0000

Hi Brian,

> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> Sent: Thursday, October 29, 2015 2:59 PM
> To: Brian E Carpenter
> Cc: Templin, Fred L; Tore Anderson; v6ops@ietf.org; =1B$B?@L@C#:H=1B(B
> Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-=
host-00.txt
>=20
> Brian,
>=20
> >> Hi, I won't disagree with Brian and Tore but on some IPv6 links waitin=
g to
> >> receive an RA may be redundant and unnecessary before directly
> >> attempting DHCPv6 PD. On those links, DHCPv6 messaging alone may
> >> be all that is necessary, and no RS/RA is required.
> >
> > How is an IPv6 stack fresh from the factory supposed to guess that?
> > Surely we don't want to add configuration knobs?
> >
> > I think RA is a required feature. RFC 6434 says:
> >
> > 7.2.2.  Use of Router Advertisements in Managed Environments
> >
> >   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> >   are expected to determine their default router information and on-
> >   link prefix information from received Router Advertisements.
> > ...
> > 12.2.  Neighbor Discovery for IPv6 - RFC 4861
> >
> >   Sending Router Advertisements and processing Router Solicitations
> >   MUST be supported.
>=20
> in the general case:
> it isn't required for router to router links.
> nor is it required for DHCPv6 PD.
>=20
> in the 7084 case:
> we've tied the CE router's default routing to ND Router Discovery.

The same as what Ole said. Also, an IPv6-over-(foo) document can specify th=
at
DHCPv6-only autoconfiguration is used on that link. In that way, IPv6 nodes
that connect to a (foo) link already known in advance what sorts of link
ND/DHCPv6 services they can expect.

Thanks - Fred
fred.l.templin@boeing.com

> Best regards,
> Ole


From nobody Thu Oct 29 15:09:44 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66811B3261 for ; Thu, 29 Oct 2015 15:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvPCBUfmIejE for ; Thu, 29 Oct 2015 15:09:42 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106791B3260 for ; Thu, 29 Oct 2015 15:09:41 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 960AAD788E; Thu, 29 Oct 2015 15:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=rbJszbPePKQbwv4pGOS8ijgD9lY=; b= BM1jEStaPOlC7kY2+gwTlLEewmoUDdpfVpPECIu2DK3pn0be7TBSlcRozZe0XkLB iByHZLiYhd1L9e03FeV/OJtNKKRl3It/gHuV0FbUvzZNHlHgYNLKep9iGH1WHLb8 Do0DtzHG4WxqKNKWCrqqkbyizlrA1m3Km8Uz97EeW3w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=peY2ZijV0QCdw7QIAFI1z4Gb+n dSy3HgfbnzwPAdVOvT76eo4vMkqdMEqNXCfNYXpb/Crbel8OUbXuQQPIX52qACeF 177QBCEdHcpIwK2l1ES6BXE6bCfc10c2dznipLbGoo5pjjxrMSd0utYqHXoUGCOY uigR1dt6mJqFDjdd0=
Received: from h.hanazo.no (122x216x24x202.ap122.ftth.ucom.ne.jp [122.216.24.202]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 384A5D788D; Thu, 29 Oct 2015 15:09:41 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B20967FA03B; Fri, 30 Oct 2015 07:09:39 +0900 (JST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_99A975B7-C58C-4F1C-A3C5-C13EC73AC24F"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <20151029203951.06a4d4fd@envy.fud.no>
Date: Fri, 30 Oct 2015 07:09:38 +0900
Message-Id: <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no>
To: Tore Anderson 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 22:09:43 -0000

--Apple-Mail=_99A975B7-C58C-4F1C-A3C5-C13EC73AC24F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I've changed subject.

> I am in 100% agreement with you, but I have clearly failed to express
> this correctly. What I have been meaning to say is that IA_PD is
> considered part of the "other configuration" (a.k.a. "not addresses")
> class of DHCPv6 options whose availability can be explicitly signaled
> through O=3D1 *or* implicitly through M=3D1.

that's incorrect.
7084 describes a specific deployment model where a router has an =
upstream interface acting both as a host and a router (in 4861 terms).
there are other deployment models of PD.
you can very well implement 7084 with DHCP and RA processing completely =
independent. i.e. ignoring the M/O flags. the implementation could use =
the M flag to determine to include IA_NA in that request or it might run =
two DHCP sessions.

> So your pseudo-code above reads correct to me, and matches RFC 7084
> WPD-4 as well as the wording in section 4.2 of RFC 4861.
>=20
> My original point is that my reading of
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt suggests a
> different and incorrect interpretation of the flags, which implies the
> following new pseudo-code (removing IA_PD from your =C2=ABif O=3D=3D1 =
{}=C2=BB block):
>=20
> if M=3D=3D1
>  {/*get addresses from DHCPv6 or SLAAC as you prefer*/;
>   /*try to get IA_PD from DHCPv6 if you want*/;
>   /*try to get other DHCPv6 options if you want*/;}
>   else {/*get addresses using SLAAC*/;
>        if O=3D=3D1
>          {/*try to get other DHCPv6 options if you want*/;}}
>=20
> That is, the draft suggests that the availability of IA_PD is tied to
> the value of the M flag exclusively, instead of the boolean expression
> (M OR O). I on the other hand believe (M OR O) is the correct
> interpretation. I think we're in agreement on this point?

PD is not tied to the M/O flags at all, apart from using them as an =
indication that DHCP service might be available on the link.

note that for a 7084 router PD is mandatory.

reading very much into the M/O flags is futile. as you will figure out =
if you read the thousands of messages on this subject in the 6man =
archive.

7084 pseudocode:
if A=3D1: do SLAAC

if M=3D1
 /* include IA_NA in request to DHCPv6 server /*
 /* include requests for other configuration options (not IA_*) /*
else if O=3D=3D1:
 /* include requests for other configurations options */

do DHCP PD (include other options as indicated above)

your pseudocode also had the bug of coupling DHCP and SLAAC address =
assignment.

Best regards,
Ole


--Apple-Mail=_99A975B7-C58C-4F1C-A3C5-C13EC73AC24F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWMpkjAAoJEL7aWKiYQt92cuAP/RMOwjsa3pHspwKUgeNf+EeV
gcO8WO1FXVdGY2knYIfnJNb2MQbRTqA7Q7mK8aJ3n44AuJrHYiK05nRJtkYQuc+I
YRQLbGQicoXOG11Yf9BluVVS4iy7nSO8dk500fB4DqZ3EzecLe95bpD9BgjklNKZ
DNngtzx1/sP5XTpFJKiI4MHodKz4Replk+Qh6ms+1y3A3ir2d8gCSmINya+2knG4
7kNKg5dT0Mbm3SXyEKpohcCC5I0UsJCgx7C3A2+HtgrS6WvGEKHeXx/Vjtrg7FaO
+mo2OI6vLjUooDMfkzbYT4pX5AXf9hwqi0eqsIT42c7so9+gMDLLoqJs9PGZ3cKp
1pzY156qthNzhDje/M40WtfTEgnFbM5RckBVanfA50lNLClpTiaL/1P2qfCOHESs
AGsw+JxouEwVEj+MZUJklJa/UFPngrtOOLDgNgJ+RK1wREeRrBcV8mQMhVheeWli
5SIjyRfad6ukvcRdfTzHodo267BaVCBsoJ7XP014UKla7ZX4J3BVpo5hoWYGXd1M
yUOTT74Q7mgHPYZtnjJfBSKOdLl2UXApouKBpFAnNcla/EUro9tROaZ5fBCC8GBf
xFGxJ7ktRL3unKaSYmQimS3qTezo2o6atFjbQKPB2MlHieCwcgY91G8SETFpPOU9
iAkCkTdHodRVRnNwuVML
=FbxO
-----END PGP SIGNATURE-----

--Apple-Mail=_99A975B7-C58C-4F1C-A3C5-C13EC73AC24F--


From nobody Thu Oct 29 15:43:26 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB081B3308 for ; Thu, 29 Oct 2015 15:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaVmF_P_kxwf for ; Thu, 29 Oct 2015 15:43:24 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0015C1B3307 for ; Thu, 29 Oct 2015 15:43:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TMhMNv053328; Thu, 29 Oct 2015 15:43:22 -0700
Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TMhGGi053093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 29 Oct 2015 15:43:17 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.139]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 15:43:16 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Thread-Topic: prefix delegation maintenance
Thread-Index: AdESmiZnsvYnpgYqToKdQ/Y16A41Hw==
Date: Thu, 29 Oct 2015 22:43:15 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F34040@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: [v6ops] prefix delegation maintenance
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 22:43:25 -0000

SGksIHRoZXJlIHNlZW1zIHRvIGJlIGEgbm90aW9uIHRoYXQgYW4gSVB2NiBwcmVmaXggY2FuIGJl
IGRlbGVnYXRlZCB2aWENCklQdjYgTkQgYnkgaGF2aW5nIHRoZSByb3V0ZXIgaW5jbHVkZSBQSU9z
IGluIFJBcyB0aGF0IGhhdmUgKEE9MTsgTD0wKQ0KaW5zdGVhZCBvZiB1c2luZyBESENQdjYgUEQu
IEJ1dCwgdGhlIHR3byBhcmUgbm90IHRoZSBzYW1lLg0KDQpBIHByb3Blcmx5IGRlbGVnYXRlZCBw
cmVmaXggaXMgb25lIHdoZXJlIHRoZSBuZXR3b3JrIGdyYW50cyBhIHByZWZpeCB0aGF0DQp0aGUg
cmVjaXBpZW50IG9idGFpbnMgZm9yIGl0cyBvd24gZXhjbHVzaXZlIHVzZSwgYW5kIHRoZSBuZXR3
b3JrIGVzdGFibGlzaGVzDQpyb3V0aW5nIHN0YXRlIHRoYXQgYXNzb2NpYXRlcyB0aGUgcHJlZml4
IHdpdGggdGhlIHJlY2lwaWVudC4gQnV0LCByZWNlaXZpbmcgdGhlDQpwcmVmaXggaXMgb25seSB0
aGUgaW5pdGlhbCBwaGFzZSBvZiBhbiBvbmdvaW5nIHJlbGF0aW9uc2hpcCB0aGUgcmVjaXBpZW50
IG11c3QNCmhhdmUgd2l0aCB0aGUgbmV0d29yay4NCg0KSW4gcGFydGljdWxhciwgdGhlIHJlY2lw
aWVudCBtdXN0IHRha2UgcGVyaW9kaWMgYW5kL29yIGV2ZW50LWRyaXZlbiAgYWN0aW9ucw0KdG8g
ZW5zdXJlIHRoYXQgdGhlIHByZWZpeCBkZWxlZ2F0aW9uIHJlbWFpbnMgYWxpdmUuIERIQ1B2NiBQ
RCBwcm92aWRlcw0KbWVzc2FnZXMgc3VjaCBhcyBSZW5ldyBhbmQgUmViaW5kIGZvciB0aGlzLiBU
aGUgcmVjaXBpZW50IG11c3QgYWxzbyB0ZWxsDQp0aGUgbmV0d29yayB3aGVuIHRoZSBwcmVmaXgg
aXMgbm8gbG9uZ2VyIG5lZWRlZCwgYW5kIERIQ1B2NiBQRCBoYXMgYQ0KUmVsZWFzZSBtZXNzYWdl
IGZvciB0aGlzLiBUaGUgcmVjaXBpZW50IGlzIGZ1cnRoZXIgcmVzcG9uc2libGUgZm9yIHJlbGlh
YmlsaXR5DQphbmQgbXVzdCByZXRyYW5zbWl0IGlmIHRoZSBuZXR3b3JrIGRvZXMgbm90IHJlc3Bv
bmQgdG8gaW5pdGlhbCBtZXNzYWdlcywNCnNvIHRoZSByZWNpcGllbnQgYWN0cyBvbiBpdHMgb3du
IGJlaGFsZiB0byBtYWtlIHN1cmUgdGhlIHByZWZpeCBkZWxlZ2F0aW9uDQpwZXJzaXN0cy4gSSBk
b24ndCBzZWUgYW55IG9mIHRoZXNlIGZhY2lsaXRpZXMgc3BlY2lmaWVkIGZvciBJUHY2IE5ELg0K
DQpTbywgSSB3b3VsZCByYXRoZXIgc2VlIHVzIHVzZSB0aGUgdG9vbCB0aGF0IHdhcyBtZWFudCBm
b3IgdGhlIGpvYiByYXRoZXINCnRoYW4gcmVpbnZlbnQgdGhlIHdoZWVsLg0KDQpUaGFua3MgLSBG
cmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo=


From nobody Thu Oct 29 15:45:00 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3D1B330E for ; Thu, 29 Oct 2015 15:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2GEtuuyvpYf for ; Thu, 29 Oct 2015 15:44:58 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5C11B330D for ; Thu, 29 Oct 2015 15:44:58 -0700 (PDT)
Received: by pasz6 with SMTP id z6so53171704pas.2 for ; Thu, 29 Oct 2015 15:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=J/54nakUUSxKBYYnNq2FruraQnI6od7Y+LBcAueeAfE=; b=qlQh0GNBd31TBpNE6/jz/77MWsiH6bAkc3T9H08WUaHxmOBQSb9fGbg1ahnehbrN3T Af8CT5iTCg9j99eEX75k8BiawduTSTGZH8x+142i+dYo9+ZKVofUONnucodj3+k0KyK/ yRJnYORkKEYXWc61eqXz/yYCUQ1O2/V1037zXQPqzzCyDtRz/2krDLkiv9O+Izn8fXkQ Rjn5c8rveGLsluiSqp+MNhfpbcGKMHD2T01a1p6PCj5d/q6Cqnrb9myF1UFxSc1++rc/ 0Vfyr5CVnkENnhFGr259uQOa7Np2YFCBOm+n97IBx7SwYP2WPFFzZ3FmFKgwhCXecZHC 7eUA==
X-Received: by 10.68.178.1 with SMTP id cu1mr4600282pbc.99.1446158697806; Thu, 29 Oct 2015 15:44:57 -0700 (PDT)
Received: from ?IPv6:2406:e007:704e:1:28cc:dc4c:9703:6781? ([2406:e007:704e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id by6sm4223085pab.25.2015.10.29.15.44.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 15:44:56 -0700 (PDT)
To: "Templin, Fred L" , "otroan@employees.org" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org> <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5632A16C.50809@gmail.com>
Date: Fri, 30 Oct 2015 11:45:00 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , Tore Anderson , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 22:44:59 -0000

Ole, Fred,

On 30/10/2015 11:03, Templin, Fred L wrote:
> Hi Brian,
>=20
>> -----Original Message-----
>> From: otroan@employees.org [mailto:otroan@employees.org]
>> Sent: Thursday, October 29, 2015 2:59 PM
>> To: Brian E Carpenter
>> Cc: Templin, Fred L; Tore Anderson; v6ops@ietf.org; =E7=A5=9E=E6=98=8E=
=E9=81=94=E5=93=89
>> Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-p=
er-host-00.txt
>>
>> Brian,
>>
>>>> Hi, I won't disagree with Brian and Tore but on some IPv6 links wait=
ing to
>>>> receive an RA may be redundant and unnecessary before directly
>>>> attempting DHCPv6 PD. On those links, DHCPv6 messaging alone may
>>>> be all that is necessary, and no RS/RA is required.
>>>
>>> How is an IPv6 stack fresh from the factory supposed to guess that?
>>> Surely we don't want to add configuration knobs?
>>>
>>> I think RA is a required feature. RFC 6434 says:
>>>
>>> 7.2.2.  Use of Router Advertisements in Managed Environments
>>>
>>>   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv=
6)
>>>   are expected to determine their default router information and on-
>>>   link prefix information from received Router Advertisements.
>>> ...
>>> 12.2.  Neighbor Discovery for IPv6 - RFC 4861
>>>
>>>   Sending Router Advertisements and processing Router Solicitations
>>>   MUST be supported.
>>
>> in the general case:
>> it isn't required for router to router links.

That may be so in practice, but is it actually documented that way?
(I agree that it makes sense.)

>> nor is it required for DHCPv6 PD.

I don't see any wiggle room in the section 12.2 quote above. But anyway,
the only practical interpretation of that is "if you think you might
like to get an IA_PD, then try DHCPv6 regardless of RA."

>>
>> in the 7084 case:
>> we've tied the CE router's default routing to ND Router Discovery.

Right... which is a safe choice, because it's consistent with RFC 6434.

>=20
> The same as what Ole said. Also, an IPv6-over-(foo) document can specif=
y that
> DHCPv6-only autoconfiguration is used on that link.=20

Really? RFC 4861 does allow exceptions, but mainly in terms of NBMA
links. Also, DHCPv6 is only a SHOULD in node requirements.

> In that way, IPv6 nodes
> that connect to a (foo) link already known in advance what sorts of lin=
k
> ND/DHCPv6 services they can expect.

Well, the IPv6-over-foo modules can know in advance. But host stacks as a=
 whole
need to figure this out dynamically, I think. Again, I am assuming that w=
e want
to get avoid configuration knobs.

Regards
   Brian


From nobody Thu Oct 29 15:53:16 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F691A0104 for ; Thu, 29 Oct 2015 15:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvWdYNJG6qxO for ; Thu, 29 Oct 2015 15:53:12 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413D21A00F3 for ; Thu, 29 Oct 2015 15:53:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9TMrBC7004745; Thu, 29 Oct 2015 15:53:11 -0700
Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9TMr7kr004544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Oct 2015 15:53:07 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.50]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 15:53:06 -0700
From: "Templin, Fred L" 
To: Brian E Carpenter , "otroan@employees.org" 
Thread-Topic: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREpWlfhRQDc9H8Umtd3rwf220Z56Dhw8A//+LE2A=
Date: Thu, 29 Oct 2015 22:53:06 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F34073@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org> <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com> <5632A16C.50809@gmail.com>
In-Reply-To: <5632A16C.50809@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , Tore Anderson , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Oct 2015 22:53:14 -0000

SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g
RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6
IFRodXJzZGF5LCBPY3RvYmVyIDI5LCAyMDE1IDM6NDUgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQg
TDsgb3Ryb2FuQGVtcGxveWVlcy5vcmcNCj4gQ2M6IFRvcmUgQW5kZXJzb247IHY2b3BzQGlldGYu
b3JnOyDnpZ7mmI7pgZTlk4kNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJh
ZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQo+IA0KPiBP
bGUsIEZyZWQsDQo+IA0KPiBPbiAzMC8xMC8yMDE1IDExOjAzLCBUZW1wbGluLCBGcmVkIEwgd3Jv
dGU6DQo+ID4gSGkgQnJpYW4sDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPj4gRnJvbTogb3Ryb2FuQGVtcGxveWVlcy5vcmcgW21haWx0bzpvdHJvYW5AZW1wbG95ZWVz
Lm9yZ10NCj4gPj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjksIDIwMTUgMjo1OSBQTQ0KPiA+
PiBUbzogQnJpYW4gRSBDYXJwZW50ZXINCj4gPj4gQ2M6IFRlbXBsaW4sIEZyZWQgTDsgVG9yZSBB
bmRlcnNvbjsgdjZvcHNAaWV0Zi5vcmc7IOelnuaYjumBlOWTiQ0KPiA+PiBTdWJqZWN0OiBSZTog
W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w
ZXItaG9zdC0wMC50eHQNCj4gPj4NCj4gPj4gQnJpYW4sDQo+ID4+DQo+ID4+Pj4gSGksIEkgd29u
J3QgZGlzYWdyZWUgd2l0aCBCcmlhbiBhbmQgVG9yZSBidXQgb24gc29tZSBJUHY2IGxpbmtzIHdh
aXRpbmcgdG8NCj4gPj4+PiByZWNlaXZlIGFuIFJBIG1heSBiZSByZWR1bmRhbnQgYW5kIHVubmVj
ZXNzYXJ5IGJlZm9yZSBkaXJlY3RseQ0KPiA+Pj4+IGF0dGVtcHRpbmcgREhDUHY2IFBELiBPbiB0
aG9zZSBsaW5rcywgREhDUHY2IG1lc3NhZ2luZyBhbG9uZSBtYXkNCj4gPj4+PiBiZSBhbGwgdGhh
dCBpcyBuZWNlc3NhcnksIGFuZCBubyBSUy9SQSBpcyByZXF1aXJlZC4NCj4gPj4+DQo+ID4+PiBI
b3cgaXMgYW4gSVB2NiBzdGFjayBmcmVzaCBmcm9tIHRoZSBmYWN0b3J5IHN1cHBvc2VkIHRvIGd1
ZXNzIHRoYXQ/DQo+ID4+PiBTdXJlbHkgd2UgZG9uJ3Qgd2FudCB0byBhZGQgY29uZmlndXJhdGlv
biBrbm9icz8NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIFJBIGlzIGEgcmVxdWlyZWQgZmVhdHVyZS4g
UkZDIDY0MzQgc2F5czoNCj4gPj4+DQo+ID4+PiA3LjIuMi4gIFVzZSBvZiBSb3V0ZXIgQWR2ZXJ0
aXNlbWVudHMgaW4gTWFuYWdlZCBFbnZpcm9ubWVudHMNCj4gPj4+DQo+ID4+PiAgIE5vZGVzIHVz
aW5nIHRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhD
UHY2KQ0KPiA+Pj4gICBhcmUgZXhwZWN0ZWQgdG8gZGV0ZXJtaW5lIHRoZWlyIGRlZmF1bHQgcm91
dGVyIGluZm9ybWF0aW9uIGFuZCBvbi0NCj4gPj4+ICAgbGluayBwcmVmaXggaW5mb3JtYXRpb24g
ZnJvbSByZWNlaXZlZCBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMuDQo+ID4+PiAuLi4NCj4gPj4+IDEy
LjIuICBOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQdjYgLSBSRkMgNDg2MQ0KPiA+Pj4NCj4gPj4+
ICAgU2VuZGluZyBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMgYW5kIHByb2Nlc3NpbmcgUm91dGVyIFNv
bGljaXRhdGlvbnMNCj4gPj4+ICAgTVVTVCBiZSBzdXBwb3J0ZWQuDQo+ID4+DQo+ID4+IGluIHRo
ZSBnZW5lcmFsIGNhc2U6DQo+ID4+IGl0IGlzbid0IHJlcXVpcmVkIGZvciByb3V0ZXIgdG8gcm91
dGVyIGxpbmtzLg0KPiANCj4gVGhhdCBtYXkgYmUgc28gaW4gcHJhY3RpY2UsIGJ1dCBpcyBpdCBh
Y3R1YWxseSBkb2N1bWVudGVkIHRoYXQgd2F5Pw0KPiAoSSBhZ3JlZSB0aGF0IGl0IG1ha2VzIHNl
bnNlLikNCj4gDQo+ID4+IG5vciBpcyBpdCByZXF1aXJlZCBmb3IgREhDUHY2IFBELg0KPiANCj4g
SSBkb24ndCBzZWUgYW55IHdpZ2dsZSByb29tIGluIHRoZSBzZWN0aW9uIDEyLjIgcXVvdGUgYWJv
dmUuIEJ1dCBhbnl3YXksDQo+IHRoZSBvbmx5IHByYWN0aWNhbCBpbnRlcnByZXRhdGlvbiBvZiB0
aGF0IGlzICJpZiB5b3UgdGhpbmsgeW91IG1pZ2h0DQo+IGxpa2UgdG8gZ2V0IGFuIElBX1BELCB0
aGVuIHRyeSBESENQdjYgcmVnYXJkbGVzcyBvZiBSQS4iDQo+IA0KPiA+Pg0KPiA+PiBpbiB0aGUg
NzA4NCBjYXNlOg0KPiA+PiB3ZSd2ZSB0aWVkIHRoZSBDRSByb3V0ZXIncyBkZWZhdWx0IHJvdXRp
bmcgdG8gTkQgUm91dGVyIERpc2NvdmVyeS4NCj4gDQo+IFJpZ2h0Li4uIHdoaWNoIGlzIGEgc2Fm
ZSBjaG9pY2UsIGJlY2F1c2UgaXQncyBjb25zaXN0ZW50IHdpdGggUkZDIDY0MzQuDQo+IA0KPiA+
DQo+ID4gVGhlIHNhbWUgYXMgd2hhdCBPbGUgc2FpZC4gQWxzbywgYW4gSVB2Ni1vdmVyLShmb28p
IGRvY3VtZW50IGNhbiBzcGVjaWZ5IHRoYXQNCj4gPiBESENQdjYtb25seSBhdXRvY29uZmlndXJh
dGlvbiBpcyB1c2VkIG9uIHRoYXQgbGluay4NCj4gDQo+IFJlYWxseT8gUkZDIDQ4NjEgZG9lcyBh
bGxvdyBleGNlcHRpb25zLCBidXQgbWFpbmx5IGluIHRlcm1zIG9mIE5CTUENCj4gbGlua3MuDQoN
ClllcywgSSBzaG91bGQgaGF2ZSBzYWlkIE5CTUEuIFRoYXQgaXMgd2hhdCBJIG1lYW50Lg0KDQo+
IEFsc28sIERIQ1B2NiBpcyBvbmx5IGEgU0hPVUxEIGluIG5vZGUgcmVxdWlyZW1lbnRzLg0KDQpU
aGF0IGlzIGZvciBJUHY2IG5vZGUgcmVxdWlyZW1lbnRzLCB5ZXMuIFJlcXVpcmVtZW50cyBmb3Ig
bm9kZXMgdGhhdA0KY29ubmVjdCB0byBhIHNwZWNpZmljIGxpbmsgdHlwZSBjYW4gY2hhbmdlIHRo
ZSBTSE9VTEQgdG8gYSBNVVNULg0KDQo+ID4gSW4gdGhhdCB3YXksIElQdjYgbm9kZXMNCj4gPiB0
aGF0IGNvbm5lY3QgdG8gYSAoZm9vKSBsaW5rIGFscmVhZHkga25vd24gaW4gYWR2YW5jZSB3aGF0
IHNvcnRzIG9mIGxpbmsNCj4gPiBORC9ESENQdjYgc2VydmljZXMgdGhleSBjYW4gZXhwZWN0Lg0K
PiANCj4gV2VsbCwgdGhlIElQdjYtb3Zlci1mb28gbW9kdWxlcyBjYW4ga25vdyBpbiBhZHZhbmNl
LiBCdXQgaG9zdCBzdGFja3MgYXMgYSB3aG9sZQ0KPiBuZWVkIHRvIGZpZ3VyZSB0aGlzIG91dCBk
eW5hbWljYWxseSwgSSB0aGluay4gQWdhaW4sIEkgYW0gYXNzdW1pbmcgdGhhdCB3ZSB3YW50DQo+
IHRvIGdldCBhdm9pZCBjb25maWd1cmF0aW9uIGtub2JzLg0KDQpBIG5vZGUgY29ubmVjdGluZyB0
byBhIGxpbmsgdHlwZSB0aGF0IGhhcyBESENQdjYgYXMgYSBNVVNUIHdpbGwgbmF0dXJhbGx5DQpk
byBESENQdjYsIHllcy4NCg0KUGxlYXNlIG5vdGUgdGhhdCBJIGFtIG5vdCBzYXlpbmcgIkRIQ1B2
Ni1vbmx5Ii4gSVB2NiBORCBmdW5jdGlvbnMgc3VjaA0KYXMgUmVkaXJlY3QgYW5kIE5VRCBtYXkg
c3RpbGwgYmUgbmVlZGVkLCBhbmQgaWYgdGhlIG5vZGUgc2VuZHMgYW4gUlMNCml0IHNob3VsZCBw
cm9iYWJseSBleHBlY3QgdG8gcmVjZWl2ZSBhbiBSQSBpbiByZXBseSAodW5pY2FzdCkuDQoNClRo
YW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBSZWdhcmRzDQo+ICAg
IEJyaWFuDQoNCg==


From nobody Thu Oct 29 18:01:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8BE1B2A5D for ; Thu, 29 Oct 2015 18:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmyV5STGPntT for ; Thu, 29 Oct 2015 18:01:42 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A7D1B2A5C for ; Thu, 29 Oct 2015 18:01:42 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 80625D7882; Thu, 29 Oct 2015 18:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=FWqX/DWeZggfQGhUfswrJgRXE9A=; b= drXZptFdSXIybU8HdWRQnTdRfLf8yNpBkU5XPrHeNpMHE0TcnKsBbEg1z7MpRCWo wXhMyYjIu6C3ng4GTvzdyN2+LE1amjOYijJKRjwqZ5DVMiWM+45lakTwFt0MyIRY hDQSNGROTHNvETfNxJGcvbvJVJzDHjz4983m04x723U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=DAe/Ifk+g7kZd31USKgRWf/mWe uZGBwxPOOHE83917UjJuxZcV7iSomDGMLiHwNYByKqYyR04+HPfC0vuDExBwny0E o2h59lgMtO3wB166nTtCtoz9OY265xjO82bx5oA4H4VD4F2u2Az/Y7opQiLV24cK qPY9aiaeMxwt9+VZ0=
Received: from h.hanazo.no (unknown [103.5.140.162]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 632C7D7884; Thu, 29 Oct 2015 18:01:41 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A2DF57FC61B; Fri, 30 Oct 2015 10:01:39 +0900 (JST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3014239D-2179-4378-BFDB-91D2D7EAE5ED"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <5632A16C.50809@gmail.com>
Date: Fri, 30 Oct 2015 10:01:38 +0900
Message-Id: 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org> <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com> <5632A16C.50809@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: Tore Anderson , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 01:01:44 -0000

--Apple-Mail=_3014239D-2179-4378-BFDB-91D2D7EAE5ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

[off topic warning]

>>> in the 7084 case:
>>> we've tied the CE router's default routing to ND Router Discovery.
>=20
> Right... which is a safe choice, because it's consistent with RFC =
6434.

well, the choice isn't all that obvious. implementations/deployments do =
also vary.
the most obvious choice is a routing protocol.

cheers,
Ole

--Apple-Mail=_3014239D-2179-4378-BFDB-91D2D7EAE5ED
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWMsFzAAoJEL7aWKiYQt92pD8P/R+1xynJau8SAvYh7RAXQ7Ah
M6oXpw1ijOFXvSXph8N6s9zMNNYqUeVbGTJHVL76N1nsiqRF4CD0NMxkysQbPTKe
1qStjdFf3wMzuE8qhtVcwttj2vYy/fl/FDh34742sK5CowiU1EKTNMSIL3XuBqs9
hPK+UtimmnTZFxTsdtYndZZHvjyBT2BzvNx6QM7jSTwJGxaROXbSdExMwVTVpS5R
e8+26nS5gsD7J47a1D3w7DNToUZFlgsmpLg/wveGoPSyTUG6bz21NlWUabFx0Go6
38WvypEsxSuOWbA6IDoIXiXAWdgz7zXI8JEC39xDVSgfLZHvILyP3Gsb4vTSKXYb
7enUSHideZFSbeaBpZozqGNK3m1loQtJxAIsiywNbvf6LSlNYl0kMIdMizgTU0H/
xmwNj+KYbwCiwCxfRYuy3ddVJAXCQpBzVmjdVw2odtnB7skOTyMbvuUfZwVdAGRi
FPsKT+n8yS7dv+L31nxp6CKrKchbbJY85eMIMDnHRuNh4/d2GN6YMzyQCNnerJyz
d7QsLWE2Mcd9EK93GkVmXH+8E/0o7LDh0F3X/Bi2KOxM8GIGGGXbA0ap1SOqw4vx
eFxFD+2cVRFy+hOHFwBPItvwNiizKZU344goj7TlwGREnsNnHIBwuSov6udDyofI
hidvW2FMDcXAAvOldyHY
=ztKw
-----END PGP SIGNATURE-----

--Apple-Mail=_3014239D-2179-4378-BFDB-91D2D7EAE5ED--


From nobody Thu Oct 29 19:12:54 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ED51B3480 for ; Thu, 29 Oct 2015 19:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn-q3nju_GYN for ; Thu, 29 Oct 2015 19:12:50 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3681B347E for ; Thu, 29 Oct 2015 19:12:50 -0700 (PDT)
Received: by vkfw189 with SMTP id w189so39131002vkf.2 for ; Thu, 29 Oct 2015 19:12:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=swSYanMD3LS2u9yapDn4TPBuzs1nPNHzKNmzgZgJUpk=; b=nRkwbX6OYkGOLt2PJS751G/xvVoe8sG9C78kKZ+VIh/Gjyc6JS6W68EOdglXhWL/qP O0qkGC/9LP4tx6fKsnuD72kYbI0cBhMxz5sD9CsGm4yBQpE4HdyM7+AXXwRPnT+OaKM4 z1UFaaFc7YmLB3SAsn1HF1SUXPqd4mTo3Zu9f6xipVw6ieQmzGgXFvuQ8nKrd8zfwrWh +XqC5rlwz71HvyI+NgX+44Ff7odpAeI2vpVIF0aD5zXj6PMVI5KEvGwGar5WAu3mkwsR SDWl7FN2a3vwJ8HyfG6BIOXHyTGYFvwNS+vm1USiOv3vZgh6K0imavyPHTEdrBP9oN0q PXuA==
X-Received: by 10.31.33.75 with SMTP id h72mr3776129vkh.144.1446171169534; Thu, 29 Oct 2015 19:12:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.67.194 with HTTP; Thu, 29 Oct 2015 19:12:19 -0700 (PDT)
In-Reply-To: <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org> <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com>
From: Mark Smith 
Date: Fri, 30 Oct 2015 13:12:19 +1100
Message-ID: 
To: "Templin, Fred L" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Tore Anderson , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 02:12:52 -0000

Hi Fred,

On 30 October 2015 at 09:03, Templin, Fred L  wrote:
> Hi Brian,
>
>> -----Original Message-----

>
> The same as what Ole said. Also, an IPv6-over-(foo) document can specify that
> DHCPv6-only autoconfiguration is used on that link.

Do any exist that state that?

I'd hope in that case the IPv6-over-(foo) document mentions that if a
stateful DHCPv6 server is not available, the hosts are only left with
link-local addresses to use for all IPv6 operations and applications.


Regards,
Mark.


> In that way, IPv6 nodes
> that connect to a (foo) link already known in advance what sorts of link
> ND/DHCPv6 services they can expect.
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> Best regards,
>> Ole
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Oct 29 21:51:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204281B3720 for ; Thu, 29 Oct 2015 21:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level: 
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX5xIV16QyPW for ; Thu, 29 Oct 2015 21:51:42 -0700 (PDT)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EA81B371F for ; Thu, 29 Oct 2015 21:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1446180702; x=2310094302; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9T+cQCB2086pgwhqIhiLBZ2FTlyn23+9x0b5x8G/ym4=; b=NT1KcnAcpinbx6PM0nrJBSXmIPPYUtCbfrWqcX7UAoKupCcnsTKc7UnSRBclAMj/ pXYDen0x/u5TRTYFyY81XGHIdNaC1k3xYaPmg7ks3LCARsQB+kGVPqxYnRxcZjmb nE0d3cwHZaDLc9bxvpU0mR0QRbJWzeSBRT/snvftwTGyt8DTtry+xyA9iarG/csA ahERsmUj0mKkglxfZTr6cgAfjKHEnQUROUqn4+54VF4a958lioUddkqyXD3qsLtz 7S+2LGioMhNybGH9vDbUhWUAi0bw8ndWGpSXobQTO7SGZLtgh78ItI0Z1bH74Opo uuqPBMjI6HpanxKoDIpsKw==;
Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 35.FA.12069.E57F2365; Thu, 29 Oct 2015 21:51:42 -0700 (PDT)
X-AuditID: 11973e12-f79c06d000002f25-fc-5632f75e87d4
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 70.FA.29028.D57F2365; Thu, 29 Oct 2015 21:51:42 -0700 (PDT)
Received: from [17.153.16.142] by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NX000IRFO64PU00@kencur.apple.com> for v6ops@ietf.org; Thu, 29 Oct 2015 21:51:41 -0700 (PDT)
Sender: dschinazi@apple.com
From: David Schinazi 
Content-type: multipart/alternative; boundary="Apple-Mail=_0DECF4E9-B6FF-4287-9D66-A966260B7BC5"
Message-id: 
Date: Thu, 29 Oct 2015 21:51:44 -0700
To: v6ops@ietf.org
MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCYphv33SjM4Nc8ZovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+30ZvaCJs2Ktfv62BsYryt3MXJySAiYSDROWc4EYYtJXLi3 nq2LkYtDSGAfo0Tn32ZGmKK9mz+zQCTamSROvz3BDuF8YZQ4M/URG0iVsIC0RNeFu6xdjBwc bAJaEgfWGIGEmQWSJJ5tvsoOUWIpsf3kD7ByXgEbiTmPtjGD2CwCqhLtS+eBxUUEhCR2PGti gqgxkPh/tZEd4gh5iZ8rG5hA9koITGCT+P7lLMsERoFZSHbMQtIDEdeWWLbwNTOErSmxv3s5 C6a4hkTnt4msCxjZVjEK5SZm5uhm5pnoJRYU5KTqJefnbmIEBfJ0O6EdjKdWWR1iFOBgVOLh /ZFgFCbEmlhWXJl7iFGag0VJnHftfqCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxpTtTy4U XrSKKy7bcvZR4IHfLmJFiwzXlO1xORm1Rckp8Nu89f7TjdZc79zdq2Y40eVRRdrpTmNL4+n/ FJv2cHvscZxeFmklJx5lJuLJ7Okp/Ijr3Nrdcq1dvxZ3Pf1bNEtZ+ZOx1c57x/TcsgOrw087 JK5LnnJ89d+jYh/Edv2/dJGzcq/0VSWW4oxEQy3mouJEAC620kRFAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUiON1OTTfuu1GYwQ85i9PH9jI7MHosWfKT KYAxissmJTUnsyy1SN8ugStj7fRm9oImzYq1+/rYGxivK3cxcnJICJhI7N38mQXCFpO4cG89 WxcjF4eQQDuTxOm3J9ghnC+MEmemPmIDqRIWkJbounCXtYuRg4NNQEviwBojkDCzQJLEs81X 2SFKLCW2n/wBVs4rYCMx59E2ZhCbRUBVon3pPLC4iICQxI5nTUwQNQYS/682skMcIS/xc2UD 0wRG3llIxs5CUgYR15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMQoUpeYkVlroJRYU5KTq JefnbmIEhV1DYdoOxqblVocYBTgYlXh4A5KNwoRYE8uKK3MPMUpwMCuJ8P6+BBTiTUmsrEot yo8vKs1JLT7EOJER6JuJzFKiyfnAqMgriTc0MTEwMTY2MzY2NzGnpbCSOG8cq2GYkEB6Yklq dmpqQWoRzFFMHJxSDYw97S8Nax/+Wz9brGXn7y9Hr8RI8jhudPMXT5YJuWIUHPRCtMXHzolN esoLvzeLdv5cXaOZKlW4xswo2Tp07TFZV/E9qpEf3Oa/e9131+LK7hez2d+/NT69zMTGqepB 6c7ff7pfVvk7985g6RF+trV1hYiAx3Q73XBlp+spl+Y8jMthu24xp1aJpTgj0VCLuag4EQB7 4KRFrgIAAA==
Archived-At: 
Subject: [v6ops] Apple and IPv6 - new NAT64 address synthesis API
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 04:51:44 -0000

--Apple-Mail=_0DECF4E9-B6FF-4287-9D66-A966260B7BC5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi everyone,

This week Apple released the first betas of iOS 9.2 and OS X 10.11.2.
With it, we=E2=80=99ve introduced a new API to allow developers to =
synthesize NAT64 IPv6 addresses from IPv4 literals.
We=E2=80=99re hoping that this will help more applications support NAT64 =
networks correctly while they work on getting server support for IPv6.
As usual, we=E2=80=99d love feedback from the IETF community.

The API is very simple: we ask developers to always ``resolve'=E2=80=99 =
their IPv4 literals using getaddrinfo() by treating their IPv4 literal =
as a hostname string (e.g. ``192.0.2.1''), and we will take care of =
returning an IPv4 sockaddr on IPv4 networks and an appropriately =
synthesized NAT64 IPv6 sockaddr when the network supports IPv6, NAT64 =
and DNS64 but not IPv4. This is accomplished using RFC 6052 and RFC =
7050.

Our target audience is application developers that need to communicate =
to an IPv4-only host for which they do not have a hostname. An example =
is a P2P service transmitting IPv4 literals over the wire. We do agree =
that the correct long-term solution is IPv6 support for all hosts and =
protocols but this is an effort to ease the transition. We believe this =
will help fix any remaining apps that do not support IPv6 before we =
start rejecting them from the App Store in early 2016.

More details and a code sample can be found on the Apple documentation =
website:

=
https://developer.apple.com/library/prerelease/tvos/documentation/Networki=
ngInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingforth=
eIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple=
_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4 =


Thanks,
David Schinazi
Apple CoreOS Networking Engineer=

--Apple-Mail=_0DECF4E9-B6FF-4287-9D66-A966260B7BC5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi everyone,

This week Apple released the first =
betas of iOS 9.2 and OS X 10.11.2.
With it, we=E2=80=99=
ve introduced a new API to allow developers to synthesize NAT64 IPv6 =
addresses from IPv4 literals.
We=E2=80=99re hoping =
that this will help more applications support NAT64 networks correctly =
while they work on getting server support for IPv6.
As usual, we=E2=80=99d love feedback from the IETF =
community.

The =
API is very simple: we ask developers to always ``resolve'=E2=80=99 =
their IPv4 literals using getaddrinfo() by treating their IPv4 literal =
as a hostname string (e.g. ``192.0.2.1''), and we will take care of =
returning an IPv4 sockaddr on IPv4 networks and an appropriately =
synthesized NAT64 IPv6 sockaddr when the network supports IPv6, NAT64 =
and DNS64 but not IPv4. This is accomplished using RFC 6052 and RFC =
7050.

Our =
target audience is application developers that need to communicate to an =
IPv4-only host for which they do not have a hostname. An example is a =
P2P service transmitting IPv4 literals over the wire. We do agree that =
the correct long-term solution is IPv6 support for all hosts and =
protocols but this is an effort to ease the transition. We believe this =
will help fix any remaining apps that do not support IPv6 before we =
start rejecting them from the App Store in early 2016.

More details and a code =
sample can be found on the Apple documentation website:

https://developer.apple.com/library/prerelease/tvos/documentati=
on/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPre=
paringfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.h=
tml#//apple_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4

Thanks,
David Schinazi
Apple CoreOS Networking =
Engineer
=

--Apple-Mail=_0DECF4E9-B6FF-4287-9D66-A966260B7BC5--


From nobody Thu Oct 29 23:58:59 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5D1A6F5A for ; Thu, 29 Oct 2015 23:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eneGxJ0DIXMB for ; Thu, 29 Oct 2015 23:58:56 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F741B37EB for ; Thu, 29 Oct 2015 23:58:55 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=44726 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zs3eD-0001jx-Q0; Fri, 30 Oct 2015 07:58:49 +0100
Date: Fri, 30 Oct 2015 07:58:49 +0100
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com>
In-Reply-To: <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 06:58:58 -0000

Hi Ole,

* otroan@employees.org

> I've changed subject.
>=20
> > I am in 100% agreement with you, but I have clearly failed to express
> > this correctly. What I have been meaning to say is that IA_PD is
> > considered part of the "other configuration" (a.k.a. "not addresses")
> > class of DHCPv6 options whose availability can be explicitly signaled
> > through O=3D1 *or* implicitly through M=3D1.
>=20
> that's incorrect.

I hear you say that, but I am struggling to find any reference in any
standard that supports this view. Mailing list posts doesn't really
count here, even if they number in the thousands. I'm interested in
learning which section of which RFC is telling me I'm incorrect. Give
me a pointer to that and I'll shut up.

We can even disregard RFC 7084, as it's not a standard. RFC 4861
Section 4.2 is where the flags and their meaning is specified. It says,
and I quote:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

So DHCPv6-provided configuration is divided into two categories:

1) addresses
2) other

The availability of both of these categories of configuration is
signalled through the M/O flags. Nowhere that I can find is a third
=C2=ABother than "other"=C2=BB category of DHCPv6-provided configuration de=
fined
or even hinted at.

So to me, the only logical interpretation of the above, is that the
availability of every single DHCPv6 option - including IA_PD - is
signalled through the O/M flags.

What RFC 4861 goes on to say makes me even more certain of this
interpretation:

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

> 7084 pseudocode:
> if A=3D1: do SLAAC
>=20
> if M=3D1
>  /* include IA_NA in request to DHCPv6 server /*
>  /* include requests for other configuration options (not IA_*) /*
> else if O=3D=3D1:
>  /* include requests for other configurations options */
>=20
> do DHCP PD (include other options as indicated above)

Your pseudocode seems to confirm that you consider the IA_PD to be in
this third apparently-not-specified-anywhere =C2=ABother than "other"=C2=BB
category of DHCPv6-provided configuration.

It also appears to ignore the =C2=ABIf neither M nor O flags are set, this
indicates that no information is available via DHCPv6=C2=BB statement. (But
I would agree that ignoring this "indication" is not forbidden.)

And finally it does not faithfully represent RFC 7084. Your code will
unconditionally request IA_PD in the O=3DM=3D0 case, while RFC 7084 says
this combination is =C2=ABout of scope=C2=BB:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

In other words, your pseudocode seems to instead represent this
requirement (which is *not* a quote from RFC 7084):

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation.

That said, I do not mean to say that requesting IA_PD when O=3DM=3D0 is a
wrong thing to do for a RFC 7084 CE. The O=3DM=3D0 case is, after all, left
unspecified.

> your pseudocode also had the bug of coupling DHCP and SLAAC address
> assignment.

Agreed.

In any case, I think we can also agree that it is improper for
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 to imply that the
availability of IA_PD is contingent on the M flag alone?

The authors could avoid opening this apparent can of worms by changing
the current bullet:

   o  M-flag =3D 0 (UE/subscriber address is not managed through DHCPv6),
      this flag may be set to 1 in the future if/when DHCPv6 prefix
      delegation support over Wi-Fi is desired)

With:

   o  M-flag =3D 0 (UE/subscriber address is not managed through DHCPv6).

That way, the draft doesn't say anything controversial, and we can
leave the discussion on if IA_PD is =C2=ABaddresses=C2=BB, =C2=ABother than
addresses=C2=BB, or =C2=ABother than "other than addresses"=C2=BB for anoth=
er day.

[The draft does in any case goes on to say that O should be set to 1,
which means the described network already accomodates for (future) use
of IA_PD for both of our world views: an UE implemented by me would
then request IA_PD because of O=3D1, and one written by you would - AIUI
- just ignore the O/M flags and request IA_PD unconditionally.]

Tore


From nobody Fri Oct 30 00:17:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB381B35DB for ; Fri, 30 Oct 2015 00:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW4gOrXkU5u1 for ; Fri, 30 Oct 2015 00:17:43 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B381B35D9 for ; Fri, 30 Oct 2015 00:17:42 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=45194 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zs3wR-0002AZ-Iy; Fri, 30 Oct 2015 08:17:39 +0100
Date: Fri, 30 Oct 2015 08:17:39 +0100
From: Tore Anderson 
To: Brian E Carpenter 
Message-ID: <20151030081739.466d20a0@echo.ms.redpill-linpro.com>
In-Reply-To: <563292BE.2090000@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <563292BE.2090000@gmail.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 07:17:44 -0000

* Brian E Carpenter 

> Somebody did mention that in practice, M=3D=3DO=3D=3D0 might actually mean
> "we run DHCPv6 but forgot to set the bits". But I don't know what to
> do about that.

Another possibility is that there are multiple routers on the link
but not all of them one of them include a, or are aware of any, DHCPv6
service present on the link.

To accomodate for such a network I'd expect nodes to determine the
effective value of the flag in question to be 1 as long as at least 1
RA with the flag set to 1 is received (boolean OR, in other words).
Consequentally, a single RA with M=3DO=3D0 shouldn't be understood to
authoritatively communicate that there is no DHCPv6 service present on
the link.

However if each and every received RA on the link contain M=3DO=3D0 I think
it is the most expected node behaviour (cf. RFC4861's statement that
M=3DO=3D0 =C2=ABindicates that no information is available via DHCPv6=C2=BB=
) to not
start any DHCPv6 client at all - and for the record, that would mean
not requesting IA_PD.

Tore


From nobody Fri Oct 30 00:39:02 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1B1A89A5 for ; Fri, 30 Oct 2015 00:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p3guMKLy8gO for ; Fri, 30 Oct 2015 00:38:57 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A701A87C1 for ; Fri, 30 Oct 2015 00:38:56 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 895D462E91 for ; Fri, 30 Oct 2015 08:38:54 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5497660391 for ; Fri, 30 Oct 2015 08:38:54 +0100 (CET)
Received: (qmail 46596 invoked by uid 1007); 30 Oct 2015 08:38:54 +0100
Date: Fri, 30 Oct 2015 08:38:54 +0100
From: Gert Doering 
To: Tore Anderson 
Message-ID: <20151030073854.GZ70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , ???????????? 
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 07:38:59 -0000

Hi,

On Fri, Oct 30, 2015 at 07:58:49AM +0100, Tore Anderson wrote:
> We can even disregard RFC 7084, as it's not a standard. RFC 4861
> Section 4.2 is where the flags and their meaning is specified. It says,
> and I quote:
[..]
> So DHCPv6-provided configuration is divided into two categories:
> 
> 1) addresses
> 2) other
> 
> The availability of both of these categories of configuration is
> signalled through the M/O flags. Nowhere that I can find is a third
> «other than "other"» category of DHCPv6-provided configuration defined
> or even hinted at.

I do not have RFCs to counter that, but my interpretation is a bit
different.  I see that section of 4861 as traditionally applied to 
*hosts*, while IA_PD traditionally is a *router* function, so out of 
scope for the "host part" of 4861.

Now this gets all muddled together when you have a router that also 
wants an address for itself (= acting as a host for that purpose) or 
a host that wants a prefix (= serving as a router for that prefix).

Conceptually, still, "address for me" is a fairly independent thing
from "prefix for something I serve as a router"...  and 4861/O/M only
seem to cover the "address for me" part.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Fri Oct 30 01:11:02 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DED1A923A for ; Fri, 30 Oct 2015 01:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUhY9QQQdf2r for ; Fri, 30 Oct 2015 01:11:00 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1F91A9235 for ; Fri, 30 Oct 2015 01:11:00 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=46578 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zs4m0-0003WY-3N; Fri, 30 Oct 2015 09:10:56 +0100
Date: Fri, 30 Oct 2015 09:10:55 +0100
From: Tore Anderson 
To: Gert Doering 
Message-ID: <20151030091055.2b050875@echo.ms.redpill-linpro.com>
In-Reply-To: <20151030073854.GZ70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 08:11:01 -0000

Hi Gert,

* Gert Doering 

> I do not have RFCs to counter that, but my interpretation is a bit
> different.  I see that section of 4861 as traditionally applied to=20
> *hosts*, while IA_PD traditionally is a *router* function, so out of=20
> scope for the "host part" of 4861.

Section 4.2 of RFC 4861 simply describes the RA message format, it's
not in a "host part" of the RFC as far as I can tell. Keep in mind that
RAs are typically multicast to all IPv6 nodes, so the originating router
does not know whether it is a host or a router (or both, or none) that
will be receiving the RA.

Thus, when determining whether or not to set the M/O flags, the
[operator configuring the] RA originating router will have to ask
himself the following question:

=C2=ABIs there information available through DHCPv6 to nodes on this link?=
=C2=BB

If the answer to that question is =C2=AByes=C2=BB, the M or O flag should b=
e set.
If the answer is =C2=ABno=C2=BB, they should be both unset.

> Now this gets all muddled together when you have a router that also=20
> wants an address for itself (=3D acting as a host for that purpose) or=20
> a host that wants a prefix (=3D serving as a router for that prefix).

I'll note that this discussion started with a comment on
draft-jjmb-v6ops-unique-ipv6-prefix-per-host. This draft talks about
hosts, not routers. It even says so right there in the file name and
the title.

Then you have RFC 7084 which to the best of my knowledge is describes
the only use case for DHCPv6-PD which has seen significant deployment
to date. Its WPD-4 requirement clearly indicates that the availability
of DHCPv6-PD is something that should be communicated through the M/O
options.

The WPD-4 requirement essentially states that if you operate a network
that provides IA_PD and sets M=3DO=3D0, it's unspecified ("out of scope")
whether or not any connecting devices conforming to RFC 7084 end up
with a delegated prefix or not.

Tore


From nobody Fri Oct 30 01:21:52 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054461B2D50 for ; Fri, 30 Oct 2015 01:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECwr_pUbunF8 for ; Fri, 30 Oct 2015 01:21:35 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB951B2C7A for ; Fri, 30 Oct 2015 01:21:34 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 21AE862F1E for ; Fri, 30 Oct 2015 09:21:32 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D2AD460274 for ; Fri, 30 Oct 2015 09:21:31 +0100 (CET)
Received: (qmail 49678 invoked by uid 1007); 30 Oct 2015 09:21:31 +0100
Date: Fri, 30 Oct 2015 09:21:31 +0100
From: Gert Doering 
To: Tore Anderson 
Message-ID: <20151030082131.GC70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="95IR4Z1jyAeb17Hd"
Content-Disposition: inline
In-Reply-To: <20151030091055.2b050875@echo.ms.redpill-linpro.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 08:21:37 -0000

--95IR4Z1jyAeb17Hd
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Oct 30, 2015 at 09:10:55AM +0100, Tore Anderson wrote:
> * Gert Doering 
>=20
> > I do not have RFCs to counter that, but my interpretation is a bit
> > different.  I see that section of 4861 as traditionally applied to=20
> > *hosts*, while IA_PD traditionally is a *router* function, so out of=20
> > scope for the "host part" of 4861.
>=20
> Section 4.2 of RFC 4861 simply describes the RA message format, it's
> not in a "host part" of the RFC as far as I can tell. Keep in mind that
> RAs are typically multicast to all IPv6 nodes, so the originating router
> does not know whether it is a host or a router (or both, or none) that
> will be receiving the RA.

Yes, but that is the point - "typical routers" do not need to *listen* to=
=20
RAs, because that's not required for their job.  They will speak a=20
routing protocol, and not default-route, etc.

As I said, boundaries between "hosts" and "router" are less than clear
today - but this is my interpretation on how these have come into place.

> Thus, when determining whether or not to set the M/O flags, the
> [operator configuring the] RA originating router will have to ask
> himself the following question:
>=20
> =ABIs there information available through DHCPv6 to nodes on this link?=BB
>=20
> If the answer to that question is =AByes=BB, the M or O flag should be se=
t.
> If the answer is =ABno=BB, they should be both unset.

There might not even *be* a RA if this is a pure router-to-router link...

> > Now this gets all muddled together when you have a router that also=20
> > wants an address for itself (=3D acting as a host for that purpose) or=
=20
> > a host that wants a prefix (=3D serving as a router for that prefix).
>=20
> I'll note that this discussion started with a comment on
> draft-jjmb-v6ops-unique-ipv6-prefix-per-host. This draft talks about
> hosts, not routers. It even says so right there in the file name and
> the title.

True, but as soon as a host requests a prefix for "a bunch of VMs" running
on that same host, and forwards traffic between "the outside router" and
"the various VMs", it very much becomes a router...

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--95IR4Z1jyAeb17Hd
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVjMoi99WwGXkzn/FAQI/nQ/8DY3mxstgGli3fujMq1akz5PBTRskvPOY
KYXcMGjmV64W4KZbIRD7icDOeCSRlvZiBVMUUXsJsT1xksyJDrw/+V7YIH8qOJEW
H80mPvtuUqkZSs8MARGXyetNyK5+DN3Vny1j7+3IJAF8suyriffTPiEHUp2HaCC0
soYn13ECYz2uW6aGo++yKGaIoBxp+ZvpxM8prhiVOHV6yqx+sXD6FFt2nq4uTrQ2
fchJeKusGDNsBo3ArWMsr13/K0FByTHRpV8UYkCu/Q+GognjWCGi1qE6yDsSJ7Dl
DE5Z9Q3GEW0U17YweQpf6ZQp4OQAyGryh2QI9jWqVrT99aJMU8mT/FjA9ctuSLBi
qoC3lY5cJotky70TqSUafCnGP5yDxk1mmfesLF/cYHIrjJHYoEAWKKoen+z3vCeW
LkGYkdcn6xccJSE5QB+EI97yRtpDPd9gmHq0ZAgEkiqcsIZFJw6iqGkQiRGpbzyG
fkevzXL/4gVRdK50w0ifl5FwNLVrzXo1NV3QJzUnEHuV7zFnuHSuaDgsv2WtMWhy
opfVllG1v5aap3/VQAJ3kxH6ohndoaHW4s/fvgLVHg+qcPXRoAR0geofpcVS82go
oMAHEmAKFlvXYx55wKS3gcYMZc4xytfK620682gUdFtCSGGgp11XPD5A09SO9Bry
gJy1BtjwrBs=
=9d5+
-----END PGP SIGNATURE-----

--95IR4Z1jyAeb17Hd--


From nobody Fri Oct 30 01:55:46 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC781A6F2A for ; Fri, 30 Oct 2015 01:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd8pGHWtvttE for ; Fri, 30 Oct 2015 01:55:44 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CC61A6F0B for ; Fri, 30 Oct 2015 01:55:43 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=47734 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zs5TG-0004ei-Gt; Fri, 30 Oct 2015 09:55:38 +0100
Date: Fri, 30 Oct 2015 09:55:38 +0100
From: Tore Anderson 
To: Gert Doering 
Message-ID: <20151030095538.20544d0a@echo.ms.redpill-linpro.com>
In-Reply-To: <20151030082131.GC70452@Space.Net>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <20151030082131.GC70452@Space.Net>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 08:55:45 -0000

* Gert Doering 

> Yes, but that is the point - "typical routers" do not need to
> *listen* to RAs, because that's not required for their job.  They
> will speak a routing protocol, and not default-route, etc.

Who is listening for RAs or not seems to me to be besides the point. It
boils down to this: If you are about to originate an RA to a link, and
know that there is information available in DHCPv6 on said link, you
should set set the M or O flag. Otherwise you're supplying false
information by indicating that there is no information available in
DHCPv6.

The possibility of there being a node (router) on the link that does
not listen to RAs does not seem relevant - you'd still be giving out
false information to anyone else on that link.

> As I said, boundaries between "hosts" and "router" are less than clear
> today - but this is my interpretation on how these have come into place.

Indeed. Thus I believe claims like =C2=ABhosts don't request prefixes=C2=BB=
 or
=C2=ABrouters don't process RAs=C2=BB can't be considered true (unless a no=
de can
be both simultaneously).

> There might not even *be* a RA if this is a pure router-to-router
> link...

If you're not sending any RAs to begin with then you obviously do not
have to set any RA flags. That's fine. My point is just that IFF you
send RAs, make sure you send correct information - by setting the M or O
flag if there is any form DHCPv6 service being provided to the link.

In any case I don't think RA-less pure router-to-router links are
particularly relevant to a discussion on whether or not DHCPv6-PD is
signalled using the M/O RA flags. At least I have never seen a use case
where DHCPv6-PD being used on such RA-less router-to-router links, have
you?

> as soon as a host requests a prefix for "a bunch of VMs" running on
> that same host, and forwards traffic between "the outside router" and
> "the various VMs", it very much becomes a router...

...that, crucially, will continue to process RAs (just like a RFC 7084
CE router will). So the RA we're sending that host ought to contain
correct information.

Tore


From nobody Fri Oct 30 02:06:53 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B831A87A2 for ; Fri, 30 Oct 2015 02:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESPLKSewE_lo for ; Fri, 30 Oct 2015 02:06:50 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E866A1A879E for ; Fri, 30 Oct 2015 02:06:49 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DCCAF62F0D for ; Fri, 30 Oct 2015 10:06:47 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8347362E91 for ; Fri, 30 Oct 2015 10:06:47 +0100 (CET)
Received: (qmail 52743 invoked by uid 1007); 30 Oct 2015 10:06:47 +0100
Date: Fri, 30 Oct 2015 10:06:47 +0100
From: Gert Doering 
To: Tore Anderson 
Message-ID: <20151030090647.GG70452@Space.Net>
References: <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <20151030082131.GC70452@Space.Net> <20151030095538.20544d0a@echo.ms.redpill-linpro.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+T+TIFsggo/fsWlW"
Content-Disposition: inline
In-Reply-To: <20151030095538.20544d0a@echo.ms.redpill-linpro.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 09:06:52 -0000

--+T+TIFsggo/fsWlW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Oct 30, 2015 at 09:55:38AM +0100, Tore Anderson wrote:
> * Gert Doering 
>=20
> > Yes, but that is the point - "typical routers" do not need to
> > *listen* to RAs, because that's not required for their job.  They
> > will speak a routing protocol, and not default-route, etc.
>=20
> Who is listening for RAs or not seems to me to be besides the point. It
> boils down to this: If you are about to originate an RA to a link, and
> know that there is information available in DHCPv6 on said link, you
> should set set the M or O flag. Otherwise you're supplying false
> information by indicating that there is no information available in
> DHCPv6.

No, the point I was trying to made is: conceptually, DHCPv6 PD is happening
outside RA.  RA is "information to hosts", PD is "done by routers".

But I already agreed that this is not written down anywhere, but my
interpretation on how this can all make sense.

[..]
> > As I said, boundaries between "hosts" and "router" are less than clear
> > today - but this is my interpretation on how these have come into place.
>=20
> Indeed. Thus I believe claims like =ABhosts don't request prefixes=BB or
> =ABrouters don't process RAs=BB can't be considered true (unless a node c=
an
> be both simultaneously).

We had this discussion in the context of the CPE spec - a CPE is a=20
router (obviously), but for acquiring its management IPv6 address and
for being talked to on the management address, it's very obviously a
host as well.  So of course a node can be both.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--+T+TIFsggo/fsWlW
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVjMzJ99WwGXkzn/FAQKOTxAAmbhzf0tROVsdOjo6c0Xz/rBqySipyYRo
5NEDCd55znpMVujA2KPBQ7If+nplmnCRAXBp6Xj1nxoxbRdeElVfGcPq2Pu2CopF
BVmfBH+pcvCG3apgcHwMrMOWqgbFpnJa+bYxZVGT7gJ/an+EFU62vkiy52Cf2BVD
JF38gx0sGQK6V3rwaxyR+5AFxc1rUcB9XV/Hg1RlbEd029tUFijXF7VSHrR/CHLt
Pu1OgjKL/kK/YKgI0yEKHHEgCols8JmkwBaEG/YfFEBxBY3pYIjv7KfmqZnskXPC
NNqeOOKIoqYZTko8/OczN1YoqAabNMkyGw9N10u8DfR2byo6ySwnVNOU9VYtELu3
HIpbJGZNj9GUuwM5VyPAgQXmk6XyV2kQPGbNxrCKhWJHJ6NcLKUofEP/dM+Vr2QX
jqkAvf5xEuCGC7nQ/RuZw86mm9VZTTHp6ysqb0sjkcb+FiJW/2nbKdj3XdaL9u31
XKPLUvP1kiA8zA/qUbPEPNHf06NDmFU+yUcdNjoWaBB3VhJB9CKVm+Q05bRQOsb+
6wseaJGWCp6+NL/uHKsiqCZBpSmjylfgC9eOihnrh+rdM8DbuqG6SomtgM89VtDQ
qfRFA6ezeVt8OYxMM5Os0zRBB+ViVKtn+XZOo/DLo7P9/RqLNG+rEVPcLq3MP6JJ
TY347D3OSqc=
=mRDy
-----END PGP SIGNATURE-----

--+T+TIFsggo/fsWlW--


From nobody Fri Oct 30 07:42:22 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103131A21AD for ; Fri, 30 Oct 2015 07:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3U4yyn5fIfa for ; Fri, 30 Oct 2015 07:42:18 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4B71A21A0 for ; Fri, 30 Oct 2015 07:42:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9UEgIun021039; Fri, 30 Oct 2015 09:42:18 -0500
Received: from XCH-BLV-203.nw.nos.boeing.com (xch-blv-203.nw.nos.boeing.com [10.57.37.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9UEg9VF020471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 30 Oct 2015 09:42:10 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.45]) with mapi id 14.03.0235.001; Fri, 30 Oct 2015 07:42:08 -0700
From: "Templin, Fred L" 
To: Mark Smith 
Thread-Topic: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHREpWlfhRQDc9H8Umtd3rwf220Z56DwPyAgABaLLA=
Date: Fri, 30 Oct 2015 14:42:07 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F348C2@XCH-BLV-504.nw.nos.boeing.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <2134F8430051B64F815C691A62D9831832F33F22@XCH-BLV-504.nw.nos.boeing.com> <5632952C.5030604@gmail.com> <5EFCC4F7-802D-48A2-B4C3-CEA884559E08@employees.org> <2134F8430051B64F815C691A62D9831832F33FD3@XCH-BLV-504.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: Tore Anderson , =?utf-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 14:42:20 -0000

SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt
aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9j
dG9iZXIgMjksIDIwMTUgNzoxMiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMDQo+IENjOiBvdHJv
YW5AZW1wbG95ZWVzLm9yZzsgQnJpYW4gRSBDYXJwZW50ZXI7IHY2b3BzQGlldGYub3JnOyBUb3Jl
IEFuZGVyc29uOyDnpZ7mmI7pgZTlk4kNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlv
bjogZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQo+
IA0KPiBIaSBGcmVkLA0KPiANCj4gT24gMzAgT2N0b2JlciAyMDE1IGF0IDA5OjAzLCBUZW1wbGlu
LCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+IEhpIEJyaWFu
LA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IDxzbmlwPg0KPiA+DQo+
ID4gVGhlIHNhbWUgYXMgd2hhdCBPbGUgc2FpZC4gQWxzbywgYW4gSVB2Ni1vdmVyLShmb28pIGRv
Y3VtZW50IGNhbiBzcGVjaWZ5IHRoYXQNCj4gPiBESENQdjYtb25seSBhdXRvY29uZmlndXJhdGlv
biBpcyB1c2VkIG9uIHRoYXQgbGluay4NCj4gDQo+IERvIGFueSBleGlzdCB0aGF0IHN0YXRlIHRo
YXQ/DQoNClllcywgQUVSTyBpcyBhbiBleGFtcGxlLiANCg0KPiBJJ2QgaG9wZSBpbiB0aGF0IGNh
c2UgdGhlIElQdjYtb3Zlci0oZm9vKSBkb2N1bWVudCBtZW50aW9ucyB0aGF0IGlmIGENCj4gc3Rh
dGVmdWwgREhDUHY2IHNlcnZlciBpcyBub3QgYXZhaWxhYmxlLCB0aGUgaG9zdHMgYXJlIG9ubHkg
bGVmdCB3aXRoDQo+IGxpbmstbG9jYWwgYWRkcmVzc2VzIHRvIHVzZSBmb3IgYWxsIElQdjYgb3Bl
cmF0aW9ucyBhbmQgYXBwbGljYXRpb25zLg0KDQpJbiB0aGUgY2FzZSBvZiBBRVJPLCBpZiBhIHN0
YXRlZnVsIERIQ1B2NiBzZXJ2ZXIgaXMgbm90IGF2YWlsYWJsZSB0aGUNCmhvc3RzIGNhbiBzdGls
bCBjb21tdW5pY2F0ZSB1c2luZyBsaW5rLWxheWVyIGFkZHJlc3NpbmcgYW5kIHRoZSBBRVJPDQps
aW5rIHdpbGwgbm90IGJlIGFjdGl2YXRlZC4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBs
aW5AYm9laW5nLmNvbQ0KDQo+IFJlZ2FyZHMsDQo+IE1hcmsuDQo+IA0KPiANCj4gPiBJbiB0aGF0
IHdheSwgSVB2NiBub2Rlcw0KPiA+IHRoYXQgY29ubmVjdCB0byBhIChmb28pIGxpbmsgYWxyZWFk
eSBrbm93biBpbiBhZHZhbmNlIHdoYXQgc29ydHMgb2YgbGluaw0KPiA+IE5EL0RIQ1B2NiBzZXJ2
aWNlcyB0aGV5IGNhbiBleHBlY3QuDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4gZnJlZC5s
LnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gT2xlDQo+
ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K


From nobody Fri Oct 30 07:45:23 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9201A1BC2 for ; Fri, 30 Oct 2015 07:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLAyINgF5UEw for ; Fri, 30 Oct 2015 07:45:20 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CFA1A1A98 for ; Fri, 30 Oct 2015 07:45:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t9UEjLFF026076; Fri, 30 Oct 2015 09:45:21 -0500
Received: from XCH-BLV-406.nw.nos.boeing.com (xch-blv-406.nw.nos.boeing.com [130.247.25.162]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t9UEjB4U025409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 30 Oct 2015 09:45:11 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.161]) with mapi id 14.03.0235.001; Fri, 30 Oct 2015 07:45:09 -0700
From: "Templin, Fred L" 
To: Gert Doering , Tore Anderson 
Thread-Topic: [v6ops] M/O flags and PD
Thread-Index: AQHREuB/Fp3T7dBlRUqAWJXhaLg8yZ6EG6UAgAAI8oCAAAL2gIAACYkAgAADHYD//+h2UA==
Date: Fri, 30 Oct 2015 14:45:08 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F348D8@XCH-BLV-504.nw.nos.boeing.com>
References: <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <20151030082131.GC70452@Space.Net> <20151030095538.20544d0a@echo.ms.redpill-linpro.com> <20151030090647.GG70452@Space.Net>
In-Reply-To: <20151030090647.GG70452@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" , "jinmei@wide.ad.jp" 
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 14:45:22 -0000

Hi Gert,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering
> Sent: Friday, October 30, 2015 2:07 AM
> To: Tore Anderson
> Cc: v6ops@ietf.org; jinmei@wide.ad.jp
> Subject: Re: [v6ops] M/O flags and PD
>=20
> Hi,
>=20
> On Fri, Oct 30, 2015 at 09:55:38AM +0100, Tore Anderson wrote:
> > * Gert Doering 
> >
> > > Yes, but that is the point - "typical routers" do not need to
> > > *listen* to RAs, because that's not required for their job.  They
> > > will speak a routing protocol, and not default-route, etc.
> >
> > Who is listening for RAs or not seems to me to be besides the point. It
> > boils down to this: If you are about to originate an RA to a link, and
> > know that there is information available in DHCPv6 on said link, you
> > should set set the M or O flag. Otherwise you're supplying false
> > information by indicating that there is no information available in
> > DHCPv6.
>=20
> No, the point I was trying to made is: conceptually, DHCPv6 PD is happeni=
ng
> outside RA.  RA is "information to hosts", PD is "done by routers".
>=20
> But I already agreed that this is not written down anywhere, but my
> interpretation on how this can all make sense.
>=20
> [..]
> > > As I said, boundaries between "hosts" and "router" are less than clea=
r
> > > today - but this is my interpretation on how these have come into pla=
ce.
> >
> > Indeed. Thus I believe claims like  or
> >  can't be considered true (unless a node can
> > be both simultaneously).
>=20
> We had this discussion in the context of the CPE spec - a CPE is a
> router (obviously), but for acquiring its management IPv6 address and
> for being talked to on the management address, it's very obviously a
> host as well.  So of course a node can be both.

Right, and it is fine for a host to act as a requesting router from the
standpoint of DHCPv6 PD but then use the delegated prefix for its
own multi-addressing purposes rather than to provision addresses
for other hosts.

Thanks - Fred
fred.l.templin@boeing.com

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>=20
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culema=
nn
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Fri Oct 30 08:24:48 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AAD1A8828 for ; Fri, 30 Oct 2015 08:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.094
X-Spam-Level: 
X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWctlJX3TG3W for ; Fri, 30 Oct 2015 08:24:44 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933F01A8824 for ; Fri, 30 Oct 2015 08:24:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9C5E665; Fri, 30 Oct 2015 16:24:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1446218680; bh=h7TS1d039dC4fuK7HUC5h9p62xFH9H4jSZL3Ia3NvVk=; b=J TeKJY8lkhjG7irw0G5deNPEsDmrdwkid9TSkg9gtLIM0Fy4+f+FPBuAhCPWefiPN 8XW2iv16LiQ/VW3inmzFLmId5i5ElNXOSFZqpXdOSYiN0r0gbBt/V0iipxalt5Gm CYw35kN0Vo+T6XyPPJh8dt9LevlQ2L+eiWf8+b35cM=
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 BhxrgPmZcKZ8; Fri, 30 Oct 2015 16:24:40 +0100 (CET)
Received: from [IPv6:2a00:8640:1::7995:aa3c:f825:c77d] (unknown [IPv6:2a00:8640:1:0:7995:aa3c:f825:c77d]) by mail.sintact.nl (Postfix) with ESMTPSA id F169563; Fri, 30 Oct 2015 16:24:38 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <20151030091055.2b050875@echo.ms.redpill-linpro.com>
Date: Fri, 30 Oct 2015 16:24:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com>
To: Tore Anderson 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 15:24:46 -0000

Hi Tore,

Op 30 okt. 2015, om 09:10 heeft Tore Anderson  het volgende =
geschreven:
> * Gert Doering 
>=20
>> I do not have RFCs to counter that, but my interpretation is a bit
>> different.  I see that section of 4861 as traditionally applied to=20
>> *hosts*, while IA_PD traditionally is a *router* function, so out of=20=

>> scope for the "host part" of 4861.
>=20
> Section 4.2 of RFC 4861 simply describes the RA message format, it's
> not in a "host part" of the RFC as far as I can tell. Keep in mind =
that
> RAs are typically multicast to all IPv6 nodes, so the originating =
router
> does not know whether it is a host or a router (or both, or none) that
> will be receiving the RA.

I always understood this bit from RFC 3633 to mean that any host =
configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note =
that this use of DHCP is not bound to the assignment of IP addresses or =
other configuration information to hosts".

Cheers,
Sander


From nobody Fri Oct 30 12:08:47 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE11B3154 for ; Fri, 30 Oct 2015 12:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbIUFCuLEzhU for ; Fri, 30 Oct 2015 12:08:43 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01B51B3158 for ; Fri, 30 Oct 2015 12:08:43 -0700 (PDT)
Received: by pasz6 with SMTP id z6so82146243pas.2 for ; Fri, 30 Oct 2015 12:08:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=AJwmAAPoc/iSwwvoTCczazswOHpuffaeMwFYLQ5xHXE=; b=de1Ih/gNtBRetahG4E/YAasvUh4agaLwjj3GsOHNSZCMB/PipURRGIMQJBGSBLnZyu MuHDFmDyxGIRpTgjz62/uIjvjmHTbHtig63UOVBm+fO7anmCA2ZYkadjeRDkvYniN3ZI W0v+uuZ3lbljMwoplZJNqIGFtY+/7OyC6U01t/BuZfD7fjBrFOWTx5nua7wB0qu5qfEE MNeQOZ9UtzM+tMNpDYt1/V314+EX6j7upZB4qienATogFO8oy9KfisOgIMOSJaA24MOH 1nZgcsDynyIHBiGo06h6ESE0OCKnKP3eErBaVs712FPqEu4EH8xq+sv3BpXEEoGO16+T v9rg==
X-Received: by 10.66.144.169 with SMTP id sn9mr10766123pab.15.1446232123517; Fri, 30 Oct 2015 12:08:43 -0700 (PDT)
Received: from ?IPv6:2406:e007:498f:1:28cc:dc4c:9703:6781? ([2406:e007:498f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z12sm9600587pbt.30.2015.10.30.12.08.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2015 12:08:42 -0700 (PDT)
To: Sander Steffann , Tore Anderson 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5633C030.6040202@gmail.com>
Date: Sat, 31 Oct 2015 08:08:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 19:08:45 -0000

On 31/10/2015 04:24, Sander Steffann wrote:
> Hi Tore,
> 
> Op 30 okt. 2015, om 09:10 heeft Tore Anderson  het volgende geschreven:
>> * Gert Doering 
>>
>>> I do not have RFCs to counter that, but my interpretation is a bit
>>> different.  I see that section of 4861 as traditionally applied to 
>>> *hosts*, while IA_PD traditionally is a *router* function, so out of 
>>> scope for the "host part" of 4861.
>>
>> Section 4.2 of RFC 4861 simply describes the RA message format, it's
>> not in a "host part" of the RFC as far as I can tell. Keep in mind that
>> RAs are typically multicast to all IPv6 nodes, so the originating router
>> does not know whether it is a host or a router (or both, or none) that
>> will be receiving the RA.
> 
> I always understood this bit from RFC 3633 to mean that any host configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note that this use of DHCP is not bound to the assignment of IP addresses or other configuration information to hosts".

The phrase "is not bound to" is rather unclear, don't you think? It neither says
nor implies that routers are thereby exempt from issuing correct RAs.

However, being realistic, note that
On 30/10/2015 21:55, Tore Anderson wrote:

> It boils down to this: If you are about to originate an RA to a link, and
> know that there is information available in DHCPv6 on said link, you
> should set set the M or O flag.

Even if you accept that, in the case that you *don't* know that such information
is available, you physically cannot set the M or O flag. So in the real world,
a node that is interested in IA_PD had better go fishing for it, whatever the
MO bits say. So I retract all the if statements in the pseudocode that I sent.
The only robust implementation is one that always looks for DHCPv6 information.

    Brian



From nobody Fri Oct 30 12:22:44 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A376F1B3AD5 for ; Fri, 30 Oct 2015 12:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHqXQJVvjCNW for ; Fri, 30 Oct 2015 12:22:42 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90061B3ACF for ; Fri, 30 Oct 2015 12:22:41 -0700 (PDT)
Received: by wijp11 with SMTP id p11so17544152wij.0 for ; Fri, 30 Oct 2015 12:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R2g0q/U8yZbQHcGgqFL7kGQRK8ZtoF0Z2c5TPMeqBZ0=; b=I7wfPmQ72nMi2En0SitaNJ4bZCReA7IJkRPsQiyw+DsjMXkppr8HWrdjOsgp3/wxHh SWBm8zi6iDh5k+f/B7GdSbQ6wkNTIuuKGgc4HpusitlvASKfOJ27WxCBgBqTonr8MZiY UreBrTkubfAOPfUw09JJ6jaqzjqnHVYemg0DzIcNs7Mrqpzo7pJcTC8Y3ZHjtzKkeNbA 9NIUNwysaPoS3nSNlfLQcritso3KANVWIbhHonwKTdMxLGJp/22UkHZAffkwEH51pFbr kk5FDoluuEfdNcTJSZjevDwRsdG7kuwz89R9vNS6MRHKFwUAgyVkMRh2sG5IDZG+CdIC 7kFQ==
MIME-Version: 1.0
X-Received: by 10.194.109.99 with SMTP id hr3mr11504763wjb.25.1446232960430; Fri, 30 Oct 2015 12:22:40 -0700 (PDT)
Received: by 10.194.192.40 with HTTP; Fri, 30 Oct 2015 12:22:40 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 30 Oct 2015 12:22:40 -0700
Message-ID: 
From: Ca By 
To: David Schinazi 
Content-Type: multipart/alternative; boundary=089e010d8a6ede78ea05235759d8
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] Apple and IPv6 - new NAT64 address synthesis API
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 19:22:43 -0000

--089e010d8a6ede78ea05235759d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 29, 2015 at 9:51 PM, David Schinazi  wrote=
:

> Hi everyone,
>
> This week Apple released the first betas of iOS 9.2 and OS X 10.11.2.
> With it, we=E2=80=99ve introduced a new API to allow developers to synthe=
size
> NAT64 IPv6 addresses from IPv4 literals.
> We=E2=80=99re hoping that this will help more applications support NAT64 =
networks
> correctly while they work on getting server support for IPv6.
> As usual, we=E2=80=99d love feedback from the IETF community.
>
> The API is very simple: we ask developers to always ``resolve'=E2=80=99 t=
heir IPv4
> literals using getaddrinfo() by treating their IPv4 literal as a hostname
> string (e.g. ``192.0.2.1''), and we will take care of returning an IPv4
> sockaddr on IPv4 networks and an appropriately synthesized NAT64 IPv6
> sockaddr when the network supports IPv6, NAT64 and DNS64 but not IPv4. Th=
is
> is accomplished using RFC 6052 and RFC 7050.
>
> Our target audience is application developers that need to communicate to
> an IPv4-only host for which they do not have a hostname. An example is a
> P2P service transmitting IPv4 literals over the wire. We do agree that th=
e
> correct long-term solution is IPv6 support for all hosts and protocols bu=
t
> this is an effort to ease the transition. We believe this will help fix a=
ny
> remaining apps that do not support IPv6 before we start rejecting them fr=
om
> the App Store in early 2016.
>
> More details and a code sample can be found on the Apple documentation
> website:
>
>
> https://developer.apple.com/library/prerelease/tvos/documentation/Network=
ingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingforth=
eIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_=
ref/doc/uid/TP40010220-CH213-DontLinkElementID_4
>
> Thanks,
> David Schinazi
> Apple CoreOS Networking Engineer
>

Thanks David, this is clearly a helpful step.




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

--089e010d8a6ede78ea05235759d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 29, 2015 at 9:51 PM, David Schinazi <<=
a href=3D"mailto:dschinazi@apple.com" target=3D"_blank">dschinazi@apple.com=
> wrote:
Hi everyone,

This week Appl=
e released the first betas of iOS 9.2 and OS X 10.11.2.
With it, =
we=E2=80=99ve introduced a new API to allow developers to synthesize NAT64 =
IPv6 addresses from IPv4 literals.
We=E2=80=99re hoping that this=
 will help more applications support NAT64 networks correctly while they wo=
rk on getting server support for IPv6.
As usual, we=E2=80=99d lov=
e feedback from the IETF community.

The API is ver=
y simple: we ask developers to always ``resolve'=E2=80=99 their IPv4 li=
terals using getaddrinfo() by treating their IPv4 literal as a hostname str=
ing (e.g. ``192.0.2.1''), and we will take care of returning an IPv=
4 sockaddr on IPv4 networks and an appropriately synthesized NAT64 IPv6 soc=
kaddr when the network supports IPv6, NAT64 and DNS64 but not IPv4. This is=
 accomplished using RFC 6052 and RFC 7050.

Our tar=
get audience is application developers that need to communicate to an IPv4-=
only host for which they do not have a hostname. An example is a P2P servic=
e transmitting IPv4 literals over the wire. We do agree that the correct lo=
ng-term solution is IPv6 support for all hosts and protocols but this is an=
 effort to ease the transition. We believe this will help fix any remaining=
 apps that do not support IPv6 before we start rejecting them from the App =
Store in early 2016.

More details and a code sampl=
e can be found on the Apple documentation website:

https://developer.apple.com/library/prerelease/tvos/documentation/Networ=
kingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfort=
heIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple=
_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4

<=
div>Thanks,
David Schinazi
Apple CoreOS Networking Engi=
neer

Thanks David, this is clea=
rly a helpful step.


=C2=A0

___________________________________________=
____

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--089e010d8a6ede78ea05235759d8--


From nobody Fri Oct 30 14:12:53 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155AB1A03A3 for ; Fri, 30 Oct 2015 14:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1P32XtWLzp9 for ; Fri, 30 Oct 2015 14:12:20 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538B71A039F for ; Fri, 30 Oct 2015 14:12:20 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id D75C03493C7; Fri, 30 Oct 2015 21:12:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 50E9D160044; Fri, 30 Oct 2015 21:12:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3DC0516008D; Fri, 30 Oct 2015 21:12:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ipHCeW8_0a6d; Fri, 30 Oct 2015 21:12:43 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B074B160044; Fri, 30 Oct 2015 21:12:42 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2FC023B95BDB; Sat, 31 Oct 2015 08:12:14 +1100 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl> <5633C030.6040202@gmail.com>
In-reply-to: Your message of "Sat, 31 Oct 2015 08:08:32 +1300." <5633C030.6040202@gmail.com>
Date: Sat, 31 Oct 2015 08:12:14 +1100
Message-Id: <20151030211214.2FC023B95BDB@rock.dv.isc.org>
Archived-At: 
Cc: "v6ops@ietf.org" , Tore Anderson , jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Oct 2015 21:12:22 -0000

In message <5633C030.6040202@gmail.com>, Brian E Carpenter writes:
> On 31/10/2015 04:24, Sander Steffann wrote:
> > Hi Tore,
> > 
> > Op 30 okt. 2015, om 09:10 heeft Tore Anderson  het volgende geschreven:
> >> * Gert Doering 
> >>
> >>> I do not have RFCs to counter that, but my interpretation is a bit
> >>> different.  I see that section of 4861 as traditionally applied to 
> >>> *hosts*, while IA_PD traditionally is a *router* function, so out of 
> >>> scope for the "host part" of 4861.
> >>
> >> Section 4.2 of RFC 4861 simply describes the RA message format, it's
> >> not in a "host part" of the RFC as far as I can tell. Keep in mind that
> >> RAs are typically multicast to all IPv6 nodes, so the originating router
> >> does not know whether it is a host or a router (or both, or none) that
> >> will be receiving the RA.
> > 
> > I always understood this bit from RFC 3633 to mean that any host configuration flags (such as M/O) are not relevant to DHCPv6-PD: "Note that this use of DHCP is 
> not bound to the assignment of IP addresses or other configuration information to hosts".
> 
> The phrase "is not bound to" is rather unclear, don't you think? It neither says
> nor implies that routers are thereby exempt from issuing correct RAs.

Read the whole paragraph.  This has nothing to do with RA bits.

   "Note that this use of DHCP is not bound to the assignment of IP
   addresses or other configuration information to hosts, and that no
   mechanism is currently available to communicate delegated prefixes to
   a DHCP server that serves such a function.  This may be an item of
   future work, should usage warrant."

I see that as saying that there is no mechanism defined to inform
a DHCPv6 server of the prefix obtained and that the IETF may need
to do so in the future.  In most cases of the use cases DHCP server
is in the router so the router vendor just figures this out for
themselves (e.g. the dhcp client updates the dhcp server's configuration
and tells the dhcp server to reload).  In case where there is a
seperate DHCP server and the router is just the DHCP relay is left
unspecified how the obtained addresses are communicated.

Additional there is no requirement for there to be a DHCPv6 server
at all.  SLAAC or something else is sufficient.  This is the first
part of the paragraph.

This document is not a complete solution.  There are missing bits that
need to be specified to make it a complete solution.

> However, being realistic, note that
> On 30/10/2015 21:55, Tore Anderson wrote:
> 
> > It boils down to this: If you are about to originate an RA to a link, and
> > know that there is information available in DHCPv6 on said link, you
> > should set set the M or O flag.
> 
> Even if you accept that, in the case that you *don't* know that such information
> is available, you physically cannot set the M or O flag. So in the real world,
> a node that is interested in IA_PD had better go fishing for it, whatever the
> MO bits say. So I retract all the if statements in the pseudocode that I sent.
> The only robust implementation is one that always looks for DHCPv6 information.
> 
>     Brian
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Fri Oct 30 17:32:22 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F961ACD09 for ; Fri, 30 Oct 2015 17:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJeWhd-SOGzn for ; Fri, 30 Oct 2015 17:32:18 -0700 (PDT)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2094A1ACCF2 for ; Fri, 30 Oct 2015 17:32:17 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 5C91F3902E6 for ; Sat, 31 Oct 2015 01:32:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id qNiZ57h1aDcZ for ; Sat, 31 Oct 2015 01:32:09 +0100 (CET)
Received: from ipv6.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.go6lab.si (Postfix) with ESMTPS id 2820E3902E4 for ; Sat, 31 Oct 2015 01:32:09 +0100 (CET)
Received: from jan-mac.local (unknown [133.93.80.56]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 819AE3142E6 for ; Sat, 31 Oct 2015 01:32:06 +0100 (CET)
X-DKIM: Sendmail DKIM Filter v2.8.3 ipv6.go6.si 819AE3142E6
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=go6.si; s=go6.si.private; t=1446251527; bh=Mj3bMjXje8D1QlSS84J2dNAE0psAPGv8chlPmDwp3pI=; l=1149; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=sh+myzod6JU4AVw2spPYrt+LR8VWlnD+C28kyxHbQm7AnVbgur3o+/PK+TRLL481O E9hI5/xyq92nq96BtjMF7CXPCjPTAwudY3Y55MljSZ6zQ86+ywzNkPJRsTCGEF+EmL HyM9OIgF3TJjuydPeFY8M9/PD/Q5NTTyRvu65yL0=
Message-ID: <56340C02.7040505@go6.si>
Date: Sat, 31 Oct 2015 09:32:02 +0900
From: Jan Zorz 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: v6ops@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-design-choices-09 quick review :)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Oct 2015 00:32:20 -0000

Dear WG, authors...

As promised I did a quick review of draft-ietf-v6ops-design-choices-09. 
I apologize for late review submission, but the -09 version came out 
just days ago ;)

I'm not entirely happy with the ULA discussion on pages 5 and 6, but at 
the end you (let's say so) adequately underline the fact that folx need 
to strongly reconsider using ULAs in their networks. Not strong language 
and message enough for my personal taste, but let it be.

Section 2.2.1:

Option b) is feasible choice for servers in data centers because of 
numerous reasons - security (each server on separate /64), measurements 
and others. Maybe you should mention this in the text. Endpoint host has 
no need for that.

Section 2.2.2:

Hopefully you are talking just about L3 interfaces on routers. There is 
no clear and visible clarification of that as just "Interface" notion is 
used ;)

End hosts also have interface and should not even think about that ;)

Page 11:

You can carry IPv4 also in OSPFv3 this days, so additional option would 
be OSPFv3/OSPFv3

See you all at v6ops WG meeting in few days ;)

Cheers, Jan


From nobody Sat Oct 31 01:46:31 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902271A036F for ; Sat, 31 Oct 2015 01:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMcFl3vjgQq for ; Sat, 31 Oct 2015 01:46:29 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DDF1B2B2F for ; Sat, 31 Oct 2015 01:46:29 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=38511 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZsRnq-0005tP-H4; Sat, 31 Oct 2015 09:46:22 +0100
Date: Sat, 31 Oct 2015 09:46:21 +0100
From: Tore Anderson 
To: Brian E Carpenter , "v6ops@ietf.org" 
Message-ID: <20151031094621.182c6c50@envy.fud.no>
In-Reply-To: <5633C030.6040202@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl> <5633C030.6040202@gmail.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Oct 2015 08:46:30 -0000

* Brian E Carpenter

> On 31/10/2015 04:24, Sander Steffann wrote:
> 
> > I always understood this bit from RFC 3633 to mean that any host
> > configuration flags (such as M/O) are not relevant to DHCPv6-PD:
> > "Note that this use of DHCP is not bound to the assignment of IP
> > addresses or other configuration information to hosts".	
> 
> The phrase "is not bound to" is rather unclear, don't you think? It
> neither says nor implies that routers are thereby exempt from issuing
> correct RAs.

Agreed.

Also, note that RFC 3633 did *not* update RFCs 2461/2462, which at the
time defined the meaning of the O/M flags to be essentially the same as
what RFC 4861 defines them to be today.

> Even if you accept that, in the case that you *don't* know that such
> information is available, you physically cannot set the M or O flag.
> So in the real world, a node that is interested in IA_PD had better
> go fishing for it, whatever the MO bits say. So I retract all the if
> statements in the pseudocode that I sent. The only robust
> implementation is one that always looks for DHCPv6 information.

That might indeed be the case - but it's not what the standards are
currently telling the implementers to do. Furthermore, accepting this
would mean that the M/O flags are essentially pointless. In that case,
deprecating the flags would be the logical thing to do.

(You explicitly called out IA_PD, but as your argument applies equally
well to any other DHCPv6 option I'm going to assume you meant IA_PD
just as an example.)

Tore


From nobody Sat Oct 31 11:59:55 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62E1B2C4F for ; Sat, 31 Oct 2015 11:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fJOJcxeBc_P for ; Sat, 31 Oct 2015 11:59:52 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BB21B2C4E for ; Sat, 31 Oct 2015 11:59:52 -0700 (PDT)
Received: by pacfv9 with SMTP id fv9so109778324pac.3 for ; Sat, 31 Oct 2015 11:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ui8pI9GU36FEoasP7Cra5+Dj+9bpNlEn2yAezJtY6u4=; b=SxYzDGx6X+2FHGexwVHtKfGPUWPVNoZG2qiT3yLMZUFC337OUnz7IZSQXbk2jGsyl6 lVH1Tc2EAvWX76VEbd01mlLa53b1xW7/w5mb4IgIOuDRQLuBJFiCpF3Rpn1/Osnle88b n/fX562H88scsOpBULbzxjVeJDcU4kNM8wxQjNx1uQat89S0u/nrTUd35xMWzlAR/4sp VbKYx7Mdix7cQa3GB/dKa256lS1xmczYmXJQSrj2WkpZ/t9uw+fwl7xiY8aL7Husx0yW pGKO0d0AUDYaOiVZrpur0vebHyqWp5VfVg+DJJHFpXWWrTS0LuwPJsGSm4ZyfsqBqSTu gK7g==
X-Received: by 10.68.189.69 with SMTP id gg5mr16556132pbc.55.1446317992391; Sat, 31 Oct 2015 11:59:52 -0700 (PDT)
Received: from ?IPv6:2406:e007:5b02:1:28cc:dc4c:9703:6781? ([2406:e007:5b02:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id yh3sm15105891pbb.82.2015.10.31.11.59.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2015 11:59:51 -0700 (PDT)
To: Tore Anderson , "v6ops@ietf.org" 
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com>  <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl> <5633C030.6040202@gmail.com> <20151031094621.182c6c50@envy.fud.no>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56350FA3.4060105@gmail.com>
Date: Sun, 1 Nov 2015 07:59:47 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151031094621.182c6c50@envy.fud.no>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Oct 2015 18:59:54 -0000

On 31/10/2015 21:46, Tore Anderson wrote:
> * Brian E Carpenter
> 
>> On 31/10/2015 04:24, Sander Steffann wrote:
>>
>>> I always understood this bit from RFC 3633 to mean that any host
>>> configuration flags (such as M/O) are not relevant to DHCPv6-PD:
>>> "Note that this use of DHCP is not bound to the assignment of IP
>>> addresses or other configuration information to hosts".	
>>
>> The phrase "is not bound to" is rather unclear, don't you think? It
>> neither says nor implies that routers are thereby exempt from issuing
>> correct RAs.
> 
> Agreed.
> 
> Also, note that RFC 3633 did *not* update RFCs 2461/2462, which at the
> time defined the meaning of the O/M flags to be essentially the same as
> what RFC 4861 defines them to be today.
> 
>> Even if you accept that, in the case that you *don't* know that such
>> information is available, you physically cannot set the M or O flag.
>> So in the real world, a node that is interested in IA_PD had better
>> go fishing for it, whatever the MO bits say. So I retract all the if
>> statements in the pseudocode that I sent. The only robust
>> implementation is one that always looks for DHCPv6 information.
> 
> That might indeed be the case - but it's not what the standards are
> currently telling the implementers to do. Furthermore, accepting this
> would mean that the M/O flags are essentially pointless. In that case,
> deprecating the flags would be the logical thing to do.

I know. It's a bit depressing.

> (You explicitly called out IA_PD, but as your argument applies equally
> well to any other DHCPv6 option I'm going to assume you meant IA_PD
> just as an example.)

Yes, although it's the example that led to this thread.

  Brian


From nobody Sat Oct 31 14:01:04 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF01B2EB0 for ; Sat, 31 Oct 2015 14:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level: 
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BGZeYjQjnrQ for ; Sat, 31 Oct 2015 14:01:01 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393691B2EAF for ; Sat, 31 Oct 2015 14:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1569; q=dns/txt; s=iport; t=1446325261; x=1447534861; h=from:to:subject:date:message-id:mime-version; bh=gPwMuMeJVMs+cqjGBg3AtVb6lqjwiyVWK2D7SK7FP2I=; b=RIzLv4bw42zn7XCFu3DAnIiOUuZilXXEhgKebUyfedLLYEpzLZowPmOI jdqviBfdLdtc0DZqKqWXOnllp396XAfpQEoYytZorlCpE0XEY6Fcgh42N KN0MYL2WYvpL+PVL1Q7lKLlzHnTyPIXx8LSBKEJXflncdWDDFkGS6Kmxk o=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DFAgBhKzVW/4oNJK1egztTdb8tDoFaIYcWOBQBAQEBAQEBgQqEPIELAYEAJwQhiCINoXCgYwEBAQEBAQQBAQEBAQEBARIFBIkHixqBFAWWQwGCUYFhiHKcOQEfAUOEBIVpgQcBAQE
X-IronPort-AV: E=Sophos;i="5.20,225,1444694400";  d="asc'?scan'208";a="46320291"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2015 21:01:00 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9VL10Ym005939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 31 Oct 2015 21:01:00 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 31 Oct 2015 17:00:59 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Sat, 31 Oct 2015 17:00:59 -0400
From: "Fred Baker (fred)" 
To: "v6ops@ietf.org WG" 
Thread-Topic: v6ops administrivia
Thread-Index: AQHRFB8+wyOjKgOjEk+I6WPZABJVzg==
Date: Sat, 31 Oct 2015 21:00:59 +0000
Message-ID: <6D50AF80-9C17-4B48-B76D-BA9DF842146D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.70.230.103]
Content-Type: multipart/signed; boundary="Apple-Mail=_35C90C04-DA61-4C0F-88F8-C540D5BC3C8C"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Subject: [v6ops] v6ops administrivia
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Oct 2015 21:01:03 -0000

--Apple-Mail=_35C90C04-DA61-4C0F-88F8-C540D5BC3C8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

https://www.ietf.org/proceedings/94/agenda/agenda-94-v6ops

I'm still looking for slides from seven of the eight drafts. I need =
those today to post as "meeting materials".

I'm also looking for note-takers and a jabber scribe (or two)

--Apple-Mail=_35C90C04-DA61-4C0F-88F8-C540D5BC3C8C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBVjUsC0ayAOS/EQ8MAQItMA/7BJ+zpuLPf0rXPYhfnoq4a2ZWCim0o4/d
IIej6S5KO7dfmFBAxgS54HJSiIUCQVKd9Qw57cmkXGSgrfYghcXgrWY2b2wgLsCe
NWAQ/GwHDE9PLrHGSz59mfAqyvSom5yqGQNpJsR2Rg1Y6iVpg17iAJrK/JcVghiU
KFcxC59HKr+aDBrwjTe29zC53pPlOxNkA+k5UGT2qYYazPcyYyyYNRMGLiDbxGtI
LD5KGdf+r8ejR5UNg6+VaxmLF5QaraaFUPpHALeqlw/WQUmQYu8lDcaVibjSk00c
TuAUl7UHXUR7GAA2Mqk3oY211f/mDKYEML1ceJHHYE3sWhW0YezzE6Uzyq4ONMZq
L0Nw+IwpHTpNpEC04U59kSiKF5O46H3zyuTxqU+iodjHJPpZLL9jOAkekXj5YUph
TRrRw9V1gNH/PpssQgdcz30+Tm1dWzV+ILS/w6mSL4W+wzV0lf9hwUGQsndErEFX
+K8mTrAwmbVWVZIsycwHpf52LthczIgc3GVVL6nzrbCOMcPm20MjrlQC9eIJjd09
087pNm5MMmMebZTj4/sYvNnQd4r18ogL5deBDjz2DTjrvOgmYU1sRFYzfaTSneZa
+qO1TkBwTmHsKkzzoPbnpdzuRNuEIyNFq/eXu83xFCOODCW4DR0CqtVqDCYwklpa
2R9mwacD2ZE=
=GwZ3
-----END PGP SIGNATURE-----

--Apple-Mail=_35C90C04-DA61-4C0F-88F8-C540D5BC3C8C--


From nobody Sat Oct 31 20:28:45 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1097A1B3368 for ; Sat, 31 Oct 2015 20:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkO7WagRHgct for ; Sat, 31 Oct 2015 20:28:42 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id CCBBD1B335C for ; Sat, 31 Oct 2015 20:28:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C5F2D1E59F6 for ; Sat, 31 Oct 2015 20:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMlCh_5vNAco for ; Sat, 31 Oct 2015 20:28:06 -0700 (PDT)
Received: from t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp (t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:89c1:b291:c06d:a7b2]) by c8a.amsl.com (Postfix) with ESMTPA id 77D9C1E59F2 for ; Sat, 31 Oct 2015 20:28:06 -0700 (PDT)
From: Alexa Morris 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Sat, 31 Oct 2015 20:28:39 -0700
Message-Id: 
To: v6ops@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Sendlaterdate: Sat, 31 Oct 2015 20:28:39 -0700
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [v6ops] Virtual Queue for V6OPS Remote Attendees
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 01 Nov 2015 03:28:44 -0000

If you are planning to participate in the v6ops session here at IETF 94 =
on Monday =97 either locally in Prague or as a remote participant =97 we =
want to make sure that you are aware that the IETF is providing a remote =
participants with a fairly new way to ask questions or make comments. In =
addition to using the Jabber room, for the v6ops session there is also =
the opportunity for remote participants to enter a virtual queue and ask =
questions directly into the meeting room.=20

This experimental queue was used in several sessions at IETF 92 and IETF =
93, so you may have already seen it in action. There will be two queues =
for the v6ops session =97 a virtual queue and an actual (in-room) queue. =
Remote attendees will log into the Meetecho platform and will have a =
virtual mic line that they can enter if they have a question or comment. =
In-room participants will continue to use normal mic lines.=20

Instructions for remote participants are at =
http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20

Information on how to join the Meetecho session is at =
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) =
by performing a self-test here: =
http://ietf94.conf.meetecho.com/index.php/Self_Test.=20

Regards,
Alexa

----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amorris@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com