From nobody Sun Nov 1 08:07:05 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 3619A1B87FE; Sun, 1 Nov 2015 08:07:02 -0800 (PST) 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.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 08:07:02 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Sun, 01 Nov 2015 16:07:02 -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 : Host address availability recommendations Authors : Lorenzo Colitti Vint Cerf Stuart Cheshire David Schinazi Filename : draft-ietf-v6ops-host-addr-availability-02.txt Pages : 13 Date : 2015-11-01 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-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 Sun Nov 1 14:01: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 942341AC3C4 for ; Sun, 1 Nov 2015 14:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NZem_-Sdn5Hu for ; Sun, 1 Nov 2015 14:01:33 -0800 (PST) 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 8F9E51AC3C1 for ; Sun, 1 Nov 2015 14:01:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tA1M1UxV020550 for ; Sun, 1 Nov 2015 22:01:30 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk tA1M1UxV020550 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1446415291; bh=ajGVmqmGr6YWGOnG5tfmnuQcNsQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=OJHvihPpeiRqRUfsd4IZ0wuo2N2lOD6icQq4mbPNR/tyTj2WzfMHmzDd34ULSBsse m/Z6MMKnXDPGGPReVFdFTui7ZaQdm77gFcUk9C+HdShGYgG53CeDQbUDcCBE2cpO5z tOguTEsUzfCjCo9AYYRPsSEp3dgzNpgs8WqQ5Z84= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id rA0M1U1860229185vm ret-id none; Sun, 01 Nov 2015 22:01:30 +0000 Received: from [192.168.0.10] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tA1M1QFM008060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Nov 2015 22:01:26 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Tim Chown In-Reply-To: <56340C02.7040505@go6.si> Date: Sun, 1 Nov 2015 22:01:25 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <56340C02.7040505@go6.si> To: v6ops list X-Mailer: Apple Mail (2.3096.5) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=rA0M1U186022918500; tid=rA0M1U1860229185vm; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: tA1M1UxV020550 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [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: Sun, 01 Nov 2015 22:01:36 -0000 Hi, I also put my hand up alongside Jan to take a look at the -09 version = when it came out. Overall, I think the document is pretty close to being ready. It = contains a lot of useful information and guidance. Indeed, while = Informational, some parts are clearly documenting BCP. It=E2=80=99s = certainly worth publishing. Some comments: The title of the document might now better be =E2=80=9CRouting-Related = Design Choices for IPv6 Networks=E2=80=9D? The introduction defines the scope of the document well, and gives = useful pointers to topics not covered in the text. There is an exception to this though - the introduction says ULAs (and = address plans) are covered elsewhere (ULAs specifically in Sheng=E2=80=99s= draft) but then dives into ULAs anyway. There=E2=80=99s some mixing = here of "IPv4 thinking", e.g. =E2=80=9Cfor an enterprise, the use of = private address space is an option and may be seen as favourable = operationally=E2=80=9D, which may be the case in existing IPv4 networks, = but for IPv6, if PI/PA is not recommended, or ULAs alongside PI/PA, = there should be very clear guidance why not, and perhaps that is better = handled in Sheng=E2=80=99s draft. We also danced around this topic in = RFC 7381, but ended up punting to Sheng=E2=80=99s document. Perhaps the = same should be done here? I also found the PI/PA/Private table confusing. Perhaps it should come = after the text explaining it? Even then, it might be formulated better. The discussion of IGPs, and the hint of the result of an informal poll = on IGPs, was interesting and useful. The summary of the general themes at the end might be better placed in = the introduction, to put them in the reader=E2=80=99s mind for the = subsequent text? Tim > On 31 Oct 2015, at 00:32, Jan Zorz wrote: >=20 > Dear WG, authors... >=20 > 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 ;) >=20 > 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. >=20 > Section 2.2.1: >=20 > 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. >=20 > Section 2.2.2: >=20 > 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 ;) >=20 > End hosts also have interface and should not even think about that ;) >=20 > Page 11: >=20 > You can carry IPv4 also in OSPFv3 this days, so additional option = would be OSPFv3/OSPFv3 >=20 > See you all at v6ops WG meeting in few days ;) >=20 > Cheers, Jan >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Nov 1 15:15: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 BC8951B31F4 for ; Sun, 1 Nov 2015 15:15:22 -0800 (PST) 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 3r6jV41_-bLG for ; Sun, 1 Nov 2015 15:15:21 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 7D4891B31F0 for ; Sun, 1 Nov 2015 15:15:21 -0800 (PST) Received: by igbhv6 with SMTP id hv6so43650946igb.0 for ; Sun, 01 Nov 2015 15:15:21 -0800 (PST) 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=1LHoTV+bRPwL1A2B9ed+EPMdStwWQ46qKbvepcNYV2w=; b=0/FAcAcNCZfYo8mw+ZCZP7dPx8DRerPxL0zMci/BiUWte8px3JfhkDZTT72CB10cni St83n0sAey3WOjLZR23ljwR6qzl72hdAL04Au6BRf2wVHYlU2uZ6C7oq4AIKhjlViJmC iRSCWX6AKIx6dbGOVoW0EoOnTafRcgxv7OmT+3dlpxKd55q2C9C9b5ynwiIbokteRbxk 6UUl4OZ/dofOe3/X3TtZAOJlOBVECGwQnfDwXRTEmgJIfLMP9ZW821j2IcL6tBmfTV8E K1Ta9Dts6Dxec8PQ0CMRZhI5qFgmHOzcj9Fv+AQq8o53mF/nGCt4NmfRSbT7mwGzujNk mv2g== MIME-Version: 1.0 X-Received: by 10.50.70.1 with SMTP id i1mr8881661igu.78.1446419720961; Sun, 01 Nov 2015 15:15:20 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.71 with HTTP; Sun, 1 Nov 2015 15:15:20 -0800 (PST) Date: Mon, 2 Nov 2015 08:15:20 +0900 X-Google-Sender-Auth: seyc-V3zdIy7wXZA2aTlEIDJN5I Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] comments on draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 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 23:15:22 -0000 I have a couple of minor comments on draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 - Section 4.2 [...] Since the address is composed by the UE/subscriber device itself it will need to verify that the address is unique on the shared network. "Since the address is composed by the UE/subscriber device itself" sounds like suggesting that you don't have to verify the uniqueness if the address is assigned via DHCPv6. Is that the intent? If so, this is not really correct per Section 5.4 of RFC4862. - Section 5 In an environment using DHCPv6 IA_NA for IPv6 address assignment this is achieved by having the AP insert an interface-id RFC3315 [RFC3315] in the UE/subscriber DHCPv6 Solicit message. Is this some new protocol extension proposed by this document? As far as I know the Interface-id option is basically only expected to appear in Relay-forward and Reply-reply (but not Solicit) messages, even if RFC3315 may not explicitly prohibit other messages from including it. Besides, I don't understand what "the AP insert" means...does this mean the AP modifies the Solicit sent by the client as a middlebox? That would be a quite controversial behavior, and I think the document should at least clarify that point explicitly; or, if this is intended to say something else, it should probably explain it in more detail as at least I didn't get it. -- JINMEI, Tatuya From nobody Sun Nov 1 16:17: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 7727F1B3CFF for ; Sun, 1 Nov 2015 16:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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_SE=0.35, 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 4GvZkJQDSF8W for ; Sun, 1 Nov 2015 16:16:59 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60E21B3CFD for ; Sun, 1 Nov 2015 16:16:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B7C2EA2; Mon, 2 Nov 2015 01:16:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1446423416; bh=+5eDjUjgdjbQXmwjp5BByHYzPWW56NhoZRBlQaQS4rg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=qi4+ExG1zuZmwfgx6zgudl/VAa6qrpRpryhGpSf935NQX5S5twur+7E2yjKEwcEnX 0iRveMFYf1Hs0v2sYogcyrH466x+uuICgwSlZDsbTn4NafPOBMEabePf5b0WOS2Pcr YCUpl275mQRJelsO8SBmB66BDe3YVbnT7XYKzmz8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B367CA1 for ; Mon, 2 Nov 2015 01:16:56 +0100 (CET) Date: Mon, 2 Nov 2015 01:16:56 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> Message-ID: References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 00:17:00 -0000 I see there have been changes to replace "smaller" prefix size. Personally I don't like "shorter" and "longer", it's not intuitive which is which (compare using -gt and -le in prefix filter lists). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Nov 1 16:32: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 3EC1C1B3D7F for ; Sun, 1 Nov 2015 16:31:59 -0800 (PST) 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 W9rsnbpnoLsd for ; Sun, 1 Nov 2015 16:31:58 -0800 (PST) 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 373B01B3D58 for ; Sun, 1 Nov 2015 16:31:58 -0800 (PST) Received: by padec8 with SMTP id ec8so20222890pad.1 for ; Sun, 01 Nov 2015 16:31:57 -0800 (PST) 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=BQHoEOfPQXewWNTmocEAHSv0vat8dButVTucpjeXvPs=; b=Td9g8e8M9SO1XN7aVn05vla7vxWjJACEoGk6gvFjPEpVqhDstLXjJx/29D0LRmfErc qoZ2M0jwm4RbIJ4JaBZxJV4UL6V/oxJ40N35Kxdqj4unxiXdVes+tDcNVoUCGJv7C3ar UEMr9iSyVuEzcVb1MjpYNHhz0oOEnIaIAbuj++stXEiofuRvbMsWVC74ytCX9yKkds0m QFcDRlMnDuKeKGw/irgNWLmjXj5WtiRqTAztp5nIe9DyonPzS3+JOs8E2Fv4gnlaIw2O NcJJXPMyl+cWKMlYPiG3HV5FMYyP/gnjsYr3BXH+rrpoHS89jgk5+Ybqv5vjJTUP01xI c1dQ== X-Received: by 10.68.65.42 with SMTP id u10mr23618452pbs.8.1446424317764; Sun, 01 Nov 2015 16:31:57 -0800 (PST) Received: from ?IPv6:2406:e007:5d6d:1:28cc:dc4c:9703:6781? ([2406:e007:5d6d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id pn8sm20425001pbb.16.2015.11.01.16.31.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 16:31:56 -0800 (PST) To: Mikael Abrahamsson , v6ops@ietf.org References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5636AEF9.7010200@gmail.com> Date: Mon, 2 Nov 2015 13:31:53 +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] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 00:31:59 -0000 On 02/11/2015 13:16, Mikael Abrahamsson wrote: > > I see there have been changes to replace "smaller" prefix size. Personally I don't like "shorter" and "longer", it's not > intuitive which is which (compare using -gt and -le in prefix filter lists). > "Smaller" is completely ambiguous - does it means smaller prefix or smaller address block? Brian From nobody Sun Nov 1 17:03: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 D11201A1AB9 for ; Sun, 1 Nov 2015 17:03:30 -0800 (PST) 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 4-xMno-lrcCY for ; Sun, 1 Nov 2015 17:03:29 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A061A1B1F for ; Sun, 1 Nov 2015 17:03:23 -0800 (PST) Received: by ioll68 with SMTP id l68so130584107iol.3 for ; Sun, 01 Nov 2015 17:03:22 -0800 (PST) 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=sYWhFlnvn9Ekdv+1gHNAucZ+btXV9SkxsPnFTzSsizY=; b=d/m5WqicZ71VQ2kSRJwYph/eTxgjV13TZuFYPT9hcsZW9G+rjPxl3pF5hIOxWLYjqK Q7YPugjQkwJzz0CT8xQJmtf+ygf27s+2XHNx4oUAO+yhoVjcggJIEOtttInw+/OHcJa5 j4RmTEKLs7wEnQwt5XJsbjDNeZ2WIIJCitETNj7Oerwu7KXOPXQCqskHR9EqbNNNTPKp ZhzXsWKMhXC5i7lFq85n/neN8XRFZ8ADqCyI2AiY+UzC89zJsLCnpFl6YDlfLZHQhYtS xLFjSKZzrFk1I4cSu9FgKE4qGwtqkHdSUXXrL6cXFnqY5O4I7vMTWyX5X5OEXuwCSFj2 17Ug== MIME-Version: 1.0 X-Received: by 10.107.159.72 with SMTP id i69mr23438845ioe.4.1446426202597; Sun, 01 Nov 2015 17:03:22 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.71 with HTTP; Sun, 1 Nov 2015 17:03:22 -0800 (PST) In-Reply-To: <5636AEF9.7010200@gmail.com> References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> Date: Mon, 2 Nov 2015 10:03:22 +0900 X-Google-Sender-Auth: j_SHad5KUxddbzEfw0LbkMAR6pY Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 01:03:31 -0000 On Mon, Nov 2, 2015 at 9:31 AM, Brian E Carpenter wrote: >> >> I see there have been changes to replace "smaller" prefix size. Personally I don't like "shorter" and "longer", it's not >> intuitive which is which (compare using -gt and -le in prefix filter lists). >> > > "Smaller" is completely ambiguous - does it means smaller prefix or smaller address block? At the time of the WGLC I proposed the following text: Assigning prefixes with the length larger than 64 will limit... (https://www.ietf.org/mail-archive/web/v6ops/current/msg22862.html) This may sound too verbose but shouldn't have any ambiguity. -- JINMEI, Tatuya From nobody Sun Nov 1 17:08: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 709DA1ACD47 for ; Sun, 1 Nov 2015 17:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XebOWPgPujoM for ; Sun, 1 Nov 2015 17:08:29 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4832D1ACD4E for ; Sun, 1 Nov 2015 17:08:28 -0800 (PST) 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 0F5101FCAB9; Mon, 2 Nov 2015 01:08:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AB62B160046; Mon, 2 Nov 2015 01:08:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 99173160097; Mon, 2 Nov 2015 01:08:59 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VIemQVzxCYqW; Mon, 2 Nov 2015 01:08:59 +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 5656C160046; Mon, 2 Nov 2015 01:08:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A4B183BA1F08; Mon, 2 Nov 2015 12:08:21 +1100 (EST) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= From: Mark Andrews References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> In-reply-to: Your message of "Mon, 02 Nov 2015 10:03:22 +0900." Date: Mon, 02 Nov 2015 12:08:21 +1100 Message-Id: <20151102010821.A4B183BA1F08@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 01:08:30 -0000 longer/shorter is unambigious as it describes the length. larger/smaller can be a length or volume (a address count). Mark In message , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > On Mon, Nov 2, 2015 at 9:31 AM, Brian E Carpenter > wrote: > > >> > >> I see there have been changes to replace "smaller" prefix size. Personally > I don't like "shorter" and "longer", it's not > >> intuitive which is which (compare using -gt and -le in prefix filter lists > ). > >> > > > > "Smaller" is completely ambiguous - does it means smaller prefix or smaller > address block? > > At the time of the WGLC I proposed the following text: > > Assigning prefixes with the length larger than 64 will limit... > > (https://www.ietf.org/mail-archive/web/v6ops/current/msg22862.html) > > This may sound too verbose but shouldn't have any ambiguity. > > -- > JINMEI, Tatuya > > _______________________________________________ > 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 Sun Nov 1 17:12: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 009F61ACDC4 for ; Sun, 1 Nov 2015 17:12:06 -0800 (PST) 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 zwmj3eTG3gx6 for ; Sun, 1 Nov 2015 17:12:05 -0800 (PST) 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 EC2DB1ACDB2 for ; Sun, 1 Nov 2015 17:12:04 -0800 (PST) Received: by vkgs66 with SMTP id s66so76739361vkg.1 for ; Sun, 01 Nov 2015 17:12:04 -0800 (PST) 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=OpgohLoayhaT5ElwYxeZh0ndgCAQl74Yde1QbrnQeGU=; b=fmiuSjpCpcSIYJzgqHO5x+Xy2giA+f23fjPIYGkPVTyzyxdhoS26uQN/VH87gwjl8e 7YoTM+aMwqFHNGM0DPYjtmBfrefZtiZ09A1wFxI+EfTTIazif8pNiNuxC+L0XL8aqWnx r6Klis2qfQLdbibaiLbmf11kIr06aXqqdRv1VK5Q5zlVNH7SOmMeOeNieqmzbDy9vua3 mNuhceDRoWeHTFiZ+TGirWvllBggy5fEcsBdVijqLb2/V0QPpirCOKERIUbrCAkjrMbK 6kq3yNul6wJolsQeyRB5po5WBQ9E3oWVYli7lwirbXZvom0rqLABdAisGg+bq31c+u2o Z6tA== X-Received: by 10.31.41.133 with SMTP id p127mr13726347vkp.132.1446426724158; Sun, 01 Nov 2015 17:12:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.67.194 with HTTP; Sun, 1 Nov 2015 17:11:34 -0800 (PST) In-Reply-To: <5636AEF9.7010200@gmail.com> References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> From: Mark Smith Date: Mon, 2 Nov 2015 12:11:34 +1100 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 01:12:06 -0000 On 2 November 2015 at 11:31, Brian E Carpenter wrote: > On 02/11/2015 13:16, Mikael Abrahamsson wrote: >> >> I see there have been changes to replace "smaller" prefix size. Personally I don't like "shorter" and "longer", it's not >> intuitive which is which (compare using -gt and -le in prefix filter lists). >> > > "Smaller" is completely ambiguous - does it means smaller prefix or smaller address block? > So (as an English first language speaker), I interpret "smaller" and "larger" to be describing an unordered quantity in most cases, where as I interpret "shorter" and "longer" to be describing a measure in most cases. The exceptions are when there is other context that indicates alternative use. Therefore my expectation is that "smaller" and "larger" would be used to describe the number of addresses in a prefix, where as "shorter" or "longer" would be describing the length or measure of the prefix. I agree with making sure to avoiding ambiguity, I know on occasion it hasn't been clear to me whether somebody is describing a prefix with a smaller number of addresses, or a shorter prefix length, which obviously mean the complete opposites in terms of number of addresses within the prefix, when they use "smaller prefix". Regards, Mark. From nobody Sun Nov 1 17:18: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 43A501B3F65 for ; Sun, 1 Nov 2015 17:18:08 -0800 (PST) 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 BsyulZABq8LK for ; Sun, 1 Nov 2015 17:18:07 -0800 (PST) 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 2E5F51B3F60 for ; Sun, 1 Nov 2015 17:18:07 -0800 (PST) Received: by pacfv9 with SMTP id fv9so135933249pac.3 for ; Sun, 01 Nov 2015 17:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=f0MXuIudWRjxZonp52WGAyrcfspmZRHCdHtOgD63x7Y=; b=yuqnLXkZZZQPnAviO2PL/pOAN4bndiO8kebKDZMRanKVvVeWQ6Vzg6qdo8gyjtXy9H 9VXmCXygVG5+PPezO3BtyM4mW1FwVwGevBEN8n+XeStXm8s6TC5vsokzeLdx8ZjW58cx YAazSPHmgf0uHln8VxcpGN+bab4SQnCNlC+AciY7itfW3eAknqhl5ij/Qi87wpfAXtUS XvNi02mg4FKMuXFeZT4+GBCV/Oj5AzTUTSvHTadHSbalfvG2Tbl9/NNCy4n19S1R+EzF NQKZbxMy3gvVVX66n3OHZqiXCryVY1A202XD694GQsYXbENqdOx77AkTRBXbCvRtaaiO WCwQ== X-Received: by 10.68.68.205 with SMTP id y13mr23943587pbt.46.1446427086900; Sun, 01 Nov 2015 17:18:06 -0800 (PST) Received: from dhcp-24-227.meeting.ietf94.jp ([133.93.24.227]) by smtp.gmail.com with ESMTPSA id bz2sm20557909pad.32.2015.11.01.17.18.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:18:06 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <824F2230-A92F-4587-81DD-9EE3418558B9@gmail.com> Date: Sun, 1 Nov 2015 20:18:03 -0500 To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability-01 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, 02 Nov 2015 01:18:08 -0000 I support this I-D almost as-is (for the -01 version),=20 provided only that the clarifying editorial edit from=20 Lorenzo=E2=80=99s WG slides presented today is made to the I-D=20 before the document leaves this WG for IETF Last Call. Yours, Ran= From nobody Sun Nov 1 17:29: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 3B3331ACDE7 for ; Sun, 1 Nov 2015 17:28:59 -0800 (PST) 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 6R0oHo_Ejsxp for ; Sun, 1 Nov 2015 17:28:58 -0800 (PST) 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 403021ACDE5 for ; Sun, 1 Nov 2015 17:28:58 -0800 (PST) Received: by pabfh17 with SMTP id fh17so6676875pab.0 for ; Sun, 01 Nov 2015 17:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=S19FPBjPxX0l4nYUK2neU9bxkqx0s3mI9xeCqszdsus=; b=PcCn+wnQtorENmV2KnMeFB0WapZWLnbAr7vDqhP0RLimdHLrNR0HLEpCK6Ezpd72TP 1dl7KAyxpXF5mSqV50agSYnmZvKoPQSUqH6XxNvUzyN21i7Ms2B22MtSVkdZv23LLaK/ jnDSXgV3P9n6xRK0OVYgpTVka2p+zFanOYvaPZ0xzghuEstc6gwb4tXNUC6c7n127E4K +lpS9lEpveNhafnxdAghz0IogELWvmx62jAkieCfsdBvSVTqfPXBaUNILcQsB25ZHNgp vjrbw/25K/2tplvr03nvgOhh/sTkIFeUQmQEAESMKxHUnEhNG5cHUrHIZuM2eSB6LKO8 D0mA== X-Received: by 10.68.57.197 with SMTP id k5mr23701609pbq.142.1446427738016; Sun, 01 Nov 2015 17:28:58 -0800 (PST) Received: from dhcp-24-227.meeting.ietf94.jp ([133.93.24.227]) by smtp.gmail.com with ESMTPSA id mk5sm20593814pab.44.2015.11.01.17.28.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:28:57 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <9083C9A5-9CE9-4935-BA7E-802B870FEC21@gmail.com> Date: Sun, 1 Nov 2015 20:28:55 -0500 To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability-02 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, 02 Nov 2015 01:28:59 -0000 I support moving this version of the I-D forward to IETF Last Call as-is. Ran From nobody Sun Nov 1 17:57: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 2FB8A1B4137 for ; Sun, 1 Nov 2015 17:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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_SE=0.35, 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 MB2JNMabVHie for ; Sun, 1 Nov 2015 17:57:29 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239141B412E for ; Sun, 1 Nov 2015 17:57:29 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 98F49A2; Mon, 2 Nov 2015 02:57:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1446429446; bh=eiOqq2h4rQ9K6DXAWlKK+qL9ejj9+oEDZmDS1De5WKk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=OBfgYoH1JXVmfau1LhYOWwcJx/r+4edg64oiVB9WQyPLekmT8MgRO8+otKuntuRl6 OwBica5PyIDfH609VB2u5NNz3Nf9Agn3H02PxBZHLDPCK3b6lYG0EUTogSogAJ1RoE xF+bpe3+AAPfw37gHaDm/Wkw/S/uvawGdjINriDU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 910ACA1; Mon, 2 Nov 2015 02:57:26 +0100 (CET) Date: Mon, 2 Nov 2015 02:57:26 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 01:57:31 -0000 On Mon, 2 Nov 2015, Mark Smith wrote: > I agree with making sure to avoiding ambiguity, I know on occasion it > hasn't been clear to me whether somebody is describing a prefix with a > smaller number of addresses, or a shorter prefix length, which obviously > mean the complete opposites in terms of number of addresses within the > prefix, when they use "smaller prefix". What about "smaller/larger sized prefix"? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Nov 1 18:03: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 D5C531B418E for ; Sun, 1 Nov 2015 18:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk6Su7SaEHZU for ; Sun, 1 Nov 2015 18:03:02 -0800 (PST) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f: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 A90441B418D for ; Sun, 1 Nov 2015 18:03:02 -0800 (PST) Received: from equinox by eidolon.nox.tf with local (Exim 4.85) (envelope-from ) id 1Zt4SZ-003tgC-AG for v6ops@ietf.org; Mon, 02 Nov 2015 03:02:59 +0100 Date: Mon, 2 Nov 2015 03:02:59 +0100 From: David Lamparter To: v6ops@ietf.org Message-ID: <20151102020259.GB56957@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [v6ops] v6ops-design-choices, SADR, draft-ietf-rtgwg-dst-src-routing-00 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, 02 Nov 2015 02:03:05 -0000 In relation to the short SADR intermezzo in the v6ops room a few minutes ago, I'm happy to contradict Fred in that one of the drafts has in fact been a WG document for 2 weeks now - Yay! Nonetheless I fully agree Fred should send that e-mail :) I also think this does not imply any changes for draft-ietf-v6ops-design-choices, because indeed you can't currently buy this, especially not in a format suitable for a medium-sized enterprise. -David (Truth in advertising, again: I'm an author on some bits on this topic.) ----- Forwarded message from internet-drafts@ietf.org ----- Subject: I-D Action: draft-ietf-rtgwg-dst-src-routing-00.txt Message-ID: <20151017190649.14088.61230.idtracker@ietfa.amsl.com> Date: Sat, 17 Oct 2015 12:06:49 -0700 Cc: rtgwg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Destination/Source Routing Author : David Lamparter Filename : draft-ietf-rtgwg-dst-src-routing-00.txt Pages : 8 Date : 2015-10-16 Abstract: This note specifies using packets' source addresses in route lookups as additional qualifier to be used in route lookup. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. From nobody Sun Nov 1 18:03: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 96CB41B419A for ; Sun, 1 Nov 2015 18:03:48 -0800 (PST) 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 h3XbH5I5Wn79 for ; Sun, 1 Nov 2015 18:03:47 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386631B419B for ; Sun, 1 Nov 2015 18:03:47 -0800 (PST) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D5D75DA0088; Mon, 2 Nov 2015 02:03:46 +0000 (UTC) Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Sun, 1 Nov 2015 18:03:46 -0800 From: Ted Lemon To: Mikael Abrahamsson , Mark Smith Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-02.txt Thread-Index: AQHRFQPSu9XvXlgMgEugKaV9N20uqZ6IZ9KAgAALFgCAAAzRAP//eyCI Date: Mon, 2 Nov 2015 02:03:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A01BF4@mbx-03.WIN.NOMINUM.COM> References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [133.93.36.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 02:03:48 -0000 > What about "smaller/larger sized prefix"? I am a bit puzzled about this controversy. The term of art, as I have und= erstood it in the past, is "shorter prefix" and "longer prefix." I don't = know why you'd want to use smaller/larger. But the authors should just pi= ck something and explain what they mean. If they want to use "smaller/lar= ger," they should say "a smaller prefix is a prefix with fewer significant = bits of prefix."= From nobody Sun Nov 1 20:11: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 95A281B4454 for ; Sun, 1 Nov 2015 20:11:46 -0800 (PST) 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 uvs0wD76zkmx for ; Sun, 1 Nov 2015 20:11:45 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F3C1B4453 for ; Sun, 1 Nov 2015 20:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1446437501; x=2310351101; 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=rQwQjVLVd4Israo9OQvShDA9PNTqe49PI0AP2p3/Wzk=; b=W9lHTaJnUioLmpBXSPrak/zBMRL38c4xi/703k48ECiZanChKKEo2gTPkKP4pr0H Avhn8x6F/DrwvOjuLFr5ypHV8aE9ZGGW3fFI3r186QKO3hw1HF+naz1U7LrV51Ax OWo0+7DCC3MB0RunqUe7NA1pOl9h59ikrwEd25mX0qErgnUxP7ucJbwTersFvEQ7 d8k9eDOHwczkFXCuDFDTdnAbsCYiSFMA1T4RcBQuhakecU6NwKJd4QycsU7KobJz SgGQKOLAM2lOJlqWVX9v65FLNozvRFFbLitkpEtFgC4bPpiBgWoWteYNYMy54dk5 oUvCL5MPlvxTc+cpPA+uAg==; Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id EC.C4.21918.D72E6365; Mon, 2 Nov 2015 12:11:41 +0800 (MYT) X-AuditID: 1152fe06-f79046d00000559e-a6-5636e27dbe8f Received: from sng-mailphp-s01 ( [17.84.76.247]) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id F7.19.10755.D72E6365; Mon, 2 Nov 2015 12:11:41 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_p7VVeMWO6CMP0CC1MaoQrQ)" Received: from dhcp-24-201.meeting.ietf94.jp ([133.93.24.201]) by phonehome.asia.apple.com (Oracle Communications Messaging Server 7.0.5.34.0 64bit (built Oct 14 2014)) with ESMTPSA id <0NX600CHX6BFPW00@phonehome.asia.apple.com> for v6ops@ietf.org; Mon, 02 Nov 2015 12:11:41 +0800 (SGT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <824F2230-A92F-4587-81DD-9EE3418558B9@gmail.com> Date: Mon, 02 Nov 2015 13:11:39 +0900 Message-id: References: <824F2230-A92F-4587-81DD-9EE3418558B9@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.3096.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUiGHRCULf2kVmYwcTdIhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqveR+wFx8Urpi8qa2B8JtLFyMkhIWAisXDPfCYIW0ziwr31 bF2MXBxCArsZJdY9mMbcxcgBVnT/ijpIjZDAGkaJAztLQGxeAUGJH5PvsYDYzAJhEg19S9kh epcxSTy59ZQVJCEsIC3RdeEuK8gcYQF7iQvrc0BMNgEtiQNrjEAqOAVsJZYebQIbwyKgKnGu ZSsrxEghicXXvjNCrLKReNM/kQniBBuJlpUL2EDGiADVzz8nAHG9vMTPlQ1Qn8xhk2iZWzKB UXgWkkNnITl0FlA3s4C6xJQpuRBhbYkn7y6wQthqEgt/L2JCFl/AyLaKUTw3MTNHNzPPSC+x ODNRL7GgICdVLzk/dxMjOBr+se1gXPDa8BCjAAejEg/vivtmYUKsiWXFlbmHGCU4mJVEeL1u AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzGtcahQkJpCeWpGanphakFsFkmTg4pRoYN3S8z/Uq OXCGR35NiKdL0Zm7DN5sb1Pn9ugfbfpuJjkra3ps4fVjh4/a9ihHz9Jd910g1KztkvfCgikL XHTf63S9PJS5vq/o32MFq58XLXPvsiyNz8z8yJLEvtnlubff5x8Gjz9Par2Wmf+1aAGXVNq6 0BWzA0399ZJzlBkZTvl8+OKoJ5SvxFKckWioxVxUnAgA80ac6oICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUiGOLzXbf2kVmYwe02IYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr41XvI/aC4+IV0xeVNTA+E+li5OCQEDCRuH9FvYuRE8gUk7hw bz0biC0ksIZR4sDOEhCbV0BQ4sfkeywgNrNAmERD31L2LkYuoJplTBJPbj1lBUkIC0hLdF24 ywoyU1jAXuLC+hwQk01AS+LAGiOQCk4BW4mlR5vAxrAIqEqca9nKCjFSSGLxte+MEKtsJN70 T2SCOMFGomXlAjaQMSJA9fPPCUBcKS/xc2UD0wRGgVlIjpuF5LhZQB3MAuoSU6bkQoS1JZ68 u8AKYatJLPy9iAlZfAEj2ypG0aLUnMRKY73E4sxEvcSCgpxUveT83E2MoPANOiG4g/HDVMND jAIcjEo8vCvPmYUJsSaWFVfmHmKU4GBWEuH1ugEU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjs9 zyBMSCA9sSQ1OzW1ILUIJsvEwSnVwLi4ddo+5+uNN9s/Ry3hYl9U/vTYCyWXiXmynlp/kxPi LKZ7bHgqveXRX4/iqcm+z++d811h/M58/VrTsjTzMO9zZxKjmmzf/jz74XtJ85ze/437BCNu vZndq1ws5r5cbPPKH6xSD+s/XvtvyrW3ysSXYf7jD3ZvfvdoCOZu7r1+LjDa2/HW/RolluKM REMt5qLiRABwD9GtWwIAAA== Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability-01 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, 02 Nov 2015 04:11:46 -0000 --Boundary_(ID_p7VVeMWO6CMP0CC1MaoQrQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Ran, Thanks for the support! The edits mentioned by Lorenzo during v6ops today were added to the = draft this morning when we submitted -02. https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 = Thanks, David > On Nov 2, 2015, at 10:18 AM, RJ Atkinson wrote: >=20 >=20 > I support this I-D almost as-is (for the -01 version),=20 >=20 > provided only that the clarifying editorial edit from=20 > Lorenzo=E2=80=99s WG slides presented today is made to the I-D=20 > before the document leaves this WG for IETF Last Call. >=20 > Yours, >=20 > Ran > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_p7VVeMWO6CMP0CC1MaoQrQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Ran,

Thanks= for the support!

The edits mentioned by Lorenzo during v6ops today were added = to the draft this morning when we submitted -02.

https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availabi= lity-02

Thanks,
David


On Nov 2, 2015, at 10:18 AM, RJ = Atkinson <rja.lists@gmail.com> wrote:


I support this I-D almost as-is (for the -01 version),

provided only that the clarifying editorial = edit from
Lorenzo=E2=80=99s WG slides presented today is = made to the I-D
before the document leaves this WG for = IETF Last Call.

Yours,

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

= --Boundary_(ID_p7VVeMWO6CMP0CC1MaoQrQ)-- From nobody Sun Nov 1 20:27: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 BEA041B44E6 for ; Sun, 1 Nov 2015 20:27:50 -0800 (PST) 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 v110zicaR5sb for ; Sun, 1 Nov 2015 20:27:49 -0800 (PST) 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 B1D391B44E5 for ; Sun, 1 Nov 2015 20:27:49 -0800 (PST) Received: by vkfw189 with SMTP id w189so78322879vkf.2 for ; Sun, 01 Nov 2015 20:27:48 -0800 (PST) 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=eMaMH4aqf2Zty5UgWohGblErLYLxjFQWWePAetQDAKg=; b=TZQF8LAlkV7DpEPGaG8BFnqiNyeluZBeXxiDhvnW+kmZlMr1IYD+dg0ahIW5XWieYj GA5A47vwUhHrhtNzvMlB5TEHLlNGQfWbfQ/VFLkWUfmLVP3ltvXhDlcX+C6XPsDSCcqz j39Bhk3/kzMjCtQ9XR5bzAnOgXI/fONJL9/IyGGCvmxXXNtuZuweGn063iQrmpDb8KDO gAW/bKNjuNh0fL0WFvRXBt8PiQMkW+KUZsig96QSiVeA0p2vbOmtot62W+BDK+gM5RFj JfnHOcKQKHOVDakNeyFTVr+05sI2u7KEHOAAGbM8uwo7VNZ4EsbiAeIXoBCbtrMPIzEx U6sQ== X-Received: by 10.31.56.72 with SMTP id f69mr12635023vka.27.1446438468877; Sun, 01 Nov 2015 20:27:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.67.194 with HTTP; Sun, 1 Nov 2015 20:27:19 -0800 (PST) In-Reply-To: References: <20151101160702.19175.44949.idtracker@ietfa.amsl.com> <5636AEF9.7010200@gmail.com> From: Mark Smith Date: Mon, 2 Nov 2015 15:27:19 +1100 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 04:27:50 -0000 On 2 November 2015 at 12:57, Mikael Abrahamsson wrote: > On Mon, 2 Nov 2015, Mark Smith wrote: > >> I agree with making sure to avoiding ambiguity, I know on occasion it >> hasn't been clear to me whether somebody is describing a prefix with a >> smaller number of addresses, or a shorter prefix length, which obviously >> mean the complete opposites in terms of number of addresses within the >> prefix, when they use "smaller prefix". > > > What about "smaller/larger sized prefix"? > That would be clearer. I think the fundamental things to get right are to make clear when a number of addressing related objects (e.g., numbers of addresses for link attached hosts, or numbers of /64s in the case of prefixes being assigned to links) is being described, and when a prefix length that will contain that number of addressing related objects is being described. Regards, Mark. From nobody Sun Nov 1 21:03: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 3A1D41B459D; Sun, 1 Nov 2015 21:03:03 -0800 (PST) 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 BTanZna43sOJ; Sun, 1 Nov 2015 21:03:01 -0800 (PST) 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 41A3D1B459C; Sun, 1 Nov 2015 21:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5091; q=dns/txt; s=iport; t=1446440582; x=1447650182; h=from:to:cc:subject:date:message-id:mime-version; bh=JJWr4xTsSlDwpV66rIkxIozbGkN/hams1FtvBI1NO3I=; b=IHXnp31w6vACmO+ZAPjendBke3vn0QAtOF6Ht+VSWeL8Uoh7vzueNJzq M/zMhny1VS7Cz2QC3mavpMqQkuVJ5OF13hP2KLOu/ULcaT1xlX3jQzEtQ MPg1KIBQRuY73NU2NXy3dHkY303qGwg3i0rpsz6andm0qodidXI9vpkz2 o=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvAgDq7TZW/5pdJa1egztTdb80DoFaI4I8gzqBKTgUAQEBAQEBAYEKhDgEeRIBgQAnBAENEw2IFQ3BIQEBAQEBAQEBAQEBAQEBAQEBAQERBQSJB4cbCwYBD4NegRQFlkMBglGBYWqICJw5AR8BQ4IOIIFWhScBBxcjgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,232,1444694400"; d="asc'?scan'208";a="203394319" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 02 Nov 2015 05:03:01 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA2530Ob016726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 05:03:00 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; Mon, 2 Nov 2015 00:02:59 -0500 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; Mon, 2 Nov 2015 00:02:59 -0500 From: "Fred Baker (fred)" To: "isis-ads@tools.ietf.org" , "rtgwg-chairs@ietf.org" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , 6man Chairs <6man-chairs@tools.ietf.org>, "homenet-chairs@tools.ietf.org" Thread-Topic: PA Address Multihoming in IPv6 Thread-Index: AQHRFSu+br42M0MeV0+ZSlpi1E3FfA== Date: Mon, 2 Nov 2015 05:02:59 +0000 Message-ID: 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.235.76] Content-Type: multipart/signed; boundary="Apple-Mail=_1CCE4E31-2675-41AF-8F70-C135D85EF5C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , The IESG Subject: [v6ops] PA Address Multihoming 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: Mon, 02 Nov 2015 05:03:03 -0000 --Apple-Mail=_1CCE4E31-2675-41AF-8F70-C135D85EF5C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This email is being sent in accordance with the v6ops charter, which = calls for the working group to communicate operational issues and = requirements to working groups that are chartered to address them. The IETF's current primary recommendation for multihoming of midrange = enterprise networks - those that cannot justify the costs and overheads = of a PI address and in fact multihome - is to obtain a = provider-allocated prefix from each of their upstream networks, and = deploy a /64 out of each on each LAN in their networks. https://tools.ietf.org/html/rfc4213 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. = Nordmark, R. Gilligan. October 2005. (Format: TXT=3D58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213) This has a number of issues, not the least of which is in the back end = OSS software, which needs to now scale to a much larger number of = prefixes, handle multiple addresses in DNS for servers and perhaps = clients, resolve reverse DNS queries, and so on. It also is obviously = carrying that much more information in routing. One outcome of v6ops' discussions this morning was that PI multihoming = demonstrably works, but PA multihoming when the upstreams implement BCP = 38 filtering requires the deployment of some form of egress routing - = source/destination routing in which the traffic using a stated PA source = prefix and directed to a remote destination is routed to the provider = that allocated the prefix. The IETF currently has no such = recommendation, or consensus that it should have. However, enterprise = networks are known to delaying operational deployment of IPv6 in part = due to the complexities visited upon them and the cost of the back end = software upgrades, and this is part of that issue. Without trying to limit the options available to the working groups in = question, I'll point out that options currently on the table include the = following. There are also current open source implementations of = source/destination and source-specific routing in IS-IS, OSPFv3, and = Babel. https://datatracker.ietf.org/doc/draft-baker-ipv6-isis-dst-src-routing "IPv6 Source/Destination Routing using IS-IS", Fred Baker, David Lamparter, 2015-10-19 https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz Chroboczek, 2015-05-27 https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host "Routing packets from hosts in a multi-prefix network", Fred Baker, Brian Carpenter, 2015-10-15 https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, = Fred Baker, 2015-10-08 https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing "Destination/Source Routing", David Lamparter, 2015-10-17, https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview "Source Address Dependent Routing and Source Address Selection for = IPv6 Hosts: Problem Space Overview", Behcet Sarikaya, Mohamed Boucadair, 2015-08-17 https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-ra "IPv6 RA Option for Source Address Dependent Routing", Behcet = Sarikaya, 2015-06-08 https://datatracker.ietf.org/doc/draft-sarikaya-dhc-6man-dhcpv6-sadr "DHCPv6 Solution for Source Address Dependent Routing", Behcet = Sarikaya, 2015-05-08 https://datatracker.ietf.org/doc/draft-xu-ospf-multi-homing-ipv6 "Extending OSPFv3 to Support Multi-homing", Mingwei Xu, Shu Yang, Jianping Wu, Fred Baker, 2015-10-11, = https://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cas= es --Apple-Mail=_1CCE4E31-2675-41AF-8F70-C135D85EF5C4 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 iQIVAwUBVjbt00ayAOS/EQ8MAQLxIBAAsOInqqREN8St64S2XAr65+EyGGDIBL68 /XxoSZfzupzzGbaQAWmXa//FWMQ5nJ+nRKwjv8PWCzGuE8KEphcLylJw1LRpSFM/ ty8Tm6/JRygiWF8UUuYPn4EqSd6ODwexmU7mw6dXvtMVYkqlO8gRH2OEh5ts6Qq1 1Fgx6SL54wBLwuc0fPtO5qsbmeWZXhNHOL+yVLJV8bx/Gwc9TreEOL5q4iW/rcmo AN9zvMgYdGRQGIZGFZKlu6QtVlro9+og9pCX550+YW1G0nG3cijslqx/WERCe8gL NBhN0x2LZFHTidgmt89EyxdD67Ji9fxgm8yOnVGi2FipJUSn9octMxg5eINfhpkP FLoTz1cSqnNsW4abgTOI9nYZQMaAx/dg87J/i6/eGnUI3Eee9gREMyie/c1R95So su6RP4e60XG/qxHWpXkCQ+kdTs135Ixhg6ssnfLmC+v/bhG+6+ocv4B6hRhVWPl+ HPG678jWPLVTe4xx77QMfVos8c+PHSSvhDOWtnt0oASNCEHZwtU7mfBBN2RG8JgE 9Dhmbv6dJA8O8DUY8RcySjMQLzv6A06HSFqxyLvTbUCtY2UipmddRgvy4N7DufxK 4p+kZhg6pjJp7UC5ktwFVzz+jAIdgwNqj6cD2JRhwT7s/VT3an9TXKcN1Qc6kw55 +ryav50fEXE= =2pEZ -----END PGP SIGNATURE----- --Apple-Mail=_1CCE4E31-2675-41AF-8F70-C135D85EF5C4-- From nobody Sun Nov 1 21:15: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 451781B462B for ; Sun, 1 Nov 2015 21:15:52 -0800 (PST) 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 xD3wIrc1YC4H for ; Sun, 1 Nov 2015 21:15:50 -0800 (PST) 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 EAA1F1B44F6 for ; Sun, 1 Nov 2015 21:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2378; q=dns/txt; s=iport; t=1446441349; x=1447650949; h=from:to:subject:date:message-id:mime-version; bh=wpaFCcsZWSqDpHv1/5XQfkLFAG7GBHl8j1pm0i1+yuI=; b=FJ0l7D7al5AjtNOXyAr8VOSYmYZtrkFDWgV2mSi+/wf+lfNsZIsmRmZh o9FSSiNtkP9B/UTYycQ6N0aEDZuEoMLcQKAp8cpvb51JGF4X0DTDbzmO+ iiwoppFgUdahz8k58kID6Ila+pfa9LCU6tC7fUMZFb9XzDkD+GJ1NOexf s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtAgD58DZW/40NJK1UCoM7gUi/NA6BWodDOBQBAQEBAQEBfwuEPIELAYEAJwQhiCKgaaBIAQEBAQYBAQEBAQEUCYkHhxsGCwGDbYEUBZZDAYJRgWGIcpw5AR8BQ4QEhS86gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="asc'?scan'208";a="41155126" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2015 05:15:49 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA25Fm43032008 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2015 05:15:49 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 00:15:47 -0500 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; Mon, 2 Nov 2015 00:15:47 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Q== Date: Mon, 2 Nov 2015 05:15:47 +0000 Message-ID: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@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.235.76] Content-Type: multipart/signed; boundary="Apple-Mail=_3C943F93-0CC0-46AB-988D-3F7C41026CFC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 02 Nov 2015 05:15:52 -0000 --Apple-Mail=_3C943F93-0CC0-46AB-988D-3F7C41026CFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the discussion this morning, we wound up in a position that I could = not call "consensus", even "rough consensus", but per a hum of those in = the room, within shouting distance of achieving that. Several people = spoke at the mike asking for a sentence or brief discussion to be added, = or a section clarified. In the interest of expediency, let me ask those who spoke (and anyone = else that has an issue) to respond to this note (copying the list) with = suggested text. It might be best if this is stated as OLD TEXT the text that should be replaced goes here NEW TEXT the text that should replace it goes here or LOCATION identify the section the text should go into PROPOSED TEXT the text that should be added goes here I'll permit the authors to declare suggested text out of scope; some of = the discussion this morning left them commenting on scope and scope = creep. However, I do ask them to justify the exclusion to the list, = rather than just ignore the email. This comment period ends 15 November. --Apple-Mail=_3C943F93-0CC0-46AB-988D-3F7C41026CFC 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 iQIVAwUBVjbxg0ayAOS/EQ8MAQJ/OBAA1tq50fR4FBGIoa9EXd6MVMm9Y7uBaZSQ 6UXScJvYzxMF/WNabpUOR/Qls1HzdqJeUsZS61g/V4x5lKmKCfCbBnTUS1aUADNd TytUZsPfBCCmUmeDELrfb/83/b2KsHyVQE6VK2skeIUNHZLt85MAHcg/9oWuI08p KontcoLx+wkL+QgVvj50XGM8yH3ejqi7n3pLcfr2lNkA2L7g+trO9Op/yVLcKPmi ITAVl3NIMBC/rHYCV2aCQwf1yrM+Jqjva2LmYKyoLWOaXhA4J+ns3oCevATx7ImO Q4qJzkRaEXb5TVS3iC9BPqmG6goa2kAsve3x0nn2ZkwmMZ/AXuovnk/O4N5xTwJX 89DZc5qkqV3nLlSHYsQBpeoWP13WmDyBS+wfLQ3/swDN8msVG8Wsl4qJVDhQiC7+ wX6IWf5uE0mwpw+eFYTTPhZc2HpAYkzBDLQuFY/R68yA85JbivD4dpXvS6Tt8oC3 //ndwyj4SwtGw9tM0cIx3AiNSAIGFuYk5Sw9+5ZKdKGfftDZsbUnx42OME5ZAjDt Q2o5XNk0igsnnMyk8mxsXbzjZ3Py/IkfYRE6FMCOUaLSkxhWs0B0+1regasUT1bb jpxrZubZhFWuv+6T5RT9Jd8iwkIxVSKMysneWIUIBBazgUjMHwuCIZAkSggN95ZN o4Tb/Jt6JVo= =OHVc -----END PGP SIGNATURE----- --Apple-Mail=_3C943F93-0CC0-46AB-988D-3F7C41026CFC-- From nobody Sun Nov 1 21:41: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 8CBE01B474E for ; Sun, 1 Nov 2015 21:41:16 -0800 (PST) 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 uk--3D1E2mnq for ; Sun, 1 Nov 2015 21:41:15 -0800 (PST) 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 41A5D1B4747 for ; Sun, 1 Nov 2015 21:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1606; q=dns/txt; s=iport; t=1446442875; x=1447652475; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O0MBlAW5MXlNA1XkXphZ1LtKCE9QzGbgsRl5HpUY07s=; b=XA7x0+K7bIdS1CIuLav93mT904RUlC7rTo+cBlFLQNXWQpmjxXpSJjoS NyarqmAEOPtAxe/m72UrJkakVlbvA+ZpY6xAtXUk3UR3P7AqQ3xTCstYQ JDw0weoHtFFjRt6Uu/TbUxg41kaYp8z0DFaeQoMRWjZX4ijzYPDln9bux 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQAQ9zZW/4YNJK1egzuBQga7E4QvgVqGGQKBKDkTAQEBAQEBAYEKhDUBAQEDAXIHBQsCAQgOCi4yJQIEDgUOiBoIwSYBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYkHgm6ILIEUAQSSZoNdAYJRgWGIcgWcNAEjAT+EBHKEd4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="asc'?scan'208";a="46548067" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2015 05:41:13 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA25fCLU013293 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 05:41:13 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; Mon, 2 Nov 2015 00:41:12 -0500 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; Mon, 2 Nov 2015 00:41:12 -0500 From: "Fred Baker (fred)" To: David Lamparter Thread-Topic: [v6ops] v6ops-design-choices, SADR, draft-ietf-rtgwg-dst-src-routing-00 Thread-Index: AQHRFTEUnkhb/HVOTkKN9DCAkF3VAw== Date: Mon, 2 Nov 2015 05:41:12 +0000 Message-ID: References: <20151102020259.GB56957@eidolon> In-Reply-To: <20151102020259.GB56957@eidolon> 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.235.76] Content-Type: multipart/signed; boundary="Apple-Mail=_CC3E5941-BB4F-4E76-8336-2701D4122BFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6ops-design-choices, SADR, draft-ietf-rtgwg-dst-src-routing-00 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, 02 Nov 2015 05:41:16 -0000 --Apple-Mail=_CC3E5941-BB4F-4E76-8336-2701D4122BFA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Nov 2, 2015, at 11:02 AM, David Lamparter wrote: > > In relation to the short SADR intermezzo in the v6ops room a few minutes > ago, I'm happy to contradict Fred in that one of the drafts has in fact > been a WG document for 2 weeks now - Yay! Excellent! --Apple-Mail=_CC3E5941-BB4F-4E76-8336-2701D4122BFA 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 iQIVAwUBVjb3dkayAOS/EQ8MAQJTtg/8Dx8pDfpLdgxw4wHeAngxb3d6pSU895hf uffiYzKW0zzeyM4bgRRSY+LgdBZ8ZF4qnhkcjfUE3+VYRrwrcd9YmpJ1Ms1m1Gmm zJXnD49cCMNVs49fsRBmQfBYNb5sKYYUVAh2bhoO3gFwuBlXdInYX3gJW7I72uVR Y62U3rWVUAuz+v/ByjbYwQX1DQ+4A738xsrQ/XNZ84MSB+/knPlxMPAHN9ZOrQq4 xBqazExTqKwbGdTU6BDmqTOqly2cQQN80f4DbPNbrFlpXGAHmJNNgSlVUeX3SITe tqmgxVFp0Sv+1Q88DW0r7hqLLptdhYcwf5eg+Z46/dZevp0UP+ZaLQsXmeS3ltFK K6+8Ci3FYTm+aiD3lZhlaMlacHj2R1TaR69qmhYflN6Qz+Y9TRYZZmi650pcIBPL 1mgMLITDz5XWQSUN6Sicvb1IanxeXfGpdIFZFIrs/AOM/nZVbvlxXHO1l+DgHbct aksOwda40FnLIMFWbBWkEwQVOw05g+ZixZpLFFxs/YIxNg6CIiv+PRHcEmhKbESV LFh2EdOrqD+MsbZc40PhHbfiOuvUtQyXwRBV5VoO3jSqj2O9hXj7Q369+B/VVF6w 3cHnXtevoVJ2cKdjVMY2TO8DaBPAN5F4UpFIDfL2TIjogEaBQxg93mkHG93xKbg9 UPhlDcP8B6o= =vnGe -----END PGP SIGNATURE----- --Apple-Mail=_CC3E5941-BB4F-4E76-8336-2701D4122BFA-- From nobody Sun Nov 1 22:45:44 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 3788C1A0098 for ; Sun, 1 Nov 2015 22:45:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102064543.32353.19307.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 22:45:43 -0800 From: IETF Secretariat Archived-At: Subject: [v6ops] Milestones changed for v6ops WG 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, 02 Nov 2015 06:45:43 -0000 Changed milestone "Describe a Translation solution for IPv6-only data centers", added draft-ietf-v6ops-siit-eam, draft-ietf-v6ops-siit-dc, draft-ietf-v6ops-siit-dc-2xlat to milestone. Changed milestone "Describe emerging IPv6 allocations to hosts", added draft-ietf-v6ops-host-addr-availability to milestone. Changed milestone "Describe and recommend mitigations for energy consumption in Neighbor Discovery", resolved as "Done", added draft-ietf-v6ops-reducing-ra-energy-consumption to milestone. Changed milestone "Update RFC 6145 Translation in view of operational experience", added draft-bao-v6ops-rfc6145bis to milestone. Changed milestone "File report on behavior of IPv6 traffic with Extension Headers", added draft-ietf-v6ops-ipv6-ehs-in-real-world to milestone. Changed milestone "Describe routing choices and trade-offs for enterprise and service provider networks", set due date to March 2016 from November 2015, added draft-ietf-v6ops-design-choices to milestone. URL: https://datatracker.ietf.org/wg/v6ops/charter/ From nobody Sun Nov 1 23:46:34 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 9B7101ACEED; Sun, 1 Nov 2015 23:46:32 -0800 (PST) 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.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102074632.9601.39470.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 23:46:32 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-00.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, 02 Nov 2015 07:46:32 -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 : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14 Date : 2015-11-01 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-ietf-v6ops-unique-ipv6-prefix-per-host/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-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/ From nobody Sun Nov 1 23:48: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 9A6DB1B3446 for ; Sun, 1 Nov 2015 23:48:53 -0800 (PST) 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 noYA2vF1Qb_w for ; Sun, 1 Nov 2015 23:48:52 -0800 (PST) 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 46E151B3445 for ; Sun, 1 Nov 2015 23:48:52 -0800 (PST) X-AuditID: 44571fa7-f79626d0000011ff-59-563715630c10 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 D6.23.04607.36517365; Mon, 2 Nov 2015 02:48:51 -0500 (EST) Received: from PACDCEX44.cable.comcast.com (24.40.2.143) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 2 Nov 2015 02:48:31 -0500 Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX44.cable.comcast.com (24.40.2.143) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 2 Nov 2015 02:48:31 -0500 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, 2 Nov 2015 02:48:30 -0500 From: "Brzozowski, John" To: v6ops Thread-Topic: New Version Notification for draft-ietf-v6ops-unique-ipv6-prefix-per-host-00.txt Thread-Index: AQHRFUKYebtbF0IT9E25HQJOcav0hZ6JReaA Date: Mon, 2 Nov 2015 07:48:30 +0000 Message-ID: References: <20151102074632.9601.491.idtracker@ietfa.amsl.com> In-Reply-To: <20151102074632.9601.491.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: [96.115.73.252] Content-Type: text/plain; charset="utf-8" Content-ID: <8E47F3E52002F447B9573B4CA6562135@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsXiEq4ko5ssah5mcHQjv8XpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWL1L+aCDXIVL5tusjUwnpHtYuTkkBAwkXjycS8ThC0mceHe erYuRi4OIYFdTBJbJ/SwQjh7GCX6Pq1mhsowSrycspkJwjnBKHFyylKwfjYBG4nXH34ygtgi AlISiz/vBbOFBaIlJtx4wQoRT5DoWPeSGcI2kvjV0AtmswioSHw42MsCYvMK2Ev8fvKTDcQW ErCT+HlhF9h8TqD4xDmbwWYyAt36/dQasDizgLjErSfzoX4QkFiy5zwzhC0q8fLxP7C9ogJ6 Eu2n/rNBxA0kti7dxwJhK0r8m70eyOYAmqMpsX6XPsRIB4nlD14zQ9iKElO6H7JDnCYocXLm E7ByIaCR8x5IQ0wRlzh8ZAfrBEaZWUgOmoUwdBaSobOQDJ2FZOgCRtZVjHIFickpybkZ+aUl BoZ6yYlJOal6yfm5yYnFJSB6EyM4yuWX72C898LpEKMAB6MSD+9XbvMwIdbEsuLK3EOMEhzM SiK8XjfMwoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzbr73K1RIID2xJDU7NbUgtQgmy8TBKdXA WFu2Ybledb5780KT/r8RhR/W6DEbv/We5qOznH2xTH5j8cP3MRPXMO9ssWLnqUuZ2LZ+cpjq 0WDdxo3SixcavMhvZqvr/dviOte7L1Mt4W3736mNpwOvTDIMDq149p27K37x730pz1ezXn/f o7AkoaQ4RrN78eL+LK2pPhVGv36pej7/8iVAiaU4I9FQi7moOBEAhpBfmu4CAAA= Archived-At: Subject: [v6ops] New Version Notification for draft-ietf-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, 02 Nov 2015 07:48:53 -0000 UGVyIEZyZWTigJlzIHJlcXVlc3QgdGhpcyBJLUQgaGFzIGJlZW4gcmVuYW1lZC4gIFdlIGhhdmUg YSAtMDEgaW4gdGhlIHdvcmtzDQpiYXNlZCBvbiB0aGUgZmVlZGJhY2sgd2UgaGF2ZSByZWNlaXZl ZCBieSBlbWFpbCBhbmQgaW4gdGhlIFdHIG1lZXRpbmcgdG8NCmRhdGUuDQoNCkpvaG4NCisxLTQ4 NC05NjItMDA2MA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogImlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkRhdGU6 IE1vbmRheSwgTm92ZW1iZXIgMiwgMjAxNSBhdCAxNjo0Ng0KVG86IEd1bnRlciBWYW4gZGUgVmVs ZGUgPGd1bnRlci52YW5fZGVfdmVsZGVAYWxjYXRlbC1sdWNlbnQuY29tPiwgSm9obg0KSmFzb24g QnJ6b3pvd3NraSA8am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPiwgR3VudGVyIFZh biBkZSBWZWxkZQ0KPGd1bnRlci52YW5fZGVfdmVsZGVAYWxjYXRlbC1sdWNlbnQuY29tPg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAudHh0DQo+ aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIEphc29uIEJyem96b3dza2kg YW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+UmV2aXNpb246CTAwDQo+VGl0 bGU6CQlVbmlxdWUgSVB2NiBQcmVmaXggUGVyIEhvc3QNCj5Eb2N1bWVudCBkYXRlOgkyMDE1LTEx LTAyDQo+R3JvdXA6CQl2Nm9wcw0KPlBhZ2VzOgkJMTQNCj5VUkw6ICAgICAgICAgICAgDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXANCj5lci1ob3N0LTAwLnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2 LXByZWZpeC1wZXItaA0KPm9zdC8NCj5IdG1saXplZDogICAgICAgDQo+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTANCj4wDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAgSW4gc29tZSBJUHY2IGVudmlyb25tZW50cyB0 aGUgbmVlZCBoYXMgYXJpc2VuIGZvciBob3N0cyB0byBiZSBhYmxlIHRvDQo+ICAgdXRpbGlzZSBh IHVuaXF1ZSBJUHY2IHByZWZpeCBldmVuIHRob3VnaCB0aGUgbGluayBvciBtZWRpYSBtYXkgYmUN Cj4gICBzaGFyZWQuICBUeXBpY2FsbHkgaG9zdHMgKHN1YnNjcmliZXJzKSBvbiBhIHNoYXJlZCBu ZXR3b3JrLCBsaWtlIFdpLQ0KPiAgIEZpIG9yIEV0aGVybmV0LCB3aWxsIGFjcXVpcmUgdW5pcXVl IElQdjYgYWRkcmVzc2VzIGZyb20gYSBjb21tb24gSVB2Ng0KPiAgIHByZWZpeCB0aGF0IGlzIGFs bG9jYXRlZCBvciBhc3NpZ25lZCBmb3IgdXNlIG9uIGEgc3BlY2lmaWMgbGluay4NCj4gICBCZW5l Zml0cyBvZiBhIHVuaXF1ZSBJUHY2IHByZWZpeCBjb21wYXJlZCB0byBhIHVuaXF1ZSBJUHY2IGFk ZHJlc3MNCj4gICBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGFyZSBnb2luZyBmcm9tIGVuaGFu Y2VkIHN1YnNjcmliZXINCj4gICBtYW5hZ2VtZW50IHRvIGltcHJvdmVkIGlzb2xhdGlvbiBiZXR3 ZWVuIHN1YnNjcmliZXJzLg0KPg0KPiAgIEluIG1vc3QgZGVwbG95bWVudHMgdG9kYXkgSVB2NiBh ZGRyZXNzIGFzc2lnbm1lbnQgZnJvbSBhIHNpbmdsZSBJUHY2DQo+ICAgcHJlZml4IG9uIGEgc2hh cmVkIG5ldHdvcmsgaXMgZG9uZSBieSBlaXRoZXIgdXNpbmcgSVB2NiBzdGF0ZWxlc3MNCj4gICBh ZGRyZXNzIGF1dG8tY29uZmlndXJhdGlvbiAoU0xBQUMpIGFuZC9vciBzdGF0ZWZ1bCBESENQdjYu ICBXaGlsZQ0KPiAgIHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25l ZCB0aGVyZSBhcmUgc29tZSBsYXJnZQ0KPiAgIHNjYWxlIGVudmlyb25tZW50cyB3aGVyZSB0aGlz IGNvbmNlcHQgaW50cm9kdWNlcyBzaWduaWZpY2FudA0KPiAgIHBlcmZvcm1hbmNlIGNoYWxsZW5n ZXMgYW5kIGltcGxpY2F0aW9ucywgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2Ng0KPiAgIHJv dXRlciBhbmQgbmVpZ2hib3IgZGlzY292ZXJ5LiAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBh cHByb2FjaA0KPiAgIHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scyB0byBhbGxvdyBo b3N0cyB0byBiZSBhc3NpZ25lZCBhDQo+ICAgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFkIG9m IGEgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVkDQo+ICAgSVB2NiBwcmVmaXgpLg0K Pg0KPiAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAgDQo+ZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDAgcmVwbGFjZXMNCj5kcmFmdC1qam1iLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wMA0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0K PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4NCg0K From nobody Mon Nov 2 01:17: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 1F85B1B356D for ; Mon, 2 Nov 2015 01:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, 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 e6O0-aOtPGrj for ; Mon, 2 Nov 2015 01:17:07 -0800 (PST) Received: from cdpipgw01.twcable.com (unknown [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 478331B356A for ; Mon, 2 Nov 2015 01:17:07 -0800 (PST) X-SENDER-IP: 10.64.163.160 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,234,1444708800"; d="scan'208";a="1051173055" Received: from unknown (HELO exchpapp19.corp.twcable.com) ([10.64.163.160]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 02 Nov 2015 04:10:02 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp19.corp.twcable.com (10.64.163.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 04:17:05 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 04:17:04 -0500 From: "Howard, Lee" To: 'IPv6 Operations' Thread-Topic: draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhg== Date: Mon, 2 Nov 2015 09:17:04 +0000 Message-ID: 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21916.004 x-tm-as-result: No--35.845400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 09:17:08 -0000 This document hasn=B9t had any revisions or discussion in a while. Is there anyone interested in working on it? If we do not hear any interest, we will abandon this draft. Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Nov 2 01: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 1F5631B356C for ; Mon, 2 Nov 2015 01:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, 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 iQiibPd_k-W8 for ; Mon, 2 Nov 2015 01:17:07 -0800 (PST) Received: from cdpipgw01.twcable.com (unknown [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D91D71B355B for ; Mon, 2 Nov 2015 01:17:06 -0800 (PST) X-SENDER-IP: 10.64.163.155 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,234,1444708800"; d="scan'208";a="1051172988" Received: from unknown (HELO exchpapp14.corp.twcable.com) ([10.64.163.155]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 02 Nov 2015 04:10:01 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp14.corp.twcable.com (10.64.163.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 04:17:03 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 04:17:03 -0500 From: "Howard, Lee" To: 'IPv6 Operations' Thread-Topic: draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? Thread-Index: AQHRFU888nRMMUSjWUC3GmDThnGDmA== Date: Mon, 2 Nov 2015 09:17:03 +0000 Message-ID: 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21916.004 x-tm-as-result: No--35.845400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <365100AD2A638740969A9F209BDD5D88@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? 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, 02 Nov 2015 09:17:08 -0000 This document hasn=B9t had any revisions or discussion in a while. Is there anyone interested in working on it? If we do not hear any interest, we will abandon this draft. Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Nov 2 01:52: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 A4C101A0378 for ; Mon, 2 Nov 2015 01:52:32 -0800 (PST) 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 aN0tjhAW4DyZ for ; Mon, 2 Nov 2015 01:52:30 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA161A02B1 for ; Mon, 2 Nov 2015 01:52:30 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id D8BFC3D0B3; Mon, 2 Nov 2015 10:52:28 +0100 (CET) Date: Mon, 02 Nov 2015 10:52:28 +0100 (CET) Message-Id: <20151102.105228.439899806.he@uninett.no> To: markzzzsmith@gmail.com From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Mon, 02 Nov 2015 09:52:32 -0000 >>> I agree with making sure to avoiding ambiguity, I know on occasion = it >>> hasn't been clear to me whether somebody is describing a prefix wit= h a >>> smaller number of addresses, or a shorter prefix length, which obvi= ously >>> mean the complete opposites in terms of number of addresses within = the >>> prefix, when they use "smaller prefix". >> >> What about "smaller/larger sized prefix"? > > That would be clearer. To me that's still borderline ambigious, and I don't understand why anyone would want to use borderline ambigious wording when writing RFCs or discussing them. It's not clear whether it's the prefix-length which is "smaller" or "larger" or the address space covered which is "smaller" or "larger", and they each point in the direction of different interpretations. In other words, you don't "size" a prefix, but you "size" the address space covered. A prefix, on the other hand, has length, so to my eyes the above looks ... awkward. Therefore I'm suggesting the more unambigious "shorter/longer prefix" as preferable. Regards, - H=E5vard From nobody Mon Nov 2 01:58: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 86DA21A066C for ; Mon, 2 Nov 2015 01:58:47 -0800 (PST) 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 yIvqoCvQxl6B for ; Mon, 2 Nov 2015 01:58:45 -0800 (PST) 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 5A94B1A06E9 for ; Mon, 2 Nov 2015 01:58:45 -0800 (PST) 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 tA29whTK017079 for ; Mon, 2 Nov 2015 10:58:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAF2320141A for ; Mon, 2 Nov 2015 11:04: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 B16A0200D11 for ; Mon, 2 Nov 2015 11:04:09 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.5]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA29w8NF026183 for ; Mon, 2 Nov 2015 10:58:12 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <563733AF.4010509@gmail.com> Date: Mon, 2 Nov 2015 18:58:07 +0900 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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 09:58:47 -0000 Hello, I would like to continue working on this draft. I am not sure what is needed to continue working on this draft? Is it ready to go as is? The ULAs I consider are (1) in the core of enterprise PA+ULA network slowly migrating to IPv6 and (2) in vehicles at manufacturing time. In an enterprise network, I wonder whether ULAs coexist well with IPv4 on a same VLAN, or must they be each on its own VLAN? Such as to leave IPv4 continue exist well. I think a recommendation on this is very valuable, at least to me. Also, I wonder whether simply adding ULAs on interfaces of a well-known router means that it will automatically turn on NAT66? (or not?) Will the packets addressed to them from a PA-part of the enterprise network be dropped by default? More generally - what is the precise knob which blocks ULA-addressed packets from leaking to the Internet? Is this a matter of a routing protocol knob, like e.g. BGP having a definition of an area around ULAs? Or is it a matter of on/off knob which allows/disallows reaching a ULA in the network attached to a particular interface? Or does it only depend of a trivial static route being present or absent in the forward information base? For ULAs in a vehicle, it is a bit early to describe the problems and the needed advice, but I speculate there will be a need for this. We have several drafts and implementations on this topic. Alex Le 02/11/2015 18:17, Howard, Lee a écrit : > This document hasnąt had any revisions or discussion in a while. Is > there anyone interested in working on it? > > If we do not hear any interest, we will abandon this draft. > > Thanks, Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 2 02:03: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 255B11A19EC for ; Mon, 2 Nov 2015 02:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 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, HTML_MESSAGE=0.001, 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 I6wxGFyozv0b for ; Mon, 2 Nov 2015 02:03:06 -0800 (PST) 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 C0BC11A19E9 for ; Mon, 2 Nov 2015 02:03:05 -0800 (PST) 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 tA2A314A019153 for ; Mon, 2 Nov 2015 11:03:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B88DB202529 for ; Mon, 2 Nov 2015 11:09:00 +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 A477F20A692 for ; Mon, 2 Nov 2015 11:09:00 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.5]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA2A2xO3031013 for ; Mon, 2 Nov 2015 11:03:02 +0100 From: Alexandre Petrescu To: "v6ops@ietf.org" Message-ID: <563734D2.2@gmail.com> Date: Mon, 2 Nov 2015 19:02:58 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010503020807090702010806" Archived-At: Subject: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 02 Nov 2015 10:03:07 -0000 This is a multi-part message in MIME format. --------------010503020807090702010806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, With respect to the design-choices draft, I think it is worth to mention in the discussion that backwards compatibility is a 'pro' when considering PA/PI/ULA schemes for enterprise networks. It is not a drawback. This (maintain IPv4 ok while migrating) is the most important requirement in the networks I work. Alex --------------010503020807090702010806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

With respect to the design-choices draft, I think it is worth to mention in the discussion that backwards compatibility is a 'pro' when considering PA/PI/ULA schemes for enterprise networks.  It is not a drawback.

This (maintain IPv4 ok while migrating) is the most important requirement in the networks I work.

Alex
 --------------010503020807090702010806-- From nobody Mon Nov 2 02:51: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 468BE1A1EF4 for ; Mon, 2 Nov 2015 02:51:17 -0800 (PST) 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 gVUE8yjrjpCL for ; Mon, 2 Nov 2015 02:51:15 -0800 (PST) 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 E365B1A1C06 for ; Mon, 2 Nov 2015 02:51:14 -0800 (PST) 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 tA2ApAFf011699 for ; Mon, 2 Nov 2015 11:51:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6FEEC20A73A for ; Mon, 2 Nov 2015 11:57:09 +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 65EE720A6FF for ; Mon, 2 Nov 2015 11:57:09 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA2Ap7dI031772 for ; Mon, 2 Nov 2015 11:51:11 +0100 To: v6ops@ietf.org References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> From: Alexandre Petrescu Message-ID: <5637401A.1050807@gmail.com> Date: Mon, 2 Nov 2015 19:51:06 +0900 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: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 02 Nov 2015 10:51:17 -0000 Hello, I do agree with the idea in the draft and I fully support its advancement. Lorenzo said several times, and the abstract is clear, that the recommendation is to not limit the number of addresses are 'provided' to general-purposes hosts. I fully agree with the intent in general. But because SLAAC is what it is, a network does not 'provide' an address to the host. Worse, it is because of SLAAC universally assumed that the end result may look that only one address is provided to the host. If SLAAC were not what it is, or if it were not that widely adopted, then the network could safely assume it 'provided' 2^64 addresses to a host when it set a prefixlen 64 in a RA. For example, the draft says: > In most general-purpose IPv6 networks, including all 3GPP networks > (see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using > SLAAC [RFC4862], IPv6 hosts have the ability to configure additional > IPv6 addresses from the link prefix(es) without explicit requests to > the network. YEs. But this does not mean that it is good that a 3GPP network gives only one /64 to an UE. This is not a good recommendation. The right recommendation is the following: "in a 3GPP network which uses exclusively SLAAC for IPv6 address configuration on the UE the network must not limit its ability to set multiple distinct IPv6 prefixes in a RA to the UE. By default there should be two." (other criteria are: in any access network which uses ptp links with next-hop as an address rather than a '*' in the forwarding entry for the general-purpose host, and exclusively SLAAC) Also, at the following place: OLD: > Example of how the availability of multiple addresses per host has > already allowed substantial deployment of new applications without > explicit requests to the network are: [...] > o /64 sharing [RFC7278]. This was a way to provide IPv6 tethering > without needing to wait for network operators to deploy DHCPv6 PD, > which is only available in 3GPP release 10. This is not a good example either. One wouldn't give an INFORMATIONAL document as a recommendation to follow. I suggest the following NEW: An example of how the availability of multiple addresses per host has already stimulated successful new applications: [...] o tethering. In tethering a UE such as a smartphone connects several IP devices on its LAN through the access network and to the Internet. This is realized with DHCPv6-PD [AERO] or some other techniques like "/64 sharing" [RFC7278] or other forms of bridging. Alex Le 02/11/2015 14:15, Fred Baker (fred) a écrit : > In the discussion this morning, we wound up in a position that I could not call "consensus", even "rough consensus", but per a hum of those in the room, within shouting distance of achieving that. Several people spoke at the mike asking for a sentence or brief discussion to be added, or a section clarified. > > In the interest of expediency, let me ask those who spoke (and anyone else that has an issue) to respond to this note (copying the list) with suggested text. It might be best if this is stated as > > OLD TEXT > the text that should be replaced goes here > NEW TEXT > the text that should replace it goes here > > or > > LOCATION > identify the section the text should go into > PROPOSED TEXT > the text that should be added goes here > > I'll permit the authors to declare suggested text out of scope; some of the discussion this morning left them commenting on scope and scope creep. However, I do ask them to justify the exclusion to the list, rather than just ignore the email. > > This comment period ends 15 November. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 2 02: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 6FA871A1EF3 for ; Mon, 2 Nov 2015 02:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 GD2ENjDXZccH for ; Mon, 2 Nov 2015 02:53:21 -0800 (PST) Received: from tor-smtp-04.primus.ca (smtp-auth-16.primus.ca [67.230.159.16]) by ietfa.amsl.com (Postfix) with ESMTP id 493C21A1EB7 for ; Mon, 2 Nov 2015 02:53:21 -0800 (PST) Received: from i223-218-131-39.s41.a014.ap.plala.or.jp ([223.218.131.39] helo=[192.168.2.100]) by tor-smtp-04.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZtCjo-0001SA-C9; Mon, 02 Nov 2015 05:53:20 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-1-2932741 From: Philip Matthews In-Reply-To: <563734D2.2@gmail.com> Date: Mon, 2 Nov 2015 19:52:47 +0900 Message-Id: <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> References: <563734D2.2@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - i223-218-131-39.s41.a014.ap.plala.or.jp ([192.168.2.100]) [223.218.131.39] Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 02 Nov 2015 10:53:22 -0000 --Apple-Mail-1-2932741 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you explain a bit more what you mean by that? =20 - Philip On 2015-11-02, at 19:02 , Alexandre Petrescu wrote: > Hello, >=20 > With respect to the design-choices draft, I think it is worth to = mention in the discussion that backwards compatibility is a 'pro' when = considering PA/PI/ULA schemes for enterprise networks. It is not a = drawback. >=20 > This (maintain IPv4 ok while migrating) is the most important = requirement in the networks I work. >=20 > Alex > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-1-2932741 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Can you explain a bit more what you mean by that?  
- Philip


On 2015-11-02, at 19:02 , Alexandre Petrescu wrote:

Hello,

With respect to the design-choices draft, I think it is worth to mention in the discussion that backwards compatibility is a 'pro' when considering PA/PI/ULA schemes for enterprise networks.  It is not a drawback.

This (maintain IPv4 ok while migrating) is the most important requirement in the networks I work.

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

--Apple-Mail-1-2932741-- From nobody Mon Nov 2 04:47: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 669FC1B35D2 for ; Mon, 2 Nov 2015 04:47:04 -0800 (PST) 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 N8q8Fiz3iXFt for ; Mon, 2 Nov 2015 04:47:03 -0800 (PST) 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 333F91B35BB for ; Mon, 2 Nov 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=144; q=dns/txt; s=iport; t=1446468423; x=1447678023; h=date:from:message-id:to:subject:cc; bh=uO3azjmEuDB4YsUGS7mDBxvfh48XJ/SJl82d9UqD3i4=; b=gqYWQ6Wikgd/oJy17BRDvgn9jphd4kA4k/PkBxjArjD4cDSpWs6mLio3 biEWeSb3m38ataKqXjNcwfSuO1laTB+BiJLeZ56GZ8oTWy04VI+lxcd6r eHFArDy0gouxAsPBg+vEazpiYCMl5kCNIeO4VT9n5Efig9FRRU1/xPRJi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B6AgD3WTdW/4YNJK1egztTcK4ZAZEiAQ2BWiOFbQmBMTgUAQEBAQEBAYEKhDh9PDSJEAENwRABAQEHAQEBAQEei3WFKoQWBY4RiDKFHYlhSIN3liIfAQFChCWGTwEBAQ X-IronPort-AV: E=Sophos;i="5.20,234,1444694400"; d="scan'208";a="204335584" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2015 12:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA2Cl20q006420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id tA2Cl1El020987; Mon, 2 Nov 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id tA2Cl14l020984; Mon, 2 Nov 2015 04:47:01 -0800 Date: Mon, 2 Nov 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201511021247.tA2Cl14l020984@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-unique-ipv6-prefix-per-host 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, 02 Nov 2015 12:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host. Please take a look at it and comment. From nobody Mon Nov 2 07:50: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 169721B48C9 for ; Mon, 2 Nov 2015 07:50:55 -0800 (PST) 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 uy2O3klH6ZJs for ; Mon, 2 Nov 2015 07:50:52 -0800 (PST) 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 305A91B48C4 for ; Mon, 2 Nov 2015 07:50:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV30643; Mon, 02 Nov 2015 15:50:48 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 15:50:47 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 23:50:41 +0800 From: "Liubing (Leo)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFVUaWz4Tcyq930Wi3jgKFnfWJ56I2lgg Date: Mon, 2 Nov 2015 15:50:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C23191E2@nkgeml506-mbx.china.huawei.com> References: <563733AF.4010509@gmail.com> In-Reply-To: <563733AF.4010509@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.186.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5637865A.001B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 15:50:55 -0000 Hi Dear Alex and all, Speaking as a co-author. I wasn't in the v6ops session this afternoon. And I'm sorry for the silence= of the draft for a while, but I do wish to continue working on it. There was indeed lots of controversial discussion on it, but many of them (= even most of them) was just not directly regarding to the draft itself (mos= tly the IPv6 NAT debate). For the draft, we heard few negative comments, bu= t much more positive comments that were in favor of advancing it. Unfortuna= tely, we didn't get the chance to WGLC, and we also didn't get some essenti= al feedback of how to improve it. So the draft was kind of stuck there. No = doubt it should be my responsibility to approach it, but the WG's feedback = is also very important/helpful for us. And thanks for Alex' response, you're more than welcome to contribute on th= is draft. We can have some detailed discussion later to figure out how to m= ake an update. For people who are in favor of advancing this draft, I expect very much you= could state your opinion on this.=20 Many thanks to you all. Best regards, Bing -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, November 02, 2015 6:58 PM To: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? Hello, I would like to continue working on this draft. I am not sure what is needed to continue working on this draft? Is it read= y to go as is? The ULAs I consider are (1) in the core of enterprise PA+ULA network slowly= migrating to IPv6 and (2) in vehicles at manufacturing time. In an enterprise network, I wonder whether ULAs coexist well with IPv4 on a= same VLAN, or must they be each on its own VLAN? Such as to leave IPv4 continue exist well. I think a recommendation on this is very valuabl= e, at least to me. Also, I wonder whether simply adding ULAs on interfaces of a well-known router means that it will automatically turn on NAT66? (or not?) Will the packets addressed to them from a PA-part of the enterprise network be d= ropped by default? More generally - what is the precise knob which blocks ULA-addressed packet= s from leaking to the Internet? Is this a matter of a routing protocol kno= b, like e.g. BGP having a definition of an area around ULAs? Or is it a matter of on/off knob which allows/disallows reaching a ULA in= the network attached to a particular interface? Or does it only depend of= a trivial static route being present or absent in the forward information = base? For ULAs in a vehicle, it is a bit early to describe the problems and the n= eeded advice, but I speculate there will be a need for this. We have sever= al drafts and implementations on this topic. Alex Le 02/11/2015 18:17, Howard, Lee a =E9crit : > This document hasn=B9t had any revisions or discussion in a while. Is=20 > there anyone interested in working on it? > > If we do not hear any interest, we will abandon this draft. > > Thanks, Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable=20 > proprietary information, which is privileged, confidential, or subject=20 > to copyright belonging to Time Warner Cable. This E-mail is intended=20 > solely for the use of the individual or entity to which it is=20 > addressed. If you are not the intended recipient of this E-mail, you=20 > are hereby notified that any dissemination, distribution, copying, or=20 > action taken in relation to the contents of and attachments to this=20 > E-mail is strictly prohibited and may be unlawful. If you have=20 > received this E-mail in error, please notify the sender immediately=20 > and permanently delete the original and any copy of this E-mail and=20 > any printout. > > _______________________________________________ v6ops mailing list=20 > 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 Mon Nov 2 08:00: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 0BA751B48FA for ; Mon, 2 Nov 2015 08:00:53 -0800 (PST) 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 IRzrdcnAEj8P for ; Mon, 2 Nov 2015 08:00:51 -0800 (PST) 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 38EC61B48F4 for ; Mon, 2 Nov 2015 08:00:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV31671; Mon, 02 Nov 2015 16:00:48 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 16:00:48 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 00:00:44 +0800 From: "Liubing (Leo)" To: "'IPv6 Operations'" Thread-Topic: draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? Thread-Index: AQHRFU888nRMMUSjWUC3GmDThnGDmJ6I4jeA Date: Mon, 2 Nov 2015 16:00:43 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319201@nkgeml506-mbx.china.huawei.com> 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.194.186.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.563788B1.014F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2c33d546c1ef9c8af9cd30af5348bbef Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? 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, 02 Nov 2015 16:00:53 -0000 Hi Dear all, Speaking as a co-author. I do wish to continue working on it. We actually had an essential revision around ietf93. We added more comprehe= nsive test cases in that revision, but unfortunately we didn't get a chance= to present it in Prague. Personally I believe the technical aspect of the draft is ready, but might = need a final editorial/organization revision. And please pardon me for iterating it again: this draft is not intended to = serve as a formal Problem Statement document, it is an informational draft = that captures current divergent behaviors of interpreting the M/O bits by d= ifferent operating systems. We believe it is valuable information for netwo= rk administrators. I really hope you could state your opinion if you're in favor of advancing = the draft. Best regards, Bing=20 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Monday, November 02, 2015 6:17 PM To: 'IPv6 Operations' Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? This document hasn=B9t had any revisions or discussion in a while. Is there anyone interested in working on it? If we do not hear any interest, we will abandon this draft. Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 2 08:03: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 2088F1B4912 for ; Mon, 2 Nov 2015 08:03:12 -0800 (PST) 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 IK6XnmGmo-Vb for ; Mon, 2 Nov 2015 08:03:09 -0800 (PST) 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 595681B4915 for ; Mon, 2 Nov 2015 08:02:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV31953; Mon, 02 Nov 2015 16:02:47 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 16:02:46 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 00:02:41 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFVUaWz4Tcyq930Wi3jgKFnfWJ56I2lgggAAKhZA= Date: Mon, 2 Nov 2015 16:02:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> References: <563733AF.4010509@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.186.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56378927.0102, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 16:03:12 -0000 And pardon for my iteration again: this draft is NOT making any formal reco= mmendations, but some considerations to refer if you're going to use ULAs. Best regards, Bing -----Original Message----- From: Liubing (Leo)=20 Sent: Tuesday, November 03, 2015 12:51 AM To: 'Alexandre Petrescu'; v6ops@ietf.org Subject: RE: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? Hi Dear Alex and all, Speaking as a co-author. I wasn't in the v6ops session this afternoon. And I'm sorry for the silence= of the draft for a while, but I do wish to continue working on it. There was indeed lots of controversial discussion on it, but many of them (= even most of them) was just not directly regarding to the draft itself (mos= tly the IPv6 NAT debate). For the draft, we heard few negative comments, bu= t much more positive comments that were in favor of advancing it. Unfortuna= tely, we didn't get the chance to WGLC, and we also didn't get some essenti= al feedback of how to improve it. So the draft was kind of stuck there. No = doubt it should be my responsibility to approach it, but the WG's feedback = is also very important/helpful for us. And thanks for Alex' response, you're more than welcome to contribute on th= is draft. We can have some detailed discussion later to figure out how to m= ake an update. For people who are in favor of advancing this draft, I expect very much you= could state your opinion on this.=20 Many thanks to you all. Best regards, Bing -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, November 02, 2015 6:58 PM To: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? Hello, I would like to continue working on this draft. I am not sure what is needed to continue working on this draft? Is it read= y to go as is? The ULAs I consider are (1) in the core of enterprise PA+ULA network slowly= migrating to IPv6 and (2) in vehicles at manufacturing time. In an enterprise network, I wonder whether ULAs coexist well with IPv4 on a= same VLAN, or must they be each on its own VLAN? Such as to leave IPv4 continue exist well. I think a recommendation on this is very valuabl= e, at least to me. Also, I wonder whether simply adding ULAs on interfaces of a well-known router means that it will automatically turn on NAT66? (or not?) Will the packets addressed to them from a PA-part of the enterprise network be d= ropped by default? More generally - what is the precise knob which blocks ULA-addressed packet= s from leaking to the Internet? Is this a matter of a routing protocol kno= b, like e.g. BGP having a definition of an area around ULAs? Or is it a matter of on/off knob which allows/disallows reaching a ULA in= the network attached to a particular interface? Or does it only depend of= a trivial static route being present or absent in the forward information = base? For ULAs in a vehicle, it is a bit early to describe the problems and the n= eeded advice, but I speculate there will be a need for this. We have sever= al drafts and implementations on this topic. Alex Le 02/11/2015 18:17, Howard, Lee a =E9crit : > This document hasn=B9t had any revisions or discussion in a while. Is=20 > there anyone interested in working on it? > > If we do not hear any interest, we will abandon this draft. > > Thanks, Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable=20 > proprietary information, which is privileged, confidential, or subject=20 > to copyright belonging to Time Warner Cable. This E-mail is intended=20 > solely for the use of the individual or entity to which it is=20 > addressed. If you are not the intended recipient of this E-mail, you=20 > are hereby notified that any dissemination, distribution, copying, or=20 > action taken in relation to the contents of and attachments to this=20 > E-mail is strictly prohibited and may be unlawful. If you have=20 > received this E-mail in error, please notify the sender immediately=20 > and permanently delete the original and any copy of this E-mail and=20 > any printout. > > _______________________________________________ v6ops mailing list=20 > 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 Mon Nov 2 11:30: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 79F831B2AEF for ; Mon, 2 Nov 2015 11:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 l12TSv6Dj6mO for ; Mon, 2 Nov 2015 11:30:40 -0800 (PST) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E463D1B2ABF for ; Mon, 2 Nov 2015 11:30:39 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tA2JSvMe041717; Mon, 2 Nov 2015 14:30:31 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 1xvpwt2s27-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2015 14:30:31 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id tA2JUTKu020288; Mon, 2 Nov 2015 14:30:30 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id tA2JUJqB019975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2015 14:30:21 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 2 Nov 2015 19:30:10 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.188]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 14:30:09 -0500 From: "STARK, BARBARA H" To: Brian E Carpenter , Tore Anderson , "v6ops@ietf.org" Thread-Topic: [v6ops] M/O flags and PD Thread-Index: AQHREpaLgf/xytQGK0GZBFdbnxAIPJ6D3ryAgAALMwCAAAjygIAAeS0AgAA+jwCAAOR/gIAAq2SAgALeLFA= Date: Mon, 2 Nov 2015 19:30:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611424EC0D1@GAALPA1MSGUSRBF.ITServices.sbc.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> <20151031094621.182c6c50@envy.fud.no> <56350FA3.4060105@gmail.com> In-Reply-To: <56350FA3.4060105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.91.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-02_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1511020334 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: Mon, 02 Nov 2015 19:30:41 -0000 > >> 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. Just to provide some additional context/history... BBF TR-124 (https://www.broadband-forum.org/technical/download/TR-124_Issue= -4.pdf, whose IPv6 requirements predate RFC 7084) requires simultaneous DHC= Pv6 solicit (for IA_NA, IA_PD, and everything else) and RS from the telco I= SP-procured "CE router" (RG in TR-124). In BBF we saw no need to wait for t= he RA.=20 The eRouter people wanted their routers to wait for M=3D1, though, before d= oing DHCPv6 solicit, because they were having a field trial issue where the= y only wanted select CE routers to solicit from the DHCPv6 server. They wer= en't ready for all CE routers to be soliciting (and this was before SOL_MAX= _RT so the unwanted CE routers were soliciting every 2 minutes and overwhel= ming the field trial DHCPv6 servers).=20 The current RFC 7084 language allows the eRouters to wait for RA and only S= olicit when M or O =3D 1, but doesn't preclude the BBF simultaneous RS/DHCP= v6. Retail CE router vendors can decide for themselves what they want to do= .=20 >From the access network perspective, independent of whether the CE router i= s just RFC 7084, or is eRouter or TR-124, the access network can ensure DHC= Pv6 Solicit by use of M or O =3D 1 flags (since "simultaneous" implementati= ons will always do DHCPv6, including when M or O =3D 1). They can't prevent= all unwanted DHCPv6 Solicit, but apparently there weren't enough "simultan= eous" implementations to cause issues in cable networks. They designed the = eRouter to only do DHCPv6 Solicit when M or O =3D 1. This was a compromise = solution and is the reason M =3D O =3D 0 is out of scope in RFC 7084. Barbara From nobody Mon Nov 2 12:37: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 E5FF81B381C for ; Mon, 2 Nov 2015 12:37:45 -0800 (PST) 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 PgTQgYDNeYhH for ; Mon, 2 Nov 2015 12:37:44 -0800 (PST) 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 6EE091B3818 for ; Mon, 2 Nov 2015 12:37:44 -0800 (PST) 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 tA2Kbiat012336; Mon, 2 Nov 2015 14:37:44 -0600 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA2KbgHa012320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 2 Nov 2015 14:37:42 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.64]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 12:37:40 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: AERO and multi-addressing Thread-Index: AdEVrAwtOvfi+MxRRTiOjpDIe5ESnw== Date: Mon, 2 Nov 2015 20:37:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F37C12@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: [v6ops] AERO and multi-addressing 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, 02 Nov 2015 20:37:46 -0000 Hello, AERO (which was not included on the agenda yesterday) has been advocating giving the end system a /64 or shorter prefix for a long time - longer than recent drafts on this subject have been around. The mechanism AERO uses is DHCPv6 PD over NBMA tunnels. Once it receives a delegated prefix, the end system can then act as either a router or a host (either weak end system or strong end system) and assign as many addresses as it wants without having to do DAD for any of them. Strong end system is different than a router act= ing as a host, because IP forwarding is turned off and the end system is there= fore a true host and not a router. The draft is here, and comments are welcome: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thanks - Fred fred.l.templin@boeing.com From nobody Mon Nov 2 12:56: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 92F751B3884 for ; Mon, 2 Nov 2015 12:56:10 -0800 (PST) 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 43BFr8c01ko1 for ; Mon, 2 Nov 2015 12:56:09 -0800 (PST) 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 F001C1B3872 for ; Mon, 2 Nov 2015 12:56:08 -0800 (PST) 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 tA2Ku7l7028277; Mon, 2 Nov 2015 14:56:07 -0600 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA2Ku4Br028246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 2 Nov 2015 14:56:04 -0600 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; Mon, 2 Nov 2015 12:56:03 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: AERO and enterprise mobile VPN Thread-Index: AdEVsNVlYEbNlbDZSvuSOqMlG+WkFw== Date: Mon, 2 Nov 2015 20:56:03 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F37C9F@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: [v6ops] AERO and enterprise mobile VPN 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, 02 Nov 2015 20:56:10 -0000 Hello, Enterprise mobile device users need a way to get back into the enterprise v= ia the Internet when they are coming in from some form of off-campus access link. For this, mobile devices are more and more beginning to use VPN clien= ts that can establish a secure tunnel via an enterprise border security gatewa= y. But, a mobile VPN client that uses AERO can receive a prefix delegation fro= m the enterprise that it can retain and use wherever it happens to move to. AERO can be used for maintaining a mobile VPN service for enterprise mobile devices. The service can be built into the enterprise network, and the clie= nt functions can be integrated with common VPN clients such as OpenVPN. This would give end systems a mobile multi-addressing capability that does not require renumbering even as the end system moves between on- and off- campus access links. IMHO, this is a compelling use case as enterprise networks come in a vast array of shapes and sizes. Comments welcome. Thanks - Fred fred.l.templin@boeing.com From nobody Mon Nov 2 13:40: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 D1B331A879F for ; Mon, 2 Nov 2015 13:40:54 -0800 (PST) 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 47WSJgIIj6rC for ; Mon, 2 Nov 2015 13:40:53 -0800 (PST) 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 EE90A1A879D for ; Mon, 2 Nov 2015 13:40:52 -0800 (PST) Received: from mb-2.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA2Lehop077890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 21:40:45 GMT (envelope-from joelja@bogus.com) To: "Liubing (Leo)" , "v6ops@ietf.org" References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> From: joel jaeggli Message-ID: <5637D854.2090203@bogus.com> Date: Tue, 3 Nov 2015 06:40:36 +0900 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: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="asJEkMLt27MBJDfVXFFvc028XWd3t45CR" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 21:40:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --asJEkMLt27MBJDfVXFFvc028XWd3t45CR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/3/15 1:02 AM, Liubing (Leo) wrote: > And pardon for my iteration again: this draft is NOT making any > formal recommendations, but some considerations to refer if you're > going to use ULAs. Were it completely neutral with respect to advice there would be little reason for it to exist. The sense that I got from the last time this was discussed, and perhaps this call is there may not be stomach to take this forward as the product of the working group. > Best regards, Bing >=20 > -----Original Message----- From: Liubing (Leo) Sent: Tuesday, > November 03, 2015 12:51 AM To: 'Alexandre Petrescu'; v6ops@ietf.org=20 > Subject: RE: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - > work or abandon? >=20 > Hi Dear Alex and all, >=20 > Speaking as a co-author. I wasn't in the v6ops session this > afternoon. And I'm sorry for the silence of the draft for a while, > but I do wish to continue working on it. >=20 > There was indeed lots of controversial discussion on it, but many of > them (even most of them) was just not directly regarding to the draft > itself (mostly the IPv6 NAT debate). For the draft, we heard few > negative comments, but much more positive comments that were in favor > of advancing it. Unfortunately, we didn't get the chance to WGLC, and > we also didn't get some essential feedback of how to improve it. So > the draft was kind of stuck there. No doubt it should be my > responsibility to approach it, but the WG's feedback is also very > important/helpful for us. >=20 > And thanks for Alex' response, you're more than welcome to contribute > on this draft. We can have some detailed discussion later to figure > out how to make an update. >=20 > For people who are in favor of advancing this draft, I expect very > much you could state your opinion on this. Many thanks to you all. >=20 > Best regards, Bing >=20 >=20 > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: > Monday, November 02, 2015 6:58 PM To: v6ops@ietf.org Subject: Re: > [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or > abandon? >=20 > Hello, >=20 > I would like to continue working on this draft. >=20 > I am not sure what is needed to continue working on this draft? Is > it ready to go as is? >=20 > The ULAs I consider are (1) in the core of enterprise PA+ULA network > slowly migrating to IPv6 and (2) in vehicles at manufacturing time. >=20 > In an enterprise network, I wonder whether ULAs coexist well with > IPv4 on a same VLAN, or must they be each on its own VLAN? Such as > to leave IPv4 continue exist well. I think a recommendation on this > is very valuable, at least to me. >=20 > Also, I wonder whether simply adding ULAs on interfaces of a > well-known router means that it will automatically turn on NAT66? (or > not?) Will the packets addressed to them from a PA-part of the > enterprise network be dropped by default? >=20 > More generally - what is the precise knob which blocks ULA-addressed > packets from leaking to the Internet? Is this a matter of a routing > protocol knob, like e.g. BGP having a definition of an area around > ULAs? Or is it a matter of on/off knob which allows/disallows > reaching a ULA in the network attached to a particular interface? Or > does it only depend of a trivial static route being present or absent > in the forward information base? >=20 > For ULAs in a vehicle, it is a bit early to describe the problems and > the needed advice, but I speculate there will be a need for this. We > have several drafts and implementations on this topic. >=20 > Alex >=20 > Le 02/11/2015 18:17, Howard, Lee a =E9crit : >> This document hasn=B9t had any revisions or discussion in a while. Is >> there anyone interested in working on it? >>=20 >> If we do not hear any interest, we will abandon this draft. >>=20 >> Thanks, Lee >>=20 >>=20 >> ________________________________ >>=20 >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >>=20 >> _______________________________________________ v6ops mailing list >> 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 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --asJEkMLt27MBJDfVXFFvc028XWd3t45CR 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 iEYEARECAAYFAlY32FUACgkQ8AA1q7Z/VrIrkgCfXg5ansD15wctfEeuRC+XAFbG 4CYAoIOB5LIEBILizOjmk6RzmOHozSm0 =DZUT -----END PGP SIGNATURE----- --asJEkMLt27MBJDfVXFFvc028XWd3t45CR-- From nobody Mon Nov 2 13:51: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 7ACC51A8833 for ; Mon, 2 Nov 2015 13:51:36 -0800 (PST) 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 zp5bTcJ004pW for ; Mon, 2 Nov 2015 13:51:35 -0800 (PST) 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 343E01A882D for ; Mon, 2 Nov 2015 13:51:35 -0800 (PST) Received: from mb-2.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA2LpWJJ077966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 21:51:33 GMT (envelope-from joelja@bogus.com) To: Philip Matthews , Alexandre Petrescu References: <563734D2.2@gmail.com> <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <5637DADF.8090308@bogus.com> Date: Tue, 3 Nov 2015 06:51:27 +0900 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: <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AMXVmbJRB4aNFH5KtlaqTTvw2lBXS06V" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 02 Nov 2015 21:51:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7AMXVmbJRB4aNFH5KtlaqTTvw2lBXS06V Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/2/15 7:52 PM, Philip Matthews wrote: > Can you explain a bit more what you mean by that? =20 > - Philip >=20 >=20 > On 2015-11-02, at 19:02 , Alexandre Petrescu wrote: >=20 >> Hello, >> >> With respect to the design-choices draft, I think it is worth to >> mention in the discussion that backwards compatibility is a 'pro' when= >> considering PA/PI/ULA schemes for enterprise networks. It is not a >> drawback. I'm not sure what is meant by backwards compatibility, there isn't any with respect to the ipv6 elements of the deployment. >> This (maintain IPv4 ok while migrating) is the most important >> requirement in the networks I work. dual stack deployment is a common operating modality and has been for a rather long time. there's definitely a tax to be payed with respect to resource usage, and complexity that doesn't exist in a v6 only network, but support of your existing model while building the new is incremental= =2E >> Alex >> _______________________________________________ >> 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 --7AMXVmbJRB4aNFH5KtlaqTTvw2lBXS06V 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 iEYEARECAAYFAlY32t8ACgkQ8AA1q7Z/VrJiHACeMfVq2LPn7a+Sqd222Kl8pLC5 Rm4AnRahDfut1i7vOeAaoZG6bblFr8BM =bBuB -----END PGP SIGNATURE----- --7AMXVmbJRB4aNFH5KtlaqTTvw2lBXS06V-- From nobody Mon Nov 2 14: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 AE5581A88D6 for ; Mon, 2 Nov 2015 14:15:42 -0800 (PST) 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 B_sMxDPC66Um for ; Mon, 2 Nov 2015 14:15:41 -0800 (PST) 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 505F21A88CB for ; Mon, 2 Nov 2015 14:15:41 -0800 (PST) Received: by pacfv9 with SMTP id fv9so167400358pac.3 for ; Mon, 02 Nov 2015 14:15:41 -0800 (PST) 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=HhFoc0iR7sUklq0qvcQEu3J8DGNhArC74eMAQM/J1wA=; b=Gj2nwvBvM9GtnvzhfLDPK55AGtGlv1mgAcwJT0l8qbMDuGTpWFGmcw514XwTOXYDEV PWZl3hrsSNfJ0mmFmPnvfQnXrywKS9aR9pZeImmrQQEnwuHTxkEQZbNjToHo1GjxiBMK SVRZXHoVpZLuT/RlK6W2AzpI4riVNdGaoNZkWLsOmlCGc8seS7i3puF5Fs0a/stfknqA 4t79yo1Lfy3A+Z/OEW5NIsrjf1cqKJjLJpJ8shN1uU+QZPpWAVkoo2Xtl0H5xhDuI/TC hg0XOZuc5anJfzk57lEo/YTwD22GYE75LcM9tz0fKoNIV2/aWP7Ib7NS0rK5mL03jLOn Rzwg== X-Received: by 10.66.102.101 with SMTP id fn5mr29062545pab.111.1446502541003; Mon, 02 Nov 2015 14:15:41 -0800 (PST) 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 cs5sm25868893pbc.15.2015.11.02.14.15.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:15:38 -0800 (PST) To: David Schinazi References: <824F2230-A92F-4587-81DD-9EE3418558B9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637E08A.9080207@gmail.com> Date: Tue, 3 Nov 2015 11:15:38 +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] draft-ietf-v6ops-host-addr-availability-01 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, 02 Nov 2015 22:15:42 -0000 On 02/11/2015 17:11, David Schinazi wrote: > Ran, > > Thanks for the support! > > The edits mentioned by Lorenzo during v6ops today were added to the draft this morning when we submitted -02. > > https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 Ship it like that, please. Brian From nobody Mon Nov 2 14: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 82B181A896C for ; Mon, 2 Nov 2015 14:26:58 -0800 (PST) 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 Phc5QzOr2kWs for ; Mon, 2 Nov 2015 14:26:57 -0800 (PST) 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 6ADCE1A8969 for ; Mon, 2 Nov 2015 14:26:57 -0800 (PST) Received: by pabfh17 with SMTP id fh17so36791364pab.0 for ; Mon, 02 Nov 2015 14:26:57 -0800 (PST) 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=kgkgeJ34o/W5YZcWg6nzVmEWz8wypqaXiXXZnwNUdXs=; b=s8z7ao57ziUAPLJIFFVSH888Wl83hqh9sinii0w+8+JChq3HNPVTQxNOei7hvnwFIe N6NLbiIKM3MnWBL+8T+aliQnQYIKVWOXp/C16Zu9GWb4xh4kdwvOiiCn431FD2/FRU0E TMVQzuWxl3+RxX6TsTSlAY0rdEjuBppWcV0TLI72HKSdFf2+6ZNobrc4Ao9UwgpbjNam lZeUGLt6t83OjR3wvNwRgGXS4liaEkDwsRHKLvFj2t7CzQfswAj1GrX3UZizOW8vKKdN UIKiCXb69B+mzK5ouXKA0zVbQI/pW54WVUFcDa1/udPe0lUysQGrTv0mT2WJRMsmc+G3 7Smw== X-Received: by 10.68.131.202 with SMTP id oo10mr29579027pbb.40.1446503217067; Mon, 02 Nov 2015 14:26:57 -0800 (PST) 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 xe9sm25900179pbc.4.2015.11.02.14.26.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:26:55 -0800 (PST) To: joel jaeggli , Philip Matthews , Alexandre Petrescu References: <563734D2.2@gmail.com> <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> <5637DADF.8090308@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637E32E.1020504@gmail.com> Date: Tue, 3 Nov 2015 11:26:54 +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: <5637DADF.8090308@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 02 Nov 2015 22:26:58 -0000 On 03/11/2015 10:51, joel jaeggli wrote: ... > dual stack deployment is a common operating modality and has been for a > rather long time. there's definitely a tax to be payed with respect to > resource usage, and complexity that doesn't exist in a v6 only network, > but support of your existing model while building the new is incremental. It seems to me that *this* draft should simply state that there are two main options for service continuity for IPv4 applications (dual stack or IPv4 as a service) but this is out of scope for the current document. Otherwise the draft will get bogged down for months. Brian From nobody Mon Nov 2 14:29: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 74C8E1A898F for ; Mon, 2 Nov 2015 14:29:30 -0800 (PST) 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 qIaiy9ih6NEw for ; Mon, 2 Nov 2015 14:29:29 -0800 (PST) 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 03C9C1A8972 for ; Mon, 2 Nov 2015 14:29:29 -0800 (PST) Received: by pacfv9 with SMTP id fv9so167707626pac.3 for ; Mon, 02 Nov 2015 14:29:28 -0800 (PST) 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=txrEojxkM8l6e/dEcwF2o0LKChAjlNz/iDiQp89iky0=; b=fVVspyA+1VJr14GYqqi+fTOzxiHkxqrf4bm1pUbEl3DKfgYjwEPGehv9mFwHLE3Lqn q+7Y9vFwFVBAFg2mVCXQ9sv9MblNoVmj3iOsktPBRyRXioolTzXCgX1rv1LyIsmPBp6O kMvObUvVCr+wUh0oYUlwGJhF5/cZRFLWNwGou4NclT3OpSXMp4CLvGp+1Xfhfjq+o0Wd ogLMHdKCZxv7Za2P6AcwhA/qGVBReFVh8bUVwcsVhPGeFaIjl+5zd3WvXrbfSa/ShUsA 89MobVOAoGSYRHZd0JrNlhjnv8MzQPVJN1Vss53NRI5c0CUeSOsiRIhuSCh4jvoe1i1a Xzfg== X-Received: by 10.66.255.66 with SMTP id ao2mr29251769pad.97.1446503368638; Mon, 02 Nov 2015 14:29:28 -0800 (PST) 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 hq1sm25865542pbb.43.2015.11.02.14.29.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:29:27 -0800 (PST) To: "Liubing (Leo)" , 'IPv6 Operations' References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319201@nkgeml506-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637E3C7.1030601@gmail.com> Date: Tue, 3 Nov 2015 11:29:27 +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: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319201@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem - work or abandon? 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, 02 Nov 2015 22:29:30 -0000 I think the draft should be polished and published. We've just had yet another discussion about the MO bits, which I found quite illuminating, but it shows that this document is actually needed. Regards Brian On 03/11/2015 05:00, Liubing (Leo) wrote: > Hi Dear all, >=20 > Speaking as a co-author. I do wish to continue working on it. >=20 > We actually had an essential revision around ietf93. We added more comp= rehensive test cases in that revision, but unfortunately we didn't get a = chance to present it in Prague. > Personally I believe the technical aspect of the draft is ready, but mi= ght need a final editorial/organization revision. >=20 > And please pardon me for iterating it again: this draft is not intended= to serve as a formal Problem Statement document, it is an informational = draft that captures current divergent behaviors of interpreting the M/O b= its by different operating systems. We believe it is valuable information= for network administrators. >=20 > I really hope you could state your opinion if you're in favor of advanc= ing the draft. >=20 > Best regards, > Bing=20 >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee > Sent: Monday, November 02, 2015 6:17 PM > To: 'IPv6 Operations' > Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem - work or abando= n? >=20 > This document hasn=C2=B9t had any revisions or discussion in a while. > Is there anyone interested in working on it? >=20 > If we do not hear any interest, we will abandon this draft. >=20 > Thanks, > Lee >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable pr= oprietary information, which is privileged, confidential, or subject to c= opyright belonging to Time Warner Cable. This E-mail is intended solely f= or the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified tha= t any dissemination, distribution, copying, or action taken in relation t= o the contents of and attachments to this E-mail is strictly prohibited a= nd may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any co= py of this E-mail and any printout. >=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 >=20 From nobody Mon Nov 2 14:48: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 8BAFE1A8A79 for ; Mon, 2 Nov 2015 14:48:48 -0800 (PST) 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 tNjZsgk7_kJV for ; Mon, 2 Nov 2015 14:48:45 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 C8C1F1A8A77 for ; Mon, 2 Nov 2015 14:48:45 -0800 (PST) Received: by pacfv9 with SMTP id fv9so168144045pac.3 for ; Mon, 02 Nov 2015 14:48:45 -0800 (PST) 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=j3vBr4a5c35WU9030Bb3302N0MGaMoKZ7hnPwoWAg7Q=; b=Q5Ly9xF93BefnXNop4vcr7ED5PQNrimQsRC/sqo0S4EHui7Lka1MlsIf76yvDFMCEk hjLfhadaE87Q2Ch4NeL97+t07gVps3r/9L3QNRucZjjSBZ3/BHxXiH/Q6f+eE5a2PXrZ y06g/EPT4UqH8amYnI8LIWms+ytOb2/Yo8xq1bmtvUhvmy5Fi6DFCKidwQieppazPT1a PXytSRNaBD5KNr4iGQcx3mLv1GJZ0lcl+5kyA8MDmMAxaYOOyx0dhjc/UIQOamoLbBFp 0iIUQwouGDnuDRGe9jkJOACFb/SxLCL0fVaTT8OavLo+7B3CJdBAy7z3QGtsjf1TLzMK b43Q== X-Received: by 10.66.248.137 with SMTP id ym9mr30146080pac.157.1446504525493; Mon, 02 Nov 2015 14:48:45 -0800 (PST) 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 im9sm25961610pbc.1.2015.11.02.14.48.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:48:44 -0800 (PST) To: joel jaeggli , "Liubing (Leo)" , "v6ops@ietf.org" References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637E84B.5090001@gmail.com> Date: Tue, 3 Nov 2015 11:48:43 +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: <5637D854.2090203@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 22:48:48 -0000 On 03/11/2015 10:40, joel jaeggli wrote: > On 11/3/15 1:02 AM, Liubing (Leo) wrote: >> And pardon for my iteration again: this draft is NOT making any >> formal recommendations, but some considerations to refer if you're >> going to use ULAs. >=20 > Were it completely neutral with respect to advice there would be little= > reason for it to exist. We have this feature in IPv6. It seems a bit odd that there's nothing beyond the bare bones in RFC 4193 that talks about it. "Here are the things you need to think about" seems like useful content to me. > The sense that I got from the last time this was discussed, and perhaps= > this call is there may not be stomach to take this forward as the > product of the working group. Well, there was when the WG adopted it. What I don't think has anything like consensus is any statement that it's a good or bad choice to use ULAs. So I'd like to see this continue, purely as an FYI document. Brian >=20 >> Best regards, Bing >> >> -----Original Message----- From: Liubing (Leo) Sent: Tuesday, >> November 03, 2015 12:51 AM To: 'Alexandre Petrescu'; v6ops@ietf.org=20 >> Subject: RE: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - >> work or abandon? >> >> Hi Dear Alex and all, >> >> Speaking as a co-author. I wasn't in the v6ops session this >> afternoon. And I'm sorry for the silence of the draft for a while, >> but I do wish to continue working on it. >> >> There was indeed lots of controversial discussion on it, but many of >> them (even most of them) was just not directly regarding to the draft >> itself (mostly the IPv6 NAT debate). For the draft, we heard few >> negative comments, but much more positive comments that were in favor >> of advancing it. Unfortunately, we didn't get the chance to WGLC, and >> we also didn't get some essential feedback of how to improve it. So >> the draft was kind of stuck there. No doubt it should be my >> responsibility to approach it, but the WG's feedback is also very >> important/helpful for us. >> >> And thanks for Alex' response, you're more than welcome to contribute >> on this draft. We can have some detailed discussion later to figure >> out how to make an update. >> >> For people who are in favor of advancing this draft, I expect very >> much you could state your opinion on this. Many thanks to you all. >> >> Best regards, Bing >> >> >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: >> Monday, November 02, 2015 6:58 PM To: v6ops@ietf.org Subject: Re: >> [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or >> abandon? >> >> Hello, >> >> I would like to continue working on this draft. >> >> I am not sure what is needed to continue working on this draft? Is >> it ready to go as is? >> >> The ULAs I consider are (1) in the core of enterprise PA+ULA network >> slowly migrating to IPv6 and (2) in vehicles at manufacturing time. >> >> In an enterprise network, I wonder whether ULAs coexist well with >> IPv4 on a same VLAN, or must they be each on its own VLAN? Such as >> to leave IPv4 continue exist well. I think a recommendation on this >> is very valuable, at least to me. >> >> Also, I wonder whether simply adding ULAs on interfaces of a >> well-known router means that it will automatically turn on NAT66? (or >> not?) Will the packets addressed to them from a PA-part of the >> enterprise network be dropped by default? >> >> More generally - what is the precise knob which blocks ULA-addressed >> packets from leaking to the Internet? Is this a matter of a routing >> protocol knob, like e.g. BGP having a definition of an area around >> ULAs? Or is it a matter of on/off knob which allows/disallows >> reaching a ULA in the network attached to a particular interface? Or >> does it only depend of a trivial static route being present or absent >> in the forward information base? >> >> For ULAs in a vehicle, it is a bit early to describe the problems and >> the needed advice, but I speculate there will be a need for this. We >> have several drafts and implementations on this topic. >> >> Alex >> >> Le 02/11/2015 18:17, Howard, Lee a =C3=A9crit : >>> This document hasn=C2=B9t had any revisions or discussion in a while.= Is >>> there anyone interested in working on it? >>> >>> If we do not hear any interest, we will abandon this draft. >>> >>> Thanks, Lee >>> >>> >>> ________________________________ >>> >>> This E-mail and any of its attachments may contain Time Warner >>> Cable proprietary information, which is privileged, confidential, >>> or subject to copyright belonging to Time Warner Cable. This E-mail >>> is intended solely for the use of the individual or entity to which >>> it is addressed. If you are not the intended recipient of this >>> E-mail, you are hereby notified that any dissemination, >>> distribution, copying, or action taken in relation to the contents >>> of and attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Nov 2 15:02: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 5E6201A8AF5 for ; Mon, 2 Nov 2015 15:02:12 -0800 (PST) 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, 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 LYCGcXDnk1Aw for ; Mon, 2 Nov 2015 15:02:07 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 486761A8AF1 for ; Mon, 2 Nov 2015 15:02:07 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 2 Nov 2015 17:02:06 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f171.google.com [209.85.213.171] #+LO+TS+TR X-Umn-Classification: local Received: by igpw7 with SMTP id w7so58570811igp.1 for ; Mon, 02 Nov 2015 15:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=cGxM63vDwhd0D7dvZrNT6jw6Ya07LqVSz+Mcl7XI7dM=; b=POV/AZSV8fH3+5eG8YJ6P4WVtPNHAn4n15+kZQ0SATVUQhzcgBQdRNO9GrRwn97Dl/ E64mYN5K4RysszMBarETUyr45d+ziHtOVVtJueqTA1F7g9cN5KaZrq9OgdeDWBaVFkSh 6Sjf9SpfRinSQO0Rn3Jes/DSyirXWS4nEzy1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=cGxM63vDwhd0D7dvZrNT6jw6Ya07LqVSz+Mcl7XI7dM=; b=VziM50n7l9BZpvp4PYnHtruRPbOjiMqxg4CdKdtn8kf7P3WB/5KLzi3ZI+3pMODQ15 aLUYPbWquaDzyfHn6y0o4qZerkk01Usllshc1zJzZFiJz/wzSwY9cMxXfEKqtk/BivWz VFutkY/t0duW9fNJ8CX0cItL83J4ELOeTq7LnljWcz31HP5x06JMqNrZbCOowerK3Qma WJTA+16UubjQPf4KVcx9MXHatAn+9SxKzfvkA+KIzu3Co0hEZFTcsFTG+aanVVSMfmvS fnmqjAUX2S0UhHgDVx+dXg/s25tiEms1b3tE2J0U4GbQ2yNSbD/0TOrCSXjiyiV66zg4 +wBg== X-Gm-Message-State: ALoCoQludGMmbuxxoWKEAsk+XYDULL4BbC0gJZ7BQ703orLeKK0umtqmNEm6DcuKdSmvj9Nm+HhdV57AZNtBRRabPzx+2O2CPF9PmEHia7jTutDCMQ1oqweTCpOGFrVtMV85EZugqMHV X-Received: by 10.50.20.74 with SMTP id l10mr14256291ige.2.1446505325542; Mon, 02 Nov 2015 15:02:05 -0800 (PST) X-Received: by 10.50.20.74 with SMTP id l10mr14256262ige.2.1446505325285; Mon, 02 Nov 2015 15:02:05 -0800 (PST) Received: from x-10-104-143-11.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:9432:866:7fc4:a980]) by smtp.gmail.com with ESMTPSA id lo2sm6705601igb.17.2015.11.02.15.02.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 15:02:04 -0800 (PST) References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> To: Brian E Carpenter , joel jaeggli , "Liubing (Leo)" , "v6ops@ietf.org" From: David Farmer Organization: University of Minnesota Message-ID: <5637EB69.1080608@umn.edu> Date: Mon, 2 Nov 2015 17:02:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5637E84B.5090001@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 23:02:12 -0000 On 11/2/15 16:48 , Brian E Carpenter wrote: > On 03/11/2015 10:40, joel jaeggli wrote: >> On 11/3/15 1:02 AM, Liubing (Leo) wrote: >>> And pardon for my iteration again: this draft is NOT making any >>> formal recommendations, but some considerations to refer if you're >>> going to use ULAs. >> >> Were it completely neutral with respect to advice there would be little >> reason for it to exist. > > > We have this feature in IPv6. It seems a bit odd that there's nothing > beyond the bare bones in RFC 4193 that talks about it. "Here are the > things you need to think about" seems like useful content to me. +1 We need a document that discussed the pluses and minuses of ULA, there are many misconceptions about them and a lot of the world is starting to actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6 tool box, and tell people how to use the tool. Or, we need to find the consensus to make it go ULA a way. >> The sense that I got from the last time this was discussed, and perhaps >> this call is there may not be stomach to take this forward as the >> product of the working group. > > Well, there was when the WG adopted it. What I don't think has anything > like consensus is any statement that it's a good or bad choice to use > ULAs. > > So I'd like to see this continue, purely as an FYI document. Yes, Please -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Nov 2 15:37: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 6EC111A90A5 for ; Mon, 2 Nov 2015 15:37:57 -0800 (PST) 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 kEljyqIrY3tl for ; Mon, 2 Nov 2015 15:37:55 -0800 (PST) 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 C20E81A9093 for ; Mon, 2 Nov 2015 15:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2749; q=dns/txt; s=iport; t=1446507475; x=1447717075; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lYJZc5eWEr3GNcoHpyRghKLjUlkKmQQHqCFVuJ2lHgw=; b=D67W86/PXjS2J+D57gxoCnVW/Go8LpKiuELpCUi6jX5eK4hikTbeUhRE 7niY+DBM2t/odFQeD43Kb2rBjfoJUpWw6sV41EQrjNacsfHmWhBBIrGlV pSmWgRGvNFhItakAyGHU1hA1KpcxT0H1JNBdokcRFKQcdq2KTXYDuAr0x Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DkAgBs8zdW/4sNJK1eDoMtgUIGv0AOgVqGGQKBNjgUAQEBAQEBAYEKhDUBAQEDAXkFCwIBCBguMiUCBA4FDogaCMFnAQEBAQEBAQEBAQEBAQEBAQEBAQEQCYkHgm6ILIEUAQSWQwGCUYFhiHKcOgEfAUOCER2BGD5yhHeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,236,1444694400"; d="asc'?scan'208";a="43243911" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2015 23:37:37 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tA2Nbb89023222 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 23:37:37 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; Mon, 2 Nov 2015 18:37:36 -0500 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; Mon, 2 Nov 2015 18:37:36 -0500 From: "Fred Baker (fred)" To: David Farmer Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFcd0foI3scejF0qfprMVih9FcQ== Date: Mon, 2 Nov 2015 23:37:36 +0000 Message-ID: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> In-Reply-To: <5637EB69.1080608@umn.edu> 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.235.76] Content-Type: multipart/signed; boundary="Apple-Mail=_595B1AAA-A1B9-47BD-9BC3-59538703C426"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 02 Nov 2015 23:37:57 -0000 --Apple-Mail=_595B1AAA-A1B9-47BD-9BC3-59538703C426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 3, 2015, at 8:02 AM, David Farmer wrote: >=20 > +1 We need a document that discussed the pluses and minuses of ULA, = there are many misconceptions about them and a lot of the world is = starting to actually deploy IPv6. ULA needs to be acknowledged as part = of the IPv6 tool box, and tell people how to use the tool. Or, we need = to find the consensus to make it go ULA a way. Concur. The confusion actually showed up in the discussion of "Design = Choices" yesterday, in the statement made in that draft that "RFC 1918 = and ULA addresses are different, but are used in the same way." Both types of addresses can be used in a network that doesn't attach to = the Internet, or for purposes (such as modems in a Cable Modem network) = that need to be reachable for the purposes of the network itself but = specifically not reachable from outside of it. That was what Viktor told = me was meant by "used in the same way". However, RFC 1918 addresses, by and large, are used behind NATs and = translated at a border, while that is not a capability widely supported = in v6ops. That's an important difference, likely to be an early thought = in the mind of an IPv4 operator wanting to mirror his/her IPv4 design in = IPv6. It's something that would want to be redesigned. That difference should be said somewhere, and the issues pro and con = discussed. --Apple-Mail=_595B1AAA-A1B9-47BD-9BC3-59538703C426 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 iQIVAwUBVjfzvUayAOS/EQ8MAQIQ6BAAxd2LbZyIGDkTjgHHy8RI4/wWkxJonO3l BhfF8gP4J0XNAoXds7EQNsYtzBa2lNXrbtJJfiEORUkYneer740X80T1EDKF7aPs 0Fvhk2SigygMrGF9ajB7PKelhgpd2xeUPoxpBszbukcLZBxJkUVFKRZP3YM4WFAF ym/PzzGr2M6Ty1bhDTma9RF8tWCPpKsQE2PzOUBeOyKn2ZK2Xdt954+/cjjWybZN giss5F77JT6PsTcNXVziUxFV672zLjbBlNHC9UuOftYTN9Jb9cFH13MqglUEqZaC bHUQjGB3pMaq9nls/b8TQE7hz/ZC6YsPWCCxWV7o0XFlJNnL+U+JOTaKwb9qXzM7 3QsD9NIf47mkm/tgv1S+2NYbXQUHGB1cMwoWvV7sr95HkTlfoDiPEraBw2SolaNF YYT4hdJXmicXe4Q0tDGqSWrTKCrqnV2S9/+KrRUTNCBOdVv1cskJk+3FpDr/wlr4 BkMlOpyYKYvTUMon0tPaRRmQEyJMU/qWFFWAItxZcuQlghbm+H0jtX75fYIK0ly6 PoMz49Evub1LlydBhiL6t3dI/a5x+u/S9bmaum+cWkJR0C+WTZKBmjUOM8SFyInJ ItoBQdm4JNaWGqlSeETRzIRb+Ngq8C21ae+uUlbaYJV3Nyt2CQXU6c9NDo4WsoRI 1Eu8RHEkRKw= =xCHM -----END PGP SIGNATURE----- --Apple-Mail=_595B1AAA-A1B9-47BD-9BC3-59538703C426-- From nobody Mon Nov 2 15:59: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 413F11A9128 for ; Mon, 2 Nov 2015 15:59:13 -0800 (PST) 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 qDsS1twCxSKJ for ; Mon, 2 Nov 2015 15:59:11 -0800 (PST) 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 0E1011A9127 for ; Mon, 2 Nov 2015 15:59:11 -0800 (PST) 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 tA2NxDHq001080; Mon, 2 Nov 2015 15:59:13 -0800 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA2Nx83o001059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 15:59:08 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.13]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 15:59:05 -0800 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjug Date: Mon, 2 Nov 2015 23:59:04 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> In-Reply-To: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.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] draft-ietf-v6ops-host-addr-availability discussion 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, 02 Nov 2015 23:59:13 -0000 I have one text addition suggestion and one question. On P. 7, in Table 1, suggest adding a new final row as follows: requires DAD Yes Yes No = N/A=20 Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA must use DAD to check for duplicates on the link they were obtained. In a multi-addressing environment where millions of addresses are required, this could amount to a substantial amount of DAD multicast traffic. On the other hand, DAD is not needed for DHCPv6 PD because the network has unambiguously delegated the prefix for the node's exclusive use. I have a question also on table 1. Under ""Unlimited" endpoints", why does it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a pre= fix obtained by DHCPv6 PD can be used to configure an unlimited number of addresses on the link over which the prefix was received. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Sunday, November 01, 2015 9:16 PM > To: v6ops@ietf.org > Subject: [v6ops] draft-ietf-v6ops-host-addr-availability discussion >=20 > In the discussion this morning, we wound up in a position that I could no= t call "consensus", even "rough consensus", but per a hum of > those in the room, within shouting distance of achieving that. Several pe= ople spoke at the mike asking for a sentence or brief > discussion to be added, or a section clarified. >=20 > In the interest of expediency, let me ask those who spoke (and anyone els= e that has an issue) to respond to this note (copying the > list) with suggested text. It might be best if this is stated as >=20 > OLD TEXT > the text that should be replaced goes here > NEW TEXT > the text that should replace it goes here >=20 > or >=20 > LOCATION > identify the section the text should go into > PROPOSED TEXT > the text that should be added goes here >=20 > I'll permit the authors to declare suggested text out of scope; some of t= he discussion this morning left them commenting on scope > and scope creep. However, I do ask them to justify the exclusion to the l= ist, rather than just ignore the email. >=20 > This comment period ends 15 November. From nobody Mon Nov 2 16:02: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 35F551A9126 for ; Mon, 2 Nov 2015 16:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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_SE=0.35, 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 WqYaOvODsdAq for ; Mon, 2 Nov 2015 16:02:41 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1A61A912A for ; Mon, 2 Nov 2015 16:02:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A2401A2; Tue, 3 Nov 2015 01:02:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1446508959; bh=VJaSPJRGN+Rr/QfhpkVca7eu9B79Afwy6CnrvI6NJaI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ylrXS3IdVL3JGwOkV/ya9nj5ZC9FlEtP/PIe3XjhaAWUiDXZ7I3BQGuFCoW73QqBt lzy79m3uXjMuWtJ2Sn1znliDQbAUDlZ2U6iXZSDDa0iKziLARnx2T5FzIiuRIB+ODb Sp5Ab4N0MJbWzHP78ULva2D2nWBPFkIYVroN9U+I= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9AAADA1; Tue, 3 Nov 2015 01:02:39 +0100 (CET) Date: Tue, 3 Nov 2015 01:02:39 +0100 (CET) From: Mikael Abrahamsson To: Havard Eidnes In-Reply-To: <20151102.105228.439899806.he@uninett.no> Message-ID: References: <20151102.105228.439899806.he@uninett.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Tue, 03 Nov 2015 00:02:44 -0000 On Mon, 2 Nov 2015, Havard Eidnes wrote: > Therefore I'm suggesting the more unambigious "shorter/longer prefix" as > preferable. I did some research, so perhaps we can take inspiration from: https://www.ietf.org/rfc/rfc2317.txt "One of the problems encountered when assigning a longer prefix (less address space) is that" ... and then use shorter/longer throughout the document? Just to give an introduction to the reader who might not be 100% sure what "longer prefix" means? ... and I guess I just need to figure out some rule of thumb for myself to remember what shorter/longer means. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Nov 2 16:07: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 67ACB1A914F for ; Mon, 2 Nov 2015 16:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] 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 bJ-eRym5SNSx for ; Mon, 2 Nov 2015 16:07:23 -0800 (PST) Received: from tor-smtp-06.primus.ca (smtp-auth-2.primus.ca [67.230.159.2]) by ietfa.amsl.com (Postfix) with ESMTP id B3F641A9153 for ; Mon, 2 Nov 2015 16:07:21 -0800 (PST) Received: from i223-218-131-39.s41.a014.ap.plala.or.jp ([223.218.131.39] helo=[192.168.2.100]) by tor-smtp-06.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZtP8C-0004m4-Gs; Mon, 02 Nov 2015 19:07:20 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <5637E32E.1020504@gmail.com> Date: Tue, 3 Nov 2015 09:06:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE6D3AE-8E99-43D4-8A01-91A7C6168446@magma.ca> References: <563734D2.2@gmail.com> <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> <5637DADF.8090308@bogus.com> <5637E32E.1020504@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - i223-218-131-39.s41.a014.ap.plala.or.jp ([192.168.2.100]) [223.218.131.39] Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 03 Nov 2015 00:07:24 -0000 The draft is explicitly about IPv6-only and dual-stack networks, and it = seems to me that even mentioning IPv4-as-a-service is not really = necessary.=20 - Philip On 2015-11-03, at 7:26 , Brian E Carpenter wrote: > On 03/11/2015 10:51, joel jaeggli wrote: >=20 > ... >> dual stack deployment is a common operating modality and has been = for a >> rather long time. there's definitely a tax to be payed with respect = to >> resource usage, and complexity that doesn't exist in a v6 only = network, >> but support of your existing model while building the new is = incremental. >=20 > It seems to me that *this* draft should simply state that there are > two main options for service continuity for IPv4 applications (dual > stack or IPv4 as a service) but this is out of scope for the current > document. Otherwise the draft will get bogged down for months. >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Nov 2 16:15: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 948721A9251 for ; Mon, 2 Nov 2015 16:15:14 -0800 (PST) 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, 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 E-wn8qQdYWeH for ; Mon, 2 Nov 2015 16:15:13 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 11F221A924A for ; Mon, 2 Nov 2015 16:15:12 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 2 Nov 2015 18:15:06 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f170.google.com [209.85.213.170] #+LO+TS+TR X-Umn-Classification: local Received: by igdg1 with SMTP id g1so69400147igd.1 for ; Mon, 02 Nov 2015 16:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=0eCm1sKT3qPjQ6rLFB5Ad0UuZ17vARhN9pNPilmqp4Y=; b=cC8DfYwx6M+ycpUc6mFVN+8sDQzsO3HeIbGsJfkJnTluKJIZAOx/Wy+5xKOMqyNeGv 88D+Fd1QSiYJNiFwlL0+eWxbHSO+j6U0E31UB0zRL53NTGr+OAFYySF9iPDOV64tMvY0 emqkgayig/ZNRXS6GNLywJUXeO6jbciMlNUgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=0eCm1sKT3qPjQ6rLFB5Ad0UuZ17vARhN9pNPilmqp4Y=; b=kMNPcq76oz8CBaLHEvXukV87g4QgnuMWg8k4Cj6+QhEBfjtXC6QloNMNX8L9kFJ+Tk 5qmg11YqaIO2GD5jdF75Yxdsf3Fdb55mRi1YYV0PIJVOQn4CK1+aBbFDMh1vGJAwKUrK MHzquEIGXdV/3q2FeUDuK8npR3GZ0NCB97m9LQwmDFX7p8W+zkwsE2eN1CrIbuW5BCJS RkBofU/YEmvg9QDF0ml7d6yxzIuTUMmcKBF5M2B4zsqmAz76hAkXonPYDN8jp0bKqQ8M VqBzkJpEIE6sU+ZJNNyC2Fdx43lrIU40KwRrWertRyZWR/fivzETHrfq3cSHVoPcM3g6 GEeQ== X-Gm-Message-State: ALoCoQnyGVS/yn0GYfG7KbA+CftSiAh3LRlQ/rJFZOt5iOHWvWu/+ugXN1KvxtIShbqz7VS7GCDWbHwrz5tmwV3y6DZS+W4+RNlCYxPw5p1FMQTG9YXzF+BjrStOAAijwKwwlBFikMP4 X-Received: by 10.50.79.201 with SMTP id l9mr14679521igx.60.1446509706318; Mon, 02 Nov 2015 16:15:06 -0800 (PST) X-Received: by 10.50.79.201 with SMTP id l9mr14679507igx.60.1446509706119; Mon, 02 Nov 2015 16:15:06 -0800 (PST) Received: from x-10-104-143-11.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:9432:866:7fc4:a980]) by smtp.gmail.com with ESMTPSA id g1sm8652264ioe.5.2015.11.02.16.15.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:15:04 -0800 (PST) References: <20151102.105228.439899806.he@uninett.no> To: Mikael Abrahamsson , Havard Eidnes From: David Farmer Organization: University of Minnesota Message-ID: <5637FC84.8090509@umn.edu> Date: Mon, 2 Nov 2015 18:15:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:15:14 -0000 On 11/2/15 18:02 , Mikael Abrahamsson wrote: > On Mon, 2 Nov 2015, Havard Eidnes wrote: > >> Therefore I'm suggesting the more unambigious "shorter/longer prefix" >> as preferable. > > I did some research, so perhaps we can take inspiration from: > > https://www.ietf.org/rfc/rfc2317.txt > > "One of the problems encountered when assigning a longer prefix (less > address space) is that" > > ... and then use shorter/longer throughout the document? Just to give an > introduction to the reader who might not be 100% sure what "longer > prefix" means? > > ... and I guess I just need to figure out some rule of thumb for myself > to remember what shorter/longer means. I've thought all along longer/shorter is the right way to go. But adding a parenthetical on the first use of longer and shorter, doesn't seem to be asking too much and would seem to add some clarity. So +1. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Nov 2 16:20: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 8ABC01A9165 for ; Mon, 2 Nov 2015 16:20:38 -0800 (PST) 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 57jOjwhrcXvN for ; Mon, 2 Nov 2015 16:20:36 -0800 (PST) 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 BA9E11A92DC for ; Mon, 2 Nov 2015 16:20:36 -0800 (PST) Received: by pabfh17 with SMTP id fh17so986959pab.0 for ; Mon, 02 Nov 2015 16:20:36 -0800 (PST) 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=bOfK7MxuDgtlLy9jRuh0pPCq3En6qgzcSYt/eg3bFbs=; b=jzYwJGIp/R+uwHvdy1RVw10UfqSm9qnHcmCvlIjvMHjI+lbshFs0QrGn29/E7jXGjZ 0JwRbfNOegBQFSzh36ZmKnFpfEuFP9SnH/ooTtu+ApL28Wtk6A+fWQ94150TcfIV+HuT ggSkyjJa5RxM6w0cu/q7sm2eAoHVBWGKxbQrfwHE9ykqeBZIRPuPfCZiT/rnFqBYxBy6 szyZTCHg8lmi65SjK7OyCaeWq6vGVrOPdtjzDI2oNubrq5IoDkTx6DW3gC3amRScm4ZC gT+Ye2R0dOrzS/qOyv0D3XIbWUHKSByzsfeEgwX0bRf/R6SpvkSa/NtLbqO8hAqthQ6w T7ug== 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=bOfK7MxuDgtlLy9jRuh0pPCq3En6qgzcSYt/eg3bFbs=; b=MbvSPyZXmorZ73I+XDVFoHO7t7unkLW7iHX+mnPhMgrZrW2Kw3iUeL2ujh63WnPT++ Sz2+HZyzO/zZkiGzRHptQYtr2Fq6joj6PCaeUmq7kC2K7D44vL5gSTlSt6ToxD7WpGyN PzP7MjldBO25D9mHKnMyYFUODhDw1AQgAEXx9U6SEo7sC/dg2nsPhG5tTEm6xfPBAiWL 43YuAgjTtoWU8Y+pAff2a5+e3bS9hIhAUPS6qi5LKzzpZaz0FSrhgr+acxdZk6iWIkom /aCBytrYeZDq9YjgbKVy/eAVbhgdvg+WBF7O3xt0jL99/sbeIUQ5llRtDGxE7lANeCvo 4iTw== X-Gm-Message-State: ALoCoQlKIHFwkJztQnEWZ/uDzFeCx9syLloq69xIF64cuNlLS2ELkcYx2X9Yw6vEIPDa0R7wt4bH X-Received: by 10.66.218.129 with SMTP id pg1mr30369685pac.156.1446510036385; Mon, 02 Nov 2015 16:20:36 -0800 (PST) Received: from ?IPv6:2001:c40::3032:ad65:a656:9a00:921a? (t20010c4000003032ad65a6569a00921a.v6.meeting.ietf94.jp. [2001:c40:0:3032:ad65:a656:9a00:921a]) by smtp.googlemail.com with ESMTPSA id st5sm26216028pab.42.2015.11.02.16.20.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:20:35 -0800 (PST) To: "Howard, Lee" , 'IPv6 Operations' References: From: Victor Kuarsingh Message-ID: <5637FDD0.70300@jvknet.com> Date: Tue, 3 Nov 2015 09:20:32 +0900 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: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 00:20:38 -0000 WG, My input is that we should continue this work. Given ULAs are already in use, having a document which outlines those use cases is, in my mind, operationally beneficial. Perhaps we should be more clear that we would not be recommending the use of ULAs, but keep to a unbiased document which outlines how they have been used (just a use case discussion). We can also include objective technical points as to the pros/cons related to each use case. It was also noted in another email (based on WG v6ops discussion yesterday), that one such valid example was Cable Modem management IPs assigned ULA based addressing. This is a valid technical use case. I am willing to help if required on this document. regards, Victor K On 2015-11-02 6:17 PM, Howard, Lee wrote: > This document hasnąt had any revisions or discussion in a while. > Is there anyone interested in working on it? > > If we do not hear any interest, we will abandon this draft. > > Thanks, > Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 2 16:28: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 670A51ABC75 for ; Mon, 2 Nov 2015 16:28:31 -0800 (PST) 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 vnx3fliHEzug for ; Mon, 2 Nov 2015 16:28:30 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 E83BC1A9302 for ; Mon, 2 Nov 2015 16:28:29 -0800 (PST) Received: by ykek133 with SMTP id k133so957388yke.2 for ; Mon, 02 Nov 2015 16:28:29 -0800 (PST) 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=izhHh86ZnxqZJPVOvhYaUP69KKiE3B9knnI2CXa0gdY=; b=FbgheZbrzoOgSnMDsb5je8504HQ+n/FmwmD0yr3ju8bG9H/W10tWjnp1XHn80I1h5L DP3UTx5uP8TRp39w1SEpbD97NdlJwqqvJWH9KWH+F/yLBYwIfB+COn+13ESQ0/D21cH8 7I08I6jxrI2WhdSZ33wsvVk4tcde7FhtoQJMZACBsqm2RUOgZkq9ve1htXsg2M+3sAOD 5wpi1Ro0AygoYG6c5WSPu4udPw3Q8riYVPeJeHAhyFOUZG3Ego/2Nn8Vx4R4U0HReuOt pHP2FPF2/s0YfeN0NqEuLH98bVuhbFvjiGqrTDU1/jEynMaP4qOnVNfTVjPuYEQuB0lc n9VQ== 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=izhHh86ZnxqZJPVOvhYaUP69KKiE3B9knnI2CXa0gdY=; b=eGf5pYLXRY39w+MMuzcr9e8CBQkKeopKlUUMQxmsSqXFZ2btF7Gv6MXcRAa864lSvl 8d56/2aeP3bBhQ5brSHBUexmD8PuJMO0mCVQlXwXC+7YirLWpVwlcawzmDOlQzr0q54Z P56PO95zofYHVEgm3HQDWtiNpxH0KE7fMdv3ODjn09e0wg7uNMWFsLCEVbhhZ8vuXSng B8T99ms5tsfXVMv6HBBBPn069HqjvhTX3JIZ06kho5tw384X0rcrGMvEMt8PqCmcX1GR M1gxYW6KRx2/+Eb0+aP73RSL0uBwx8Zyjdq3WFxpw6BsaGn/eBLSYP17peeeNBcffBAK /HDQ== X-Gm-Message-State: ALoCoQnBLOmcgGGr1h/LBf6XzRan2so1vhPHJ1RN92JZgILev/8k7pfA/9LwbvcW9Hl0Fx8SixOu X-Received: by 10.129.83.87 with SMTP id h84mr20966160ywb.156.1446510509089; Mon, 02 Nov 2015 16:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 16:28:09 -0800 (PST) In-Reply-To: <5637401A.1050807@gmail.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <5637401A.1050807@gmail.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 09:28:09 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114d8dae0f4cb8052397f99d Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 00:28:31 -0000 --001a114d8dae0f4cb8052397f99d Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 7:51 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > The right recommendation is the following: > > "in a 3GPP network which uses exclusively SLAAC for IPv6 address > configuration on the UE the network must not limit its ability to set > multiple distinct IPv6 prefixes in a RA to the UE. By default there > should be two." > On 3GPP there is only one Prefix Information Option in the RA - http://tools.ietf.org/html/rfc6459#section-5.2 . We can't change that because the behaviour is defined by 3GPP, not IETF. We might be able to ask 3GPP to change it, but I don't think this document is the place to do that. 3GPP networks already fulfill the spirit of this draft by providing an entire /64 to each device. This is not a good example either. One wouldn't give an INFORMATIONAL > document as a recommendation to follow. > It's not a recommendation to follow, it's just an example of how having multiple addresses can allow future applications. An example of how the availability of multiple addresses per host has > already stimulated successful new applications: > [...] > o tethering. In tethering a UE such as a smartphone connects > several IP devices on its LAN through the access network and to > the Internet. This is realized with DHCPv6-PD [AERO] or some > other techniques like "/64 sharing" [RFC7278] or other forms of > bridging. > I'm not sure that tethering is a good example for this section. It's existed for a long time, so it's not really a new application, and we already mention it in an earlier section in the draft. --001a114d8dae0f4cb8052397f99d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 2, 2015 at 7:51 PM, Alexandre Petrescu <alexandre.petre= scu@gmail.com> wrote:
The right recommend= ation is the following:

"in a 3GPP network which uses exclusively SLAAC for IPv6 address
=C2=A0configuration on the UE the network must not limit its ability to set=
=C2=A0multiple distinct IPv6 prefixes in a RA to the UE.=C2=A0 By default t= here
=C2=A0should be two."

On 3GPP ther= e is only one Prefix Information Option in the RA - http://tools.ietf.org/html/rfc6459#sect= ion-5.2 . We can't change that because the behaviour is defined by = 3GPP, not IETF. We might be able to ask 3GPP to change it, but I don't = think this document is the place to do that. 3GPP networks already fulfill = the spirit of this draft by providing an entire /64 to each device.

This is not a good example either.=C2=A0 One = wouldn't give an INFORMATIONAL document as a recommendation to follow.<= br>

It's not a recommendation to follow= , it's just an example of how having multiple addresses can allow futur= e applications.

=C2=A0 =C2=A0An exampl= e of how the availability of multiple addresses per host has
=C2=A0 =C2=A0already stimulated successful new applications:
[...]
=C2=A0 =C2=A0o=C2=A0 tethering.=C2=A0 In tethering a UE such as a smartphon= e connects
=C2=A0 =C2=A0 =C2=A0 several IP devices on its LAN through the access netwo= rk and to
=C2=A0 =C2=A0 =C2=A0 the Internet.=C2=A0 This is realized with DHCPv6-PD [A= ERO] or some
=C2=A0 =C2=A0 =C2=A0 other techniques like "/64 sharing" [RFC7278= ] or other forms of
=C2=A0 =C2=A0 =C2=A0 bridging.

I'm = not sure that tethering is a good example for this section. It's existe= d for a long time, so it's not really a new application, and we already= mention it in an earlier section in the draft.
--001a114d8dae0f4cb8052397f99d-- From nobody Mon Nov 2 16:46: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 5E6B21AC3CD for ; Mon, 2 Nov 2015 16:46:09 -0800 (PST) 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 pwl8NBCBwysL for ; Mon, 2 Nov 2015 16:46:08 -0800 (PST) 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 8F08D1AC3E2 for ; Mon, 2 Nov 2015 16:46:07 -0800 (PST) Received: by pasz6 with SMTP id z6so1479275pas.2 for ; Mon, 02 Nov 2015 16:46:07 -0800 (PST) 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=EdrJECv2cGXF30dKVLB8ZYTd8h+t6TGiLfre9Lw4dPU=; b=ITcfBh20l21yJzcp+Ky0CyhEwv/Xd7adq97Lh6MiXzpJROcePd+RZQ3qlI4+MI2QDB xWzIsD+o3wA5McN6BA8v60qBazXIhENnKS46p0kZ4fa1ZBJiXoLQOuJ6mvrWG5JJAf6F tWlxwd/o9LQuTmWU26E5XZqCAp1ByqGtWCCAVUx4pdasYJGEGITrW+L4NrAZbeoLIsYI 4DlkRKqN49tntZaNsDFy6f2AAJzPry629h3loxLJ/wROlYwruY/Gs2PBWfwUFuXtI5cw iVxIcbID7a4b1J8Kj0sz4wymL+PQUG1fg/AoPp+wLUUkrU7ApA+xaZedHTpGMSUVv+4P MgOQ== X-Received: by 10.69.11.97 with SMTP id eh1mr30498865pbd.71.1446511567249; Mon, 02 Nov 2015 16:46:07 -0800 (PST) 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 sz9sm26259166pab.13.2015.11.02.16.46.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:46:06 -0800 (PST) To: Philip Matthews References: <563734D2.2@gmail.com> <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca> <5637DADF.8090308@bogus.com> <5637E32E.1020504@gmail.com> <9DE6D3AE-8E99-43D4-8A01-91A7C6168446@magma.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563803CD.9080103@gmail.com> Date: Tue, 3 Nov 2015 13:46:05 +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: <9DE6D3AE-8E99-43D4-8A01-91A7C6168446@magma.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09 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, 03 Nov 2015 00:46:09 -0000 On 03/11/2015 13:06, Philip Matthews wrote: > The draft is explicitly about IPv6-only and dual-stack networks, and it seems to me that even mentioning IPv4-as-a-service is not really necessary. I don't feel strongly about this. Brian > - Philip > > On 2015-11-03, at 7:26 , Brian E Carpenter wrote: > >> On 03/11/2015 10:51, joel jaeggli wrote: >> >> ... >>> dual stack deployment is a common operating modality and has been for a >>> rather long time. there's definitely a tax to be payed with respect to >>> resource usage, and complexity that doesn't exist in a v6 only network, >>> but support of your existing model while building the new is incremental. >> >> It seems to me that *this* draft should simply state that there are >> two main options for service continuity for IPv4 applications (dual >> stack or IPv4 as a service) but this is out of scope for the current >> document. Otherwise the draft will get bogged down for months. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From nobody Mon Nov 2 16:49: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 BE8A51AC3F4 for ; Mon, 2 Nov 2015 16:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 820TsdkeXwZC for ; Mon, 2 Nov 2015 16:49:23 -0800 (PST) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C4ABF1AC40C for ; Mon, 2 Nov 2015 16:49:22 -0800 (PST) X-SENDER-IP: 10.64.163.155 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,236,1444708800"; d="scan'208";a="853195843" Received: from unknown (HELO exchpapp14.corp.twcable.com) ([10.64.163.155]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 02 Nov 2015 19:41:57 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp14.corp.twcable.com (10.64.163.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 19:49:02 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 19:49:02 -0500 From: "Howard, Lee" To: Victor Kuarsingh , 'IPv6 Operations' Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYA= Date: Tue, 3 Nov 2015 00:49:02 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> In-Reply-To: <5637FDD0.70300@jvknet.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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21918.002 x-tm-as-result: No--51.656300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 00:49:24 -0000 SSBzZWUgaW50ZXJlc3QgZnJvbSBWaWN0b3IgS3VhcnNpbmdoLCBEYXZpZCBGYXJtZXIsIEFsZXhh bmRyZSBQZXRyZXNjdSwgYW5kDQpCcmlhbiBDYXJwZW50ZXIuIENhbiBJIGFzayBlYWNoIG9mIHlv dSB0byBkbyBhIHJldmlldyBvZiB0aGUgY3VycmVudA0KZG9jdW1lbnQsIGFuZCBzZW5kIGNvbW1l bnRzIHRvIHRoZSBtYWlsaW5nIGxpc3Q/ICBUaGF0IHdpbGwgZ2l2ZSB0aGUNCmF1dGhvcnMNCmFu ZCB0aGUgV0cgc29tZXRoaW5nIHRvIHdvcmsgZnJvbS4NCg0KRm9sbG93aW5nIHRoYXQsIHdlIGNh biBkaXNjdXNzIHdoZXRoZXIgd2UgbmVlZCBhZGRpdGlvbmFsIGRpc2N1c3Npb24gYXQgYQ0KbWVl dGluZywgb3IgV0dMQy4NCg0KVGhhbmtzLA0KDQpMZWUNCg0KDQpPbiAxMS8zLzE1LCA5OjIwIEFN LCAiVmljdG9yIEt1YXJzaW5naCIgPHZpY3RvckBqdmtuZXQuY29tPiB3cm90ZToNCg0KPldHLA0K Pg0KPk15IGlucHV0IGlzIHRoYXQgd2Ugc2hvdWxkIGNvbnRpbnVlIHRoaXMgd29yay4gIEdpdmVu IFVMQXMgYXJlIGFscmVhZHkNCj5pbiB1c2UsIGhhdmluZyBhIGRvY3VtZW50IHdoaWNoIG91dGxp bmVzIHRob3NlIHVzZSBjYXNlcyBpcywgaW4gbXkgbWluZCwNCj5vcGVyYXRpb25hbGx5IGJlbmVm aWNpYWwuDQo+DQo+UGVyaGFwcyB3ZSBzaG91bGQgYmUgbW9yZSBjbGVhciB0aGF0IHdlIHdvdWxk IG5vdCBiZSByZWNvbW1lbmRpbmcgdGhlDQo+dXNlIG9mIFVMQXMsIGJ1dCBrZWVwIHRvIGEgdW5i aWFzZWQgZG9jdW1lbnQgd2hpY2ggb3V0bGluZXMgaG93IHRoZXkNCj5oYXZlIGJlZW4gdXNlZCAo anVzdCBhIHVzZSBjYXNlIGRpc2N1c3Npb24pLiAgV2UgY2FuIGFsc28gaW5jbHVkZQ0KPm9iamVj dGl2ZSB0ZWNobmljYWwgcG9pbnRzIGFzIHRvIHRoZSBwcm9zL2NvbnMgcmVsYXRlZCB0byBlYWNo IHVzZSBjYXNlLg0KPg0KPkl0IHdhcyBhbHNvIG5vdGVkIGluIGFub3RoZXIgZW1haWwgKGJhc2Vk IG9uIFdHIHY2b3BzIGRpc2N1c3Npb24NCj55ZXN0ZXJkYXkpLCB0aGF0IG9uZSBzdWNoIHZhbGlk IGV4YW1wbGUgd2FzIENhYmxlIE1vZGVtIG1hbmFnZW1lbnQgSVBzDQo+YXNzaWduZWQgVUxBIGJh c2VkIGFkZHJlc3NpbmcuICBUaGlzIGlzIGEgdmFsaWQgdGVjaG5pY2FsIHVzZSBjYXNlLg0KPg0K PkkgYW0gd2lsbGluZyB0byBoZWxwIGlmIHJlcXVpcmVkIG9uIHRoaXMgZG9jdW1lbnQuDQo+DQo+ cmVnYXJkcywNCj4NCj5WaWN0b3IgSw0KPg0KPk9uIDIwMTUtMTEtMDIgNjoxNyBQTSwgSG93YXJk LCBMZWUgd3JvdGU6DQo+PiBUaGlzIGRvY3VtZW50IGhhc26p9nQgaGFkIGFueSByZXZpc2lvbnMg b3IgZGlzY3Vzc2lvbiBpbiBhIHdoaWxlLg0KPj4gSXMgdGhlcmUgYW55b25lIGludGVyZXN0ZWQg aW4gd29ya2luZyBvbiBpdD8NCj4+DQo+PiBJZiB3ZSBkbyBub3QgaGVhciBhbnkgaW50ZXJlc3Qs IHdlIHdpbGwgYWJhbmRvbiB0aGlzIGRyYWZ0Lg0KPj4NCj4+IFRoYW5rcywNCj4+IExlZQ0KPj4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4NCj4+IFRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlDQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+c29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuDQo+ PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlv dSBhcmUgaGVyZWJ5DQo+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+PmluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+c3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+ PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseQ0KPj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlz IEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3Bz QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBFLW1haWwg YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50 cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Mon Nov 2 17:04: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 7A8D11ACD15 for ; Mon, 2 Nov 2015 17:04:12 -0800 (PST) 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 cvYK3iTrloJi for ; Mon, 2 Nov 2015 17:04:11 -0800 (PST) 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 135A01ACD0C for ; Mon, 2 Nov 2015 17:04:11 -0800 (PST) Received: by ykdr3 with SMTP id r3so1648264ykd.1 for ; Mon, 02 Nov 2015 17:04:10 -0800 (PST) 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=mRytb1h7vkBsPWgekGMU76AUVR9TnH19xaubRevbCz0=; b=kUU0HNPknzsIAImoeNFPVDR1bba7OAbD1b8wpUR5r2XmTsYlrp7jAYs9vJ96Nx/ADG CxE+AyaH2GfMLySGqIXj8/vMuryAFA49XeK3ajwUGRt6sDJwLANQEdflOogdO2eFYioB XyH+cAgdFqQ+cOaumtv/TLxR3qvWfEUPlfIaB/xIsPFmF1IHOmH3DNWmvKKiTab2p2jF FWpoViuhXPtXHcPuEgTghpFw04hYD9V6l+i6elkY1z5bA1Rz6xmMNLXaV8QSaXBafb6G 4k9gUcru+AiDlibmmAmnanoljDTlvHKVvgP3za8HikKrgeJfeeS/oTPELQK0SFqqYmJK 0bKA== 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=mRytb1h7vkBsPWgekGMU76AUVR9TnH19xaubRevbCz0=; b=QLX0D7pOYzk6rrUjTaN7LfQMeB9k89jSw8upTRxph0Ez06pvSlalTlH8ScbonJyvG+ vsbhdYXcrnpwvr8V+fJfPVuFDUubKSDFHLoQ8c5JqdK2I0roxpE1cnUxbLLv6y5SxFsb gFKBJNNv8FJ+8OP6LfCjCKjk3f6DLubLXo2Or9qxPxh4hwT9gKktDD1EhC9UkhhbjvIU VDQBH6G55w+Z0Uv8uPie/F2zUSm8kpxl1z7+mxmfcbKdLECrRPq8DVxIXksj0wzEve7M Z8+uLtSkgM7acKQYLUJSnxXonFNTY03hZTcO9s2ddWC29wIOJo4BIIjNvZZ+G0LjawEy +GAA== X-Gm-Message-State: ALoCoQkS10b3RRE1z3sO3SslCoEl4KBr6GCGoityxRmKnspFapTnBH/FwDcfkFFOTARCXIHRPxXd X-Received: by 10.129.137.198 with SMTP id z189mr18875077ywf.307.1446512650179; Mon, 02 Nov 2015 17:04:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 17:03:50 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 10:03:50 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=94eb2c06bf26addfab0523987826 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 01:04:12 -0000 --94eb2c06bf26addfab0523987826 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L wrote: > I have one text addition suggestion and one question. On P. 7, in Table 1, > suggest adding a new final row as follows: > > requires DAD Yes Yes > No N/A > > Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA > must use DAD to check for duplicates on the link they were obtained. In a > multi-addressing environment where millions of addresses are required, > this could amount to a substantial amount of DAD multicast traffic. On the > other hand, DAD is not needed for DHCPv6 PD because the network has > unambiguously delegated the prefix for the node's exclusive use. > I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with any other devices on that /64 (e.g., tethered devices, VMs, etc.). I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we could come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add something to the table it needs to be correct. I have a question also on table 1. Under ""Unlimited" endpoints", why does > it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a > prefix > obtained by DHCPv6 PD can be used to configure an unlimited number of > addresses on the link over which the prefix was received. > The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says "no" because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however many /64s you have available. If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign to clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons. --94eb2c06bf26addfab0523987826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
I have one t= ext addition suggestion and one question. On P. 7, in Table 1,
suggest adding a new final row as follows:

=C2=A0 requires DAD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Y= es=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N/A

Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
must use DAD to check for duplicates on the link they were obtained. In a multi-addressing environment where millions of addresses are required,
this could amount to a substantial amount of DAD multicast traffic. On the<= br> other hand, DAD is not needed for DHCPv6 PD because the network has
unambiguously delegated the prefix for the node's exclusive use.

I don't think "Requires DAD: No"= ; is correct. Even if the device gets a /64 prefix entirely for its own use= , it still needs to do DAD with any other devices on that /64 (e.g., tether= ed devices, VMs, etc.).

I'm not opposed to add= ing a line to the table, though I don't think it provides much value - = if we put our mind to it, I'm sure we could come up with lots of things= we could add to the table that aren't there at the moment. My main con= cern is that if we add something to the table it needs to be correct.

I have a question also on table 1. Under ""Unlimited" endpoi= nts", why does
it say "no" for DHCPv6 PD? I think it should say "yes" = instead, since a prefix
obtained by DHCPv6 PD can be used to configure an unlimited number of
addresses on the link over which the prefix was received.
<= div>
The table is written from the perspective of the network= assigning addresses to devices that connect to it. Therefore, it says &quo= t;no" because if you use DHCPv6 PD you can't assign address space = to an unlimited number of endpoints - you are limited to however many /64s = you have available.

If you use IA_NA or SLAAC, any= network with a /64 subnet has, at least in theory, an "unlimited"= ; number of addresses to assign to clients. Of course, that's only true= in theory. In practice, there's going to be a limit due to scaling rea= sons.
--94eb2c06bf26addfab0523987826-- From nobody Mon Nov 2 17:08: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 AEC101ACD26 for ; Mon, 2 Nov 2015 17:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 nBOlU9w8Ml4a for ; Mon, 2 Nov 2015 17:08:18 -0800 (PST) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63D1ACD17 for ; Mon, 2 Nov 2015 17:08:18 -0800 (PST) X-SENDER-IP: 10.64.163.156 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,236,1444708800"; d="scan'208";a="446754558" Received: from unknown (HELO exchpapp15.corp.twcable.com) ([10.64.163.156]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 02 Nov 2015 19:59:53 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp15.corp.twcable.com (10.64.163.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 20:08:16 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 20:08:16 -0500 From: "Howard, Lee" To: Havard Eidnes , "markzzzsmith@gmail.com" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-02.txt Thread-Index: AQHRFdQeDxFOz/D4SUiszlgIbHpl/A== Date: Tue, 3 Nov 2015 01:08:16 +0000 Message-ID: References: <20151102.105228.439899806.he@uninett.no> In-Reply-To: <20151102.105228.439899806.he@uninett.no> 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21918.002 x-tm-as-result: No--42.417800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6F85A8FB4DC26C4B92BE7CA7115FF27E@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-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: Tue, 03 Nov 2015 01:08:20 -0000 I find prefix length to be a clear descriptor. However, apparently not everyone does, so the term should be defined before using it throughout the document. Prefixes have length (longer/shorter), blocks have volume (larger/smaller). IMHO. Lee On 11/2/15, 6:52 PM, "v6ops on behalf of Havard Eidnes" wrote: >>>> I agree with making sure to avoiding ambiguity, I know on occasion it >>>> hasn't been clear to me whether somebody is describing a prefix with a >>>> smaller number of addresses, or a shorter prefix length, which >>>>obviously >>>> mean the complete opposites in terms of number of addresses within the >>>> prefix, when they use "smaller prefix". >>> >>> What about "smaller/larger sized prefix"? >> >> That would be clearer. > >To me that's still borderline ambigious, and I don't understand >why anyone would want to use borderline ambigious wording when >writing RFCs or discussing them. > >It's not clear whether it's the prefix-length which is "smaller" >or "larger" or the address space covered which is "smaller" or >"larger", and they each point in the direction of different >interpretations. In other words, you don't "size" a prefix, but >you "size" the address space covered. A prefix, on the other >hand, has length, so to my eyes the above looks ... awkward. > >Therefore I'm suggesting the more unambigious "shorter/longer >prefix" as preferable. > >Regards, > >- H=E5vard > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Nov 2 17:24: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 5C9461ACE0C for ; Mon, 2 Nov 2015 17:24:17 -0800 (PST) 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 KghRRzeJNJps for ; Mon, 2 Nov 2015 17:24:15 -0800 (PST) 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 B8E0A1ACDAB for ; Mon, 2 Nov 2015 17:24:14 -0800 (PST) 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 tA31ODUV006288; Mon, 2 Nov 2015 19:24:13 -0600 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA31OAkn006274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 19:24:11 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.206]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 17:24:11 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcA== Date: Tue, 3 Nov 2015 01:24:10 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@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_2134F8430051B64F815C691A62D9831832F393F1XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 01:24:17 -0000 --_000_2134F8430051B64F815C691A62D9831832F393F1XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KUmVzcG9uc2VzIGJlbG93IGluIOKAnGdyZWVu4oCdOg0KDQpGcm9tOiBM b3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXks IE5vdmVtYmVyIDAyLCAyMDE1IDU6MDQgUE0NClRvOiBUZW1wbGluLCBGcmVkIEwNCkNjOiBGcmVk IEJha2VyIChmcmVkKTsgdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0 LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQoNCk9uIFR1ZSwg Tm92IDMsIDIwMTUgYXQgODo1OSBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpJIGhh dmUgb25lIHRleHQgYWRkaXRpb24gc3VnZ2VzdGlvbiBhbmQgb25lIHF1ZXN0aW9uLiBPbiBQLiA3 LCBpbiBUYWJsZSAxLA0Kc3VnZ2VzdCBhZGRpbmcgYSBuZXcgZmluYWwgcm93IGFzIGZvbGxvd3M6 DQoNCiAgcmVxdWlyZXMgREFEICAgICAgICAgICAgICAgWWVzICAgICAgICAgICAgICAgICAgWWVz ICAgICAgICAgICAgICAgICAgIE5vICAgICAgICAgICAgICAgICBOL0ENCg0KTWVhbmluZyB0aGF0 IG11bHRpLWFkZHJlc3NlcyBjb25maWd1cmVkIGJ5IFNMQUFDIG9yIERIQ1B2NiBJQV9OQS9JQV9U QQ0KbXVzdCB1c2UgREFEIHRvIGNoZWNrIGZvciBkdXBsaWNhdGVzIG9uIHRoZSBsaW5rIHRoZXkg d2VyZSBvYnRhaW5lZC4gSW4gYQ0KbXVsdGktYWRkcmVzc2luZyBlbnZpcm9ubWVudCB3aGVyZSBt aWxsaW9ucyBvZiBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkLA0KdGhpcyBjb3VsZCBhbW91bnQgdG8g YSBzdWJzdGFudGlhbCBhbW91bnQgb2YgREFEIG11bHRpY2FzdCB0cmFmZmljLiBPbiB0aGUNCm90 aGVyIGhhbmQsIERBRCBpcyBub3QgbmVlZGVkIGZvciBESENQdjYgUEQgYmVjYXVzZSB0aGUgbmV0 d29yayBoYXMNCnVuYW1iaWd1b3VzbHkgZGVsZWdhdGVkIHRoZSBwcmVmaXggZm9yIHRoZSBub2Rl J3MgZXhjbHVzaXZlIHVzZS4NCg0KSSBkb24ndCB0aGluayAiUmVxdWlyZXMgREFEOiBObyIgaXMg Y29ycmVjdC4gRXZlbiBpZiB0aGUgZGV2aWNlIGdldHMgYSAvNjQgcHJlZml4IGVudGlyZWx5IGZv ciBpdHMgb3duIHVzZSwgaXQgc3RpbGwgbmVlZHMgdG8gZG8gREFEIHdpdGggYW55IG90aGVyIGRl dmljZXMgb24gdGhhdCAvNjQgKGUuZy4sIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLikuDQoN CkknbSBub3Qgb3Bwb3NlZCB0byBhZGRpbmcgYSBsaW5lIHRvIHRoZSB0YWJsZSwgdGhvdWdoIEkg ZG9uJ3QgdGhpbmsgaXQgcHJvdmlkZXMgbXVjaCB2YWx1ZSAtIGlmIHdlIHB1dCBvdXIgbWluZCB0 byBpdCwgSSdtIHN1cmUgd2UgY291bGQgY29tZSB1cCB3aXRoIGxvdHMgb2YgdGhpbmdzIHdlIGNv dWxkIGFkZCB0byB0aGUgdGFibGUgdGhhdCBhcmVuJ3QgdGhlcmUgYXQgdGhlIG1vbWVudC4gTXkg bWFpbiBjb25jZXJuIGlzIHRoYXQgaWYgd2UgYWRkIHNvbWV0aGluZyB0byB0aGUgdGFibGUgaXQg bmVlZHMgdG8gYmUgY29ycmVjdC4NCg0KV2hhdCBJIG1lYW4gaXMg4oCcUmVxdWlyZXMgREFEIG9u IHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgcHJlZml4IHdhcyByZWNlaXZlZOKAnSwNCmJ1 dCB0aGF0IHdhcyB0b28gbG9uZyB0byBmaXQgaW4gdGhlIHRhYmxlLiBMZXTigJlzIGNhbGwgdGhl IGludGVyZmFjZSDigJxB4oCdLiBJZiB0aGUgbm9kZSBnZXRzDQpTTEFBQyBhZGRyZXNzZXMgb3Ig REhDUCBJQV9OQS9JQV9UQSBhZGRyZXNzZXMgb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSwgdGhlbiBp dCBuZWVkcw0KdG8gZG8gREFEIG9uIGludGVyZmFjZSDigJxB4oCdIGZvciBlYWNoIHN1Y2ggYWRk cmVzcy4gSWYgdGhlIG5vZGUgZ2V0cyBhIERIQ1B2NiBQRA0Kb3ZlciBpbnRlcmZhY2Ug4oCcQeKA nSwgaG93ZXZlciwgaXQgZG9lcyBub3QgbmVlZCB0byBkbyBEQUQgb3ZlciBpbnRlcmZhY2Ug4oCc QeKAnSBhdCBhbGwuDQoNCklmIHRoZSBub2RlIGFzc2lnbnMgdGhlIGRlbGVnYXRlZCBwcmVmaXgg dG8gaW50ZXJmYWNlIOKAnELigJ0sIHRoZW4geW91IGFyZSByaWdodCB0aGF0DQp0aGF0IERBRCB3 aWxsIGJlIHJlcXVpcmVkIGFtb25nIGFsbCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4gb24g aW50ZXJmYWNlIOKAnELigJ0uDQpCdXQsIHRoZXJlIHdpbGwgc3RpbGwgYmUgbm8gbmVlZCBmb3Ig REFEIG9uIGludGVyZmFjZSDigJxB4oCdLiBEb2VzIHRoYXQgY2xhcmlmeT8NCg0KSSBoYXZlIGEg cXVlc3Rpb24gYWxzbyBvbiB0YWJsZSAxLiBVbmRlciAiIlVubGltaXRlZCIgZW5kcG9pbnRzIiwg d2h5IGRvZXMNCml0IHNheSAibm8iIGZvciBESENQdjYgUEQ/IEkgdGhpbmsgaXQgc2hvdWxkIHNh eSAieWVzIiBpbnN0ZWFkLCBzaW5jZSBhIHByZWZpeA0Kb2J0YWluZWQgYnkgREhDUHY2IFBEIGNh biBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mDQphZGRyZXNzZXMg b24gdGhlIGxpbmsgb3ZlciB3aGljaCB0aGUgcHJlZml4IHdhcyByZWNlaXZlZC4NCg0KVGhlIHRh YmxlIGlzIHdyaXR0ZW4gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIG5ldHdvcmsgYXNzaWdu aW5nIGFkZHJlc3NlcyB0byBkZXZpY2VzIHRoYXQgY29ubmVjdCB0byBpdC4gVGhlcmVmb3JlLCBp dCBzYXlzICJubyIgYmVjYXVzZSBpZiB5b3UgdXNlIERIQ1B2NiBQRCB5b3UgY2FuJ3QgYXNzaWdu IGFkZHJlc3Mgc3BhY2UgdG8gYW4gdW5saW1pdGVkIG51bWJlciBvZiBlbmRwb2ludHMgLSB5b3Ug YXJlIGxpbWl0ZWQgdG8gaG93ZXZlciBtYW55IC82NHMgeW91IGhhdmUgYXZhaWxhYmxlLg0KDQpJ ZiB5b3UgdXNlIElBX05BIG9yIFNMQUFDLCBhbnkgbmV0d29yayB3aXRoIGEgLzY0IHN1Ym5ldCBo YXMsIGF0IGxlYXN0IGluIHRoZW9yeSwgYW4gInVubGltaXRlZCIgbnVtYmVyIG9mIGFkZHJlc3Nl cyB0byBhc3NpZ24gdG8gY2xpZW50cy4gT2YgY291cnNlLCB0aGF0J3Mgb25seSB0cnVlIGluIHRo ZW9yeS4gSW4gcHJhY3RpY2UsIHRoZXJlJ3MgZ29pbmcgdG8gYmUgYSBsaW1pdCBkdWUgdG8gc2Nh bGluZyByZWFzb25zLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzLiBUcnVlIHRoYXQgU0xB QUMgYW5kIERIQ1B2NiBJQV9OQS9JQV9UQSBjYW4gYmUgdXNlZA0KdG8gYXNzaWduIGFuIHVubGlt aXRlZCBudW1iZXIgb2YgYWRkcmVzc2VzIHRvIGludGVyZmFjZSDigJxB4oCdLiBCdXQsIHNvIGNh biBESENQdjYNClBELiBXaGVuIHRoZSBub2RlIHJlY2VpdmVzIHRoZSBkZWxlZ2F0ZWQgcHJlZml4 IChlLmcuLCBhIC82NCksIGl0IGNhbiBhc3NpZ24gYXMNCm1hbnkgdW5pcXVlIElQdjYgYWRkcmVz c2VzIGFzIGl0IGxpa2VzIHRvIGludGVyZmFjZSDigJxB4oCdLiBBbmQgYWdhaW4sIGl0IG5lZWQg bm90DQpkbyBEQUQgZm9yIGFueSBvZiB0aGVtLg0K --_000_2134F8430051B64F815C691A62D9831832F393F1XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDBCMDUwIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwQjA1MCI+UmVzcG9uc2VzIGJlbG93IGluIOKAnGdyZWVu4oCdOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1IDU6MDQgUE08YnI+DQo8Yj5U bzo8L2I+IFRlbXBsaW4sIEZyZWQgTDxicj4NCjxiPkNjOjwvYj4gRnJlZCBCYWtlciAoZnJlZCk7 IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBOb3YgMywgMjAxNSBhdCA4OjU5IEFNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9 Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBvbmUgdGV4dCBhZGRpdGlvbiBzdWdn ZXN0aW9uIGFuZCBvbmUgcXVlc3Rpb24uIE9uIFAuIDcsIGluIFRhYmxlIDEsPGJyPg0Kc3VnZ2Vz dCBhZGRpbmcgYSBuZXcgZmluYWwgcm93IGFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KJm5ic3A7IHJl cXVpcmVzIERBRCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtZZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBZZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtObyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ti9BPGJyPg0KPGJyPg0KTWVh bmluZyB0aGF0IG11bHRpLWFkZHJlc3NlcyBjb25maWd1cmVkIGJ5IFNMQUFDIG9yIERIQ1B2NiBJ QV9OQS9JQV9UQTxicj4NCm11c3QgdXNlIERBRCB0byBjaGVjayBmb3IgZHVwbGljYXRlcyBvbiB0 aGUgbGluayB0aGV5IHdlcmUgb2J0YWluZWQuIEluIGE8YnI+DQptdWx0aS1hZGRyZXNzaW5nIGVu dmlyb25tZW50IHdoZXJlIG1pbGxpb25zIG9mIGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQsPGJyPg0K dGhpcyBjb3VsZCBhbW91bnQgdG8gYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgREFEIG11bHRpY2Fz dCB0cmFmZmljLiBPbiB0aGU8YnI+DQpvdGhlciBoYW5kLCBEQUQgaXMgbm90IG5lZWRlZCBmb3Ig REhDUHY2IFBEIGJlY2F1c2UgdGhlIG5ldHdvcmsgaGFzPGJyPg0KdW5hbWJpZ3VvdXNseSBkZWxl Z2F0ZWQgdGhlIHByZWZpeCBmb3IgdGhlIG5vZGUncyBleGNsdXNpdmUgdXNlLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24n dCB0aGluayAmcXVvdDtSZXF1aXJlcyBEQUQ6IE5vJnF1b3Q7IGlzIGNvcnJlY3QuIEV2ZW4gaWYg dGhlIGRldmljZSBnZXRzIGEgLzY0IHByZWZpeCBlbnRpcmVseSBmb3IgaXRzIG93biB1c2UsIGl0 IHN0aWxsIG5lZWRzIHRvIGRvIERBRCB3aXRoIGFueSBvdGhlciBkZXZpY2VzIG9uIHRoYXQgLzY0 IChlLmcuLCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4pLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IG9wcG9z ZWQgdG8gYWRkaW5nIGEgbGluZSB0byB0aGUgdGFibGUsIHRob3VnaCBJIGRvbid0IHRoaW5rIGl0 IHByb3ZpZGVzIG11Y2ggdmFsdWUgLSBpZiB3ZSBwdXQgb3VyIG1pbmQgdG8gaXQsIEknbSBzdXJl IHdlIGNvdWxkIGNvbWUgdXAgd2l0aCBsb3RzIG9mIHRoaW5ncyB3ZSBjb3VsZCBhZGQgdG8gdGhl IHRhYmxlIHRoYXQgYXJlbid0IHRoZXJlIGF0IHRoZSBtb21lbnQuIE15IG1haW4gY29uY2Vybg0K IGlzIHRoYXQgaWYgd2UgYWRkIHNvbWV0aGluZyB0byB0aGUgdGFibGUgaXQgbmVlZHMgdG8gYmUg Y29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPldoYXQgSSBtZWFuIGlzIOKAnFJlcXVpcmVz IERBRCBvbiB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWTi gJ0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMEIwNTAiPmJ1dCB0aGF0IHdhcyB0b28gbG9uZyB0byBmaXQgaW4gdGhl IHRhYmxlLiBMZXTigJlzIGNhbGwgdGhlIGludGVyZmFjZSDigJxB4oCdLiBJZiB0aGUgbm9kZSBn ZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMEIwNTAiPlNMQUFDIGFkZHJlc3NlcyBvciBESENQIElBX05BL0lBX1RB IGFkZHJlc3NlcyBvdmVyIGludGVyZmFjZSDigJxB4oCdLCB0aGVuIGl0IG5lZWRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMEIwNTAiPnRvIGRvIERBRCBvbiBpbnRlcmZhY2Ug4oCcQeKAnSBmb3IgZWFjaCBzdWNoIGFk ZHJlc3MuIElmIHRoZSBub2RlIGdldHMgYSBESENQdjYgUEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+b3Zl ciBpbnRlcmZhY2Ug4oCcQeKAnSwgaG93ZXZlciwgaXQgZG9lcyBub3QgbmVlZCB0byBkbyBEQUQg b3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSBhdCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDBCMDUwIj5JZiB0aGUgbm9kZSBhc3NpZ25zIHRoZSBkZWxlZ2F0ZWQgcHJlZml4 IHRvIGludGVyZmFjZSDigJxC4oCdLCB0aGVuIHlvdSBhcmUgcmlnaHQgdGhhdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDBCMDUwIj50aGF0IERBRCB3aWxsIGJlIHJlcXVpcmVkIGFtb25nIGFsbCB0ZXRoZXJlZCBkZXZp Y2VzLCBWTXMsIGV0Yy4gb24gaW50ZXJmYWNlIOKAnELigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPkJ1 dCwgdGhlcmUgd2lsbCBzdGlsbCBiZSBubyBuZWVkIGZvciBEQUQgb24gaW50ZXJmYWNlIOKAnEHi gJ0uIERvZXMgdGhhdCBjbGFyaWZ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgcXVlc3Rpb24gYWxzbyBv biB0YWJsZSAxLiBVbmRlciAmcXVvdDsmcXVvdDtVbmxpbWl0ZWQmcXVvdDsgZW5kcG9pbnRzJnF1 b3Q7LCB3aHkgZG9lczxicj4NCml0IHNheSAmcXVvdDtubyZxdW90OyBmb3IgREhDUHY2IFBEPyBJ IHRoaW5rIGl0IHNob3VsZCBzYXkgJnF1b3Q7eWVzJnF1b3Q7IGluc3RlYWQsIHNpbmNlIGEgcHJl Zml4PGJyPg0Kb2J0YWluZWQgYnkgREhDUHY2IFBEIGNhbiBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBh biB1bmxpbWl0ZWQgbnVtYmVyIG9mPGJyPg0KYWRkcmVzc2VzIG9uIHRoZSBsaW5rIG92ZXIgd2hp Y2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGFibGUgaXMgd3JpdHRlbiBmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgbmV0d29yayBhc3NpZ25pbmcgYWRkcmVzc2VzIHRvIGRl dmljZXMgdGhhdCBjb25uZWN0IHRvIGl0LiBUaGVyZWZvcmUsIGl0IHNheXMgJnF1b3Q7bm8mcXVv dDsgYmVjYXVzZSBpZiB5b3UgdXNlIERIQ1B2NiBQRCB5b3UgY2FuJ3QgYXNzaWduIGFkZHJlc3Mg c3BhY2UgdG8gYW4gdW5saW1pdGVkIG51bWJlciBvZiBlbmRwb2ludHMgLSB5b3UgYXJlDQogbGlt aXRlZCB0byBob3dldmVyIG1hbnkgLzY0cyB5b3UgaGF2ZSBhdmFpbGFibGUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB1c2UgSUFf TkEgb3IgU0xBQUMsIGFueSBuZXR3b3JrIHdpdGggYSAvNjQgc3VibmV0IGhhcywgYXQgbGVhc3Qg aW4gdGhlb3J5LCBhbiAmcXVvdDt1bmxpbWl0ZWQmcXVvdDsgbnVtYmVyIG9mIGFkZHJlc3NlcyB0 byBhc3NpZ24gdG8gY2xpZW50cy4gT2YgY291cnNlLCB0aGF0J3Mgb25seSB0cnVlIGluIHRoZW9y eS4gSW4gcHJhY3RpY2UsIHRoZXJlJ3MgZ29pbmcgdG8gYmUgYSBsaW1pdCBkdWUgdG8gc2NhbGlu ZyByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+SSBkb27igJl0IHVuZGVyc3RhbmQgdGhp cy4gVHJ1ZSB0aGF0IFNMQUFDIGFuZCBESENQdjYgSUFfTkEvSUFfVEEgY2FuIGJlIHVzZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwQjA1MCI+dG8gYXNzaWduIGFuIHVubGltaXRlZCBudW1iZXIgb2YgYWRkcmVzc2Vz IHRvIGludGVyZmFjZSDigJxB4oCdLiBCdXQsIHNvIGNhbiBESENQdjY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1 MCI+UEQuIFdoZW4gdGhlIG5vZGUgcmVjZWl2ZXMgdGhlIGRlbGVnYXRlZCBwcmVmaXggKGUuZy4s IGEgLzY0KSwgaXQgY2FuIGFzc2lnbiBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj5tYW55IHVuaXF1ZSBJ UHY2IGFkZHJlc3NlcyBhcyBpdCBsaWtlcyB0byBpbnRlcmZhY2Ug4oCcQeKAnS4gQW5kIGFnYWlu LCBpdCBuZWVkIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj5kbyBEQUQgZm9yIGFueSBvZiB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D9831832F393F1XCHBLV504nwnosb_-- From nobody Mon Nov 2 17:31: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 630A21B2B09 for ; Mon, 2 Nov 2015 17:31:30 -0800 (PST) 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 9Bou8yoi_uix for ; Mon, 2 Nov 2015 17:31:26 -0800 (PST) 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 7C6C91ACD2E for ; Mon, 2 Nov 2015 17:31:26 -0800 (PST) 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 tA31VOCA022143; Mon, 2 Nov 2015 18:31:24 -0700 Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA31VFX9021751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 18:31:15 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-512.sw.nos.boeing.com ([169.254.12.209]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 17:31:14 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrA Date: Tue, 3 Nov 2015 01:31:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F393F1@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_2134F8430051B64F815C691A62D9831832F3941DXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 01:31:30 -0000 --_000_2134F8430051B64F815C691A62D9831832F3941DXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnVtcGluZyB1cCBvbmUgbGV2ZWwg4oCTIGlzIGl0IGNsZWFyIHRvIGV2ZXJ5b25lIHRoYXQgaXQg aXMgT0sgdG8gYXNzaWduIGFkZHJlc3Nlcw0KdGFrZW4gZnJvbSBhIERIQ1B2NiBkZWxlZ2F0ZWQg cHJlZml4IHRvIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgcHJlZml4DQp3YXMgcmVjZWl2 ZWQ/IEFuZCwgdGhhdCBEQUQgaXMgbm90IHJlcXVpcmVkIGZvciB0aG9zZSBhZGRyZXNzZXM/DQoN ClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBMDQpTZW50OiBNb25kYXksIE5vdmVtYmVy IDAyLCAyMDE1IDU6MjQgUE0NClRvOiBMb3JlbnpvIENvbGl0dGkNCkNjOiB2Nm9wc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxh YmlsaXR5IGRpc2N1c3Npb24NCg0KSGkgTG9yZW56bywNCg0KUmVzcG9uc2VzIGJlbG93IGluIOKA nGdyZWVu4oCdOg0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1IDU6MDQgUE0NClRvOiBUZW1w bGluLCBGcmVkIEwNCkNjOiBGcmVkIEJha2VyIChmcmVkKTsgdjZvcHNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1o b3N0LWFkZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb24NCg0KT24gVHVlLCBOb3YgMywgMjAxNSBh dCA4OjU5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFp bHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCkkgaGF2ZSBvbmUgdGV4dCBh ZGRpdGlvbiBzdWdnZXN0aW9uIGFuZCBvbmUgcXVlc3Rpb24uIE9uIFAuIDcsIGluIFRhYmxlIDEs DQpzdWdnZXN0IGFkZGluZyBhIG5ldyBmaW5hbCByb3cgYXMgZm9sbG93czoNCg0KICByZXF1aXJl cyBEQUQgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAg ICAgICAgTm8gICAgICAgICAgICAgICAgIE4vQQ0KDQpNZWFuaW5nIHRoYXQgbXVsdGktYWRkcmVz c2VzIGNvbmZpZ3VyZWQgYnkgU0xBQUMgb3IgREhDUHY2IElBX05BL0lBX1RBDQptdXN0IHVzZSBE QUQgdG8gY2hlY2sgZm9yIGR1cGxpY2F0ZXMgb24gdGhlIGxpbmsgdGhleSB3ZXJlIG9idGFpbmVk LiBJbiBhDQptdWx0aS1hZGRyZXNzaW5nIGVudmlyb25tZW50IHdoZXJlIG1pbGxpb25zIG9mIGFk ZHJlc3NlcyBhcmUgcmVxdWlyZWQsDQp0aGlzIGNvdWxkIGFtb3VudCB0byBhIHN1YnN0YW50aWFs IGFtb3VudCBvZiBEQUQgbXVsdGljYXN0IHRyYWZmaWMuIE9uIHRoZQ0Kb3RoZXIgaGFuZCwgREFE IGlzIG5vdCBuZWVkZWQgZm9yIERIQ1B2NiBQRCBiZWNhdXNlIHRoZSBuZXR3b3JrIGhhcw0KdW5h bWJpZ3VvdXNseSBkZWxlZ2F0ZWQgdGhlIHByZWZpeCBmb3IgdGhlIG5vZGUncyBleGNsdXNpdmUg dXNlLg0KDQpJIGRvbid0IHRoaW5rICJSZXF1aXJlcyBEQUQ6IE5vIiBpcyBjb3JyZWN0LiBFdmVu IGlmIHRoZSBkZXZpY2UgZ2V0cyBhIC82NCBwcmVmaXggZW50aXJlbHkgZm9yIGl0cyBvd24gdXNl LCBpdCBzdGlsbCBuZWVkcyB0byBkbyBEQUQgd2l0aCBhbnkgb3RoZXIgZGV2aWNlcyBvbiB0aGF0 IC82NCAoZS5nLiwgdGV0aGVyZWQgZGV2aWNlcywgVk1zLCBldGMuKS4NCg0KSSdtIG5vdCBvcHBv c2VkIHRvIGFkZGluZyBhIGxpbmUgdG8gdGhlIHRhYmxlLCB0aG91Z2ggSSBkb24ndCB0aGluayBp dCBwcm92aWRlcyBtdWNoIHZhbHVlIC0gaWYgd2UgcHV0IG91ciBtaW5kIHRvIGl0LCBJJ20gc3Vy ZSB3ZSBjb3VsZCBjb21lIHVwIHdpdGggbG90cyBvZiB0aGluZ3Mgd2UgY291bGQgYWRkIHRvIHRo ZSB0YWJsZSB0aGF0IGFyZW4ndCB0aGVyZSBhdCB0aGUgbW9tZW50LiBNeSBtYWluIGNvbmNlcm4g aXMgdGhhdCBpZiB3ZSBhZGQgc29tZXRoaW5nIHRvIHRoZSB0YWJsZSBpdCBuZWVkcyB0byBiZSBj b3JyZWN0Lg0KDQpXaGF0IEkgbWVhbiBpcyDigJxSZXF1aXJlcyBEQUQgb24gdGhlIGludGVyZmFj ZSBvdmVyIHdoaWNoIHRoZSBwcmVmaXggd2FzIHJlY2VpdmVk4oCdLA0KYnV0IHRoYXQgd2FzIHRv byBsb25nIHRvIGZpdCBpbiB0aGUgdGFibGUuIExldOKAmXMgY2FsbCB0aGUgaW50ZXJmYWNlIOKA nEHigJ0uIElmIHRoZSBub2RlIGdldHMNClNMQUFDIGFkZHJlc3NlcyBvciBESENQIElBX05BL0lB X1RBIGFkZHJlc3NlcyBvdmVyIGludGVyZmFjZSDigJxB4oCdLCB0aGVuIGl0IG5lZWRzDQp0byBk byBEQUQgb24gaW50ZXJmYWNlIOKAnEHigJ0gZm9yIGVhY2ggc3VjaCBhZGRyZXNzLiBJZiB0aGUg bm9kZSBnZXRzIGEgREhDUHY2IFBEDQpvdmVyIGludGVyZmFjZSDigJxB4oCdLCBob3dldmVyLCBp dCBkb2VzIG5vdCBuZWVkIHRvIGRvIERBRCBvdmVyIGludGVyZmFjZSDigJxB4oCdIGF0IGFsbC4N Cg0KSWYgdGhlIG5vZGUgYXNzaWducyB0aGUgZGVsZWdhdGVkIHByZWZpeCB0byBpbnRlcmZhY2Ug 4oCcQuKAnSwgdGhlbiB5b3UgYXJlIHJpZ2h0IHRoYXQNCnRoYXQgREFEIHdpbGwgYmUgcmVxdWly ZWQgYW1vbmcgYWxsIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLiBvbiBpbnRlcmZhY2Ug4oCc QuKAnS4NCkJ1dCwgdGhlcmUgd2lsbCBzdGlsbCBiZSBubyBuZWVkIGZvciBEQUQgb24gaW50ZXJm YWNlIOKAnEHigJ0uIERvZXMgdGhhdCBjbGFyaWZ5Pw0KDQpJIGhhdmUgYSBxdWVzdGlvbiBhbHNv IG9uIHRhYmxlIDEuIFVuZGVyICIiVW5saW1pdGVkIiBlbmRwb2ludHMiLCB3aHkgZG9lcw0KaXQg c2F5ICJubyIgZm9yIERIQ1B2NiBQRD8gSSB0aGluayBpdCBzaG91bGQgc2F5ICJ5ZXMiIGluc3Rl YWQsIHNpbmNlIGEgcHJlZml4DQpvYnRhaW5lZCBieSBESENQdjYgUEQgY2FuIGJlIHVzZWQgdG8g Y29uZmlndXJlIGFuIHVubGltaXRlZCBudW1iZXIgb2YNCmFkZHJlc3NlcyBvbiB0aGUgbGluayBv dmVyIHdoaWNoIHRoZSBwcmVmaXggd2FzIHJlY2VpdmVkLg0KDQpUaGUgdGFibGUgaXMgd3JpdHRl biBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgbmV0d29yayBhc3NpZ25pbmcgYWRkcmVzc2Vz IHRvIGRldmljZXMgdGhhdCBjb25uZWN0IHRvIGl0LiBUaGVyZWZvcmUsIGl0IHNheXMgIm5vIiBi ZWNhdXNlIGlmIHlvdSB1c2UgREhDUHY2IFBEIHlvdSBjYW4ndCBhc3NpZ24gYWRkcmVzcyBzcGFj ZSB0byBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIGVuZHBvaW50cyAtIHlvdSBhcmUgbGltaXRlZCB0 byBob3dldmVyIG1hbnkgLzY0cyB5b3UgaGF2ZSBhdmFpbGFibGUuDQoNCklmIHlvdSB1c2UgSUFf TkEgb3IgU0xBQUMsIGFueSBuZXR3b3JrIHdpdGggYSAvNjQgc3VibmV0IGhhcywgYXQgbGVhc3Qg aW4gdGhlb3J5LCBhbiAidW5saW1pdGVkIiBudW1iZXIgb2YgYWRkcmVzc2VzIHRvIGFzc2lnbiB0 byBjbGllbnRzLiBPZiBjb3Vyc2UsIHRoYXQncyBvbmx5IHRydWUgaW4gdGhlb3J5LiBJbiBwcmFj dGljZSwgdGhlcmUncyBnb2luZyB0byBiZSBhIGxpbWl0IGR1ZSB0byBzY2FsaW5nIHJlYXNvbnMu DQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMuIFRydWUgdGhhdCBTTEFBQyBhbmQgREhDUHY2 IElBX05BL0lBX1RBIGNhbiBiZSB1c2VkDQp0byBhc3NpZ24gYW4gdW5saW1pdGVkIG51bWJlciBv ZiBhZGRyZXNzZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEJ1dCwgc28gY2FuIERIQ1B2Ng0KUEQu IFdoZW4gdGhlIG5vZGUgcmVjZWl2ZXMgdGhlIGRlbGVnYXRlZCBwcmVmaXggKGUuZy4sIGEgLzY0 KSwgaXQgY2FuIGFzc2lnbiBhcw0KbWFueSB1bmlxdWUgSVB2NiBhZGRyZXNzZXMgYXMgaXQgbGlr ZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEFuZCBhZ2FpbiwgaXQgbmVlZCBub3QNCmRvIERBRCBm b3IgYW55IG9mIHRoZW0uDQo= --_000_2134F8430051B64F815C691A62D9831832F3941DXCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1bXBpbmcg dXAgb25lIGxldmVsIOKAkyBpcyBpdCBjbGVhciB0byBldmVyeW9uZSB0aGF0IGl0IGlzIE9LIHRv IGFzc2lnbiBhZGRyZXNzZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGFrZW4gZnJvbSBhIERIQ1B2NiBk ZWxlZ2F0ZWQgcHJlZml4IHRvIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgcHJlZml4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPndhcyByZWNlaXZlZD8gQW5kLCB0aGF0IERBRCBpcyBub3QgcmVxdWly ZWQgZm9yIHRob3NlIGFkZHJlc3Nlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlbXBsaW4sIEZyZWQgTDxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1IDU6MjQgUE08YnI+DQo8Yj5U bzo8L2I+IExvcmVuem8gQ29saXR0aTxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHIt YXZhaWxhYmlsaXR5IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+SGkgTG9yZW56byw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPlJlc3BvbnNlcyBiZWxv dyBpbiDigJxncmVlbuKAnTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkgWzxhIGhyZWY9Im1h aWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPm1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTowNCBQTTxicj4N CjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMPGJyPg0KPGI+Q2M6PC9iPiBGcmVkIEJha2VyIChm cmVkKTsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFk ZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAzLCAyMDE1 IGF0IDg6NTkgQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBv bmUgdGV4dCBhZGRpdGlvbiBzdWdnZXN0aW9uIGFuZCBvbmUgcXVlc3Rpb24uIE9uIFAuIDcsIGlu IFRhYmxlIDEsPGJyPg0Kc3VnZ2VzdCBhZGRpbmcgYSBuZXcgZmluYWwgcm93IGFzIGZvbGxvd3M6 PGJyPg0KPGJyPg0KJm5ic3A7IHJlcXVpcmVzIERBRCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtZZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZZXMmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtObyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Ti9BPGJyPg0KPGJyPg0KTWVhbmluZyB0aGF0IG11bHRpLWFkZHJlc3NlcyBjb25maWd1cmVk IGJ5IFNMQUFDIG9yIERIQ1B2NiBJQV9OQS9JQV9UQTxicj4NCm11c3QgdXNlIERBRCB0byBjaGVj ayBmb3IgZHVwbGljYXRlcyBvbiB0aGUgbGluayB0aGV5IHdlcmUgb2J0YWluZWQuIEluIGE8YnI+ DQptdWx0aS1hZGRyZXNzaW5nIGVudmlyb25tZW50IHdoZXJlIG1pbGxpb25zIG9mIGFkZHJlc3Nl cyBhcmUgcmVxdWlyZWQsPGJyPg0KdGhpcyBjb3VsZCBhbW91bnQgdG8gYSBzdWJzdGFudGlhbCBh bW91bnQgb2YgREFEIG11bHRpY2FzdCB0cmFmZmljLiBPbiB0aGU8YnI+DQpvdGhlciBoYW5kLCBE QUQgaXMgbm90IG5lZWRlZCBmb3IgREhDUHY2IFBEIGJlY2F1c2UgdGhlIG5ldHdvcmsgaGFzPGJy Pg0KdW5hbWJpZ3VvdXNseSBkZWxlZ2F0ZWQgdGhlIHByZWZpeCBmb3IgdGhlIG5vZGUncyBleGNs dXNpdmUgdXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayAmcXVvdDtSZXF1aXJlcyBEQUQ6IE5vJnF1b3Q7 IGlzIGNvcnJlY3QuIEV2ZW4gaWYgdGhlIGRldmljZSBnZXRzIGEgLzY0IHByZWZpeCBlbnRpcmVs eSBmb3IgaXRzIG93biB1c2UsIGl0IHN0aWxsIG5lZWRzIHRvIGRvIERBRCB3aXRoIGFueSBvdGhl ciBkZXZpY2VzIG9uIHRoYXQgLzY0IChlLmcuLCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4p LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20gbm90IG9wcG9zZWQgdG8gYWRkaW5nIGEgbGluZSB0byB0aGUgdGFibGUsIHRo b3VnaCBJIGRvbid0IHRoaW5rIGl0IHByb3ZpZGVzIG11Y2ggdmFsdWUgLSBpZiB3ZSBwdXQgb3Vy IG1pbmQgdG8gaXQsIEknbSBzdXJlIHdlIGNvdWxkIGNvbWUgdXAgd2l0aCBsb3RzIG9mIHRoaW5n cyB3ZSBjb3VsZCBhZGQgdG8gdGhlIHRhYmxlIHRoYXQgYXJlbid0IHRoZXJlIGF0IHRoZSBtb21l bnQuIE15IG1haW4gY29uY2Vybg0KIGlzIHRoYXQgaWYgd2UgYWRkIHNvbWV0aGluZyB0byB0aGUg dGFibGUgaXQgbmVlZHMgdG8gYmUgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPldoYXQg SSBtZWFuIGlzIOKAnFJlcXVpcmVzIERBRCBvbiB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhl IHByZWZpeCB3YXMgcmVjZWl2ZWTigJ0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPmJ1dCB0aGF0IHdhcyB0 b28gbG9uZyB0byBmaXQgaW4gdGhlIHRhYmxlLiBMZXTigJlzIGNhbGwgdGhlIGludGVyZmFjZSDi gJxB4oCdLiBJZiB0aGUgbm9kZSBnZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPlNMQUFDIGFkZHJlc3Nl cyBvciBESENQIElBX05BL0lBX1RBIGFkZHJlc3NlcyBvdmVyIGludGVyZmFjZSDigJxB4oCdLCB0 aGVuIGl0IG5lZWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPnRvIGRvIERBRCBvbiBpbnRlcmZhY2Ug4oCc QeKAnSBmb3IgZWFjaCBzdWNoIGFkZHJlc3MuIElmIHRoZSBub2RlIGdldHMgYSBESENQdjYgUEQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwQjA1MCI+b3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSwgaG93ZXZlciwgaXQgZG9l cyBub3QgbmVlZCB0byBkbyBEQUQgb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSBhdCBhbGwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj5JZiB0aGUgbm9kZSBhc3NpZ25z IHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHRvIGludGVyZmFjZSDigJxC4oCdLCB0aGVuIHlvdSBhcmUg cmlnaHQgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj50aGF0IERBRCB3aWxsIGJlIHJlcXVpcmVkIGFt b25nIGFsbCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4gb24gaW50ZXJmYWNlIOKAnELigJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMEIwNTAiPkJ1dCwgdGhlcmUgd2lsbCBzdGlsbCBiZSBubyBuZWVkIGZvciBE QUQgb24gaW50ZXJmYWNlIOKAnEHigJ0uIERvZXMgdGhhdCBjbGFyaWZ5PzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIHF1ZXN0aW9uIGFsc28g b24gdGFibGUgMS4gVW5kZXIgJnF1b3Q7JnF1b3Q7VW5saW1pdGVkJnF1b3Q7IGVuZHBvaW50cyZx dW90Oywgd2h5IGRvZXM8YnI+DQppdCBzYXkgJnF1b3Q7bm8mcXVvdDsgZm9yIERIQ1B2NiBQRD8g SSB0aGluayBpdCBzaG91bGQgc2F5ICZxdW90O3llcyZxdW90OyBpbnN0ZWFkLCBzaW5jZSBhIHBy ZWZpeDxicj4NCm9idGFpbmVkIGJ5IERIQ1B2NiBQRCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUg YW4gdW5saW1pdGVkIG51bWJlciBvZjxicj4NCmFkZHJlc3NlcyBvbiB0aGUgbGluayBvdmVyIHdo aWNoIHRoZSBwcmVmaXggd2FzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRhYmxlIGlzIHdyaXR0ZW4gZnJv bSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIG5ldHdvcmsgYXNzaWduaW5nIGFkZHJlc3NlcyB0byBk ZXZpY2VzIHRoYXQgY29ubmVjdCB0byBpdC4gVGhlcmVmb3JlLCBpdCBzYXlzICZxdW90O25vJnF1 b3Q7IGJlY2F1c2UgaWYgeW91IHVzZSBESENQdjYgUEQgeW91IGNhbid0IGFzc2lnbiBhZGRyZXNz IHNwYWNlIHRvIGFuIHVubGltaXRlZCBudW1iZXIgb2YgZW5kcG9pbnRzIC0geW91IGFyZQ0KIGxp bWl0ZWQgdG8gaG93ZXZlciBtYW55IC82NHMgeW91IGhhdmUgYXZhaWxhYmxlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgdXNlIElB X05BIG9yIFNMQUFDLCBhbnkgbmV0d29yayB3aXRoIGEgLzY0IHN1Ym5ldCBoYXMsIGF0IGxlYXN0 IGluIHRoZW9yeSwgYW4gJnF1b3Q7dW5saW1pdGVkJnF1b3Q7IG51bWJlciBvZiBhZGRyZXNzZXMg dG8gYXNzaWduIHRvIGNsaWVudHMuIE9mIGNvdXJzZSwgdGhhdCdzIG9ubHkgdHJ1ZSBpbiB0aGVv cnkuIEluIHByYWN0aWNlLCB0aGVyZSdzIGdvaW5nIHRvIGJlIGEgbGltaXQgZHVlIHRvIHNjYWxp bmcgcmVhc29ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRo aXMuIFRydWUgdGhhdCBTTEFBQyBhbmQgREhDUHY2IElBX05BL0lBX1RBIGNhbiBiZSB1c2VkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMEIwNTAiPnRvIGFzc2lnbiBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIGFkZHJlc3Nl cyB0byBpbnRlcmZhY2Ug4oCcQeKAnS4gQnV0LCBzbyBjYW4gREhDUHY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIw NTAiPlBELiBXaGVuIHRoZSBub2RlIHJlY2VpdmVzIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IChlLmcu LCBhIC82NCksIGl0IGNhbiBhc3NpZ24gYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+bWFueSB1bmlxdWUg SVB2NiBhZGRyZXNzZXMgYXMgaXQgbGlrZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEFuZCBhZ2Fp biwgaXQgbmVlZCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+ZG8gREFEIGZvciBhbnkgb2YgdGhlbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D9831832F3941DXCHBLV504nwnosb_-- From nobody Mon Nov 2 17:46: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 3EAD71B2B5F for ; Mon, 2 Nov 2015 17:46:12 -0800 (PST) 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 gPtaZ-_m0Hvn for ; Mon, 2 Nov 2015 17:46:10 -0800 (PST) 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 2FBC91B2B5B for ; Mon, 2 Nov 2015 17:46:10 -0800 (PST) Received: by pasz6 with SMTP id z6so2889240pas.2 for ; Mon, 02 Nov 2015 17:46:09 -0800 (PST) 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=rdfdKfgWquUC/D71xH1J+GG2Zpc89AVb7tJP1nd3ix4=; b=SKxhxAhSRbbjwD5hfGZafGuqaVgDlHpqzIU7SPEzqr0LsS5vXH1jkVeEx6gDal+USa IObCuiByrgZmUmEeljU7W7kdM2YbUFCMHDFY8Xw1Ii3jhZtBCVcgTpSo6880T1vw6GKP 71GqAqRwxGNJAyrqME8BeRpLhEy2Rddb/+GVcaPwCxRZ3sFpRc1dDU+mHvCIn4Rnyz2Q sH8nSpwdaasGVlnzQUIXU5EbkJrJ/I7Eoi29EoPJpYMxfYs9NFkxvKtNKGAc0LDh2qxI ol7PnnUGeLPwwaOUAjxeNXBWh9WPy8lGtlr7nt6OSXro0IIjMjE1OWaZP6V8qzvc2OKM Pjbw== X-Received: by 10.66.228.199 with SMTP id sk7mr31092810pac.8.1446515169898; Mon, 02 Nov 2015 17:46:09 -0800 (PST) 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 sb6sm9185440pbc.66.2015.11.02.17.46.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 17:46:08 -0800 (PST) To: "Templin, Fred L" , Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563811DF.9020603@gmail.com> Date: Tue, 3 Nov 2015 14:46:07 +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: <2134F8430051B64F815C691A62D9831832F3941D@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" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 01:46:12 -0000 On 03/11/2015 14:31, Templin, Fred L wrote: > Bumping up one level =E2=80=93 is it clear to everyone that it is OK to= assign addresses > taken from a DHCPv6 delegated prefix to the interface over which the pr= efix > was received?=20 If it was legitimately received, I can't see why it wouldn't be OK. > And, that DAD is not required for those addresses? How is that safe? What is to stop a host running SLAAC once it sees that prefix in an RA, and hitting the same IID by chance? At least you need to specify that the A bit must not be set. Come to that, a manual address might collide. Brian >=20 > Thanks - Fred >=20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred = L > Sent: Monday, November 02, 2015 5:24 PM > To: Lorenzo Colitti > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion= >=20 > Hi Lorenzo, >=20 > Responses below in =E2=80=9Cgreen=E2=80=9D: >=20 > From: Lorenzo Colitti [mailto:lorenzo@google.com] > Sent: Monday, November 02, 2015 5:04 PM > To: Templin, Fred L > Cc: Fred Baker (fred); v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion= >=20 > On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > wrote: > I have one text addition suggestion and one question. On P. 7, in Table= 1, > suggest adding a new final row as follows: >=20 > requires DAD Yes Yes = No N/A >=20 > Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA > must use DAD to check for duplicates on the link they were obtained. In= a > multi-addressing environment where millions of addresses are required, > this could amount to a substantial amount of DAD multicast traffic. On = the > other hand, DAD is not needed for DHCPv6 PD because the network has > unambiguously delegated the prefix for the node's exclusive use. >=20 > I don't think "Requires DAD: No" is correct. Even if the device gets a = /64 prefix entirely for its own use, it still needs to do DAD with any ot= her devices on that /64 (e.g., tethered devices, VMs, etc.). >=20 > I'm not opposed to adding a line to the table, though I don't think it = provides much value - if we put our mind to it, I'm sure we could come up= with lots of things we could add to the table that aren't there at the m= oment. My main concern is that if we add something to the table it needs = to be correct. >=20 > What I mean is =E2=80=9CRequires DAD on the interface over which the pr= efix was received=E2=80=9D, > but that was too long to fit in the table. Let=E2=80=99s call the inter= face =E2=80=9CA=E2=80=9D. If the node gets > SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface =E2=80=9CA= =E2=80=9D, then it needs > to do DAD on interface =E2=80=9CA=E2=80=9D for each such address. If th= e node gets a DHCPv6 PD > over interface =E2=80=9CA=E2=80=9D, however, it does not need to do DAD= over interface =E2=80=9CA=E2=80=9D at all. >=20 > If the node assigns the delegated prefix to interface =E2=80=9CB=E2=80=9D= , then you are right that > that DAD will be required among all tethered devices, VMs, etc. on inte= rface =E2=80=9CB=E2=80=9D. > But, there will still be no need for DAD on interface =E2=80=9CA=E2=80=9D= =2E Does that clarify? >=20 > I have a question also on table 1. Under ""Unlimited" endpoints", why d= oes > it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a= prefix > obtained by DHCPv6 PD can be used to configure an unlimited number of > addresses on the link over which the prefix was received. >=20 > The table is written from the perspective of the network assigning addr= esses to devices that connect to it. Therefore, it says "no" because if y= ou use DHCPv6 PD you can't assign address space to an unlimited number of= endpoints - you are limited to however many /64s you have available. >=20 > If you use IA_NA or SLAAC, any network with a /64 subnet has, at least = in theory, an "unlimited" number of addresses to assign to clients. Of co= urse, that's only true in theory. In practice, there's going to be a limi= t due to scaling reasons. >=20 > I don=E2=80=99t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA= can be used > to assign an unlimited number of addresses to interface =E2=80=9CA=E2=80= =9D. But, so can DHCPv6 > PD. When the node receives the delegated prefix (e.g., a /64), it can a= ssign as > many unique IPv6 addresses as it likes to interface =E2=80=9CA=E2=80=9D= =2E And again, it need not > do DAD for any of them. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Nov 2 17: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 7A8AE1A014C for ; Mon, 2 Nov 2015 17:55:47 -0800 (PST) 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, 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 Zf0vDJ4nx2KB for ; Mon, 2 Nov 2015 17:55:46 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0651A0104 for ; Mon, 2 Nov 2015 17:55:44 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 2 Nov 2015 19:55:43 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f181.google.com [209.85.213.181] #+LO+TS+TR X-Umn-Classification: local Received: by igvi2 with SMTP id i2so60424851igv.0 for ; Mon, 02 Nov 2015 17:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8J7J0XG74TjOvgnErJTzaF6gwLYGNTdItTvH8mKWa8c=; b=HEfkZFO+EVwNqnw0YVobLD5rrbMQYkQdeM+6VRvRrI3xrGoO07RtJwMVvvQnzFHbVw dKyY8yfDfCMPBScCkNLKKyKEphvIMmRaAFDUGDNxKkfg5Ci0HDpdYapyn4uNa7SsAl2u +WpYcM5slt9u4iDrc/V4uu2OKbTfzQOzUYD9Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=8J7J0XG74TjOvgnErJTzaF6gwLYGNTdItTvH8mKWa8c=; b=X0Iy1666SXUKjo/NDPt85iCqfYLWc69aie7oE7HNIotmYsYSEceFm2ONXI85PDzf6o XjjtlZtd+QIR21hY/t86Dusc9+PMu3y8Fup8RvUEXm/bFXDqB168DBSwEqC1pjUmrqka afB7j1yd0YBfeU/x3H77b18O1ofdsDNFgo4VDXr347lsRV2YvpLUXxJTKWmMw2WWfxTx 4oEIgjrda3PY73hsw4cHDl6wTOhXN+j7UHbC1ptujmaWrUqC3cNHvHHWwQFjMVBgSAEu K1gP3WABLlNouCPv13dq8khcKkWakW/Lb6teenkzOoH+q+UvyYa+lqfmZYmgtofK2ODO y5Rw== X-Gm-Message-State: ALoCoQnxa77aoDsjVdpQy3ZU25UQZRzexotUjRyrAsxgbEtm7yEtXPm7YLRB2ZGvMAzTmQbed897XyAvDDljJwjtl8sUrTjjNHsr6DhpHs9JyVtAAV1/XJ5I4Qr8gFBwgbUFyC+yH7FX X-Received: by 10.50.183.39 with SMTP id ej7mr15671094igc.0.1446515742798; Mon, 02 Nov 2015 17:55:42 -0800 (PST) X-Received: by 10.50.183.39 with SMTP id ej7mr15671082igc.0.1446515742607; Mon, 02 Nov 2015 17:55:42 -0800 (PST) Received: from x-10-104-143-11.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:9432:866:7fc4:a980]) by smtp.gmail.com with ESMTPSA id g2sm6932431igi.15.2015.11.02.17.55.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 17:55:41 -0800 (PST) References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> To: Brian E Carpenter , "Templin, Fred L" , Lorenzo Colitti From: David Farmer Organization: University of Minnesota Message-ID: <5638141B.9000609@umn.edu> Date: Mon, 2 Nov 2015 19:55:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563811DF.9020603@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:55:47 -0000 On 11/2/15 19:46 , Brian E Carpenter wrote: > On 03/11/2015 14:31, Templin, Fred L wrote: >> Bumping up one level – is it clear to everyone that it is OK to assign addresses >> taken from a DHCPv6 delegated prefix to the interface over which the prefix >> was received? > > If it was legitimately received, I can't see why it wouldn't be OK. > >> And, that DAD is not required for those addresses? > > How is that safe? What is to stop a host running SLAAC once it > sees that prefix in an RA, and hitting the same IID by chance? > At least you need to specify that the A bit must not be set. > > Come to that, a manual address might collide. And no one has ever screwed up their pseudo-random number generation code. :( -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Nov 2 17:59: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 CD7271A1A2E for ; Mon, 2 Nov 2015 17:59:08 -0800 (PST) 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 oC0EatxSTtzF for ; Mon, 2 Nov 2015 17:59:06 -0800 (PST) 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 3DAFE1A19EF for ; Mon, 2 Nov 2015 17:59:06 -0800 (PST) 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 tA31x8uw013932; Mon, 2 Nov 2015 17:59:08 -0800 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA31x5Nb013923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 17:59:05 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.155]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 17:59:03 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYA== Date: Tue, 3 Nov 2015 01:59:03 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> In-Reply-To: <563811DF.9020603@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] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 01:59:09 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTo0NiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBMb3JlbnpvIENvbGl0dGkNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb djZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9u DQo+IA0KPiBPbiAwMy8xMS8yMDE1IDE0OjMxLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4g QnVtcGluZyB1cCBvbmUgbGV2ZWwg4oCTIGlzIGl0IGNsZWFyIHRvIGV2ZXJ5b25lIHRoYXQgaXQg aXMgT0sgdG8gYXNzaWduIGFkZHJlc3Nlcw0KPiA+IHRha2VuIGZyb20gYSBESENQdjYgZGVsZWdh dGVkIHByZWZpeCB0byB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeA0KPiA+IHdh cyByZWNlaXZlZD8NCj4gDQo+IElmIGl0IHdhcyBsZWdpdGltYXRlbHkgcmVjZWl2ZWQsIEkgY2Fu J3Qgc2VlIHdoeSBpdCB3b3VsZG4ndCBiZSBPSy4NCg0KT0suIFdoZW4gdGhlIERIQ1B2NiBzZXJ2 ZXIgZ3JhbnRzIGEgcHJlZml4IGRlbGVnYXRpb24gdG8gdGhlIGNsaWVudCwNCnRoZSBzZXJ2ZXIg aXMgYXNzZXJ0aW5nIHRoYXQgdGhhdCBwcmVmaXggaXMgdW5pcXVlIGFuZCBpcyBub3cgdGhlIHNv bGUNCnByb3BlcnR5IG9mIHRoZSBjbGllbnQuIFNvLCB3aGVuIHlvdSBzYXkgbGVnaXRpbWF0ZWx5 IHJlY2VpdmVkIEkNCmFncmVlIGFuZCB0aGF0IGlzIGFjdHVhbGx5IGEgY29yZSByZXF1aXJlbWVu dCBvZiBESENQdjYgUEQuDQpPdGhlcndpc2UsIGlmIHRoZSBESENQdjYgc2VydmVyIGdhdmUgb3V0 IGR1cGxpY2F0ZSBwcmVmaXhlcywgdGhlDQpyb3V0aW5nIHN5c3RlbSB3b3VsZCBiZWNvbWUgaG9w ZWxlc3NseSBjb3JydXB0ZWQgYW5kIGFkZHJlc3MNCmR1cGxpY2F0aW9uIHdvdWxkIGJlIHRoZSBs ZWFzdCBvZiBvdXIgd29ycmllcy4NCg0KPiA+IEFuZCwgdGhhdCBEQUQgaXMgbm90IHJlcXVpcmVk IGZvciB0aG9zZSBhZGRyZXNzZXM/DQo+IA0KPiBIb3cgaXMgdGhhdCBzYWZlPyBXaGF0IGlzIHRv IHN0b3AgYSBob3N0IHJ1bm5pbmcgU0xBQUMgb25jZSBpdA0KPiBzZWVzIHRoYXQgcHJlZml4IGlu IGFuIFJBLCBhbmQgaGl0dGluZyB0aGUgc2FtZSBJSUQgYnkgY2hhbmNlPw0KPiBBdCBsZWFzdCB5 b3UgbmVlZCB0byBzcGVjaWZ5IHRoYXQgdGhlIEEgYml0IG11c3Qgbm90IGJlIHNldC4NCg0KSSBh bSB0YWxraW5nIGFib3V0IERBRCBvbiBpbnRlcmZhY2UgIkEiIGJlaW5nIHRoZSBpbnRlcmZhY2Ug b3Zlcg0Kd2hpY2ggdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgcHJlZml4IGRlbGVnYXRpb24uIE5v IG90aGVyIG5vZGUgb24NCmludGVyZmFjZSAiQSIgbWF5IHVzZSB0aGUgZGVsZWdhdGVkIHByZWZp eCwgYW5kIG5vIHJvdXRlciBvbg0KaW50ZXJmYWNlICJBIiBtYXkgYWR2ZXJ0aXNlIHRoZSBwcmVm aXggaW4gYW4gUkEuIFRoZSBwcmVmaXggaXMgdGhlDQpzb2xlIHByb3BlcnR5IG9mIHRoZSBjbGll bnQgdGhhdCByZWNlaXZlZCB0aGUgUEQsIHNvIHRoZSBjbGllbnQgaXMNCmZyZWUgdG8gYXNzaWdu IGFkZHJlc3NlcyB3aXRob3V0IG5lZWRpbmcgREFELg0KDQo+IENvbWUgdG8gdGhhdCwgYSBtYW51 YWwgYWRkcmVzcyBtaWdodCBjb2xsaWRlLg0KDQpUaGUgY2xpZW50IGl0c2VsZiBpcyB0aGUgb25s eSBub2RlIHRoYXQgaXMgcGVybWl0dGVkIHRvIGFzc2lnbiBhZGRyZXNzZXMNCmZyb20gdGhlIGRl bGVnYXRlZCBwcmVmaXggdG8gYW4gaW50ZXJmYWNlLCBzbyB0aGVyZSBpcyBubyByaXNrIG9mDQpj b2xsaXNpb24gdW5sZXNzIHRoZSBjbGllbnQgaXRzZWxmIGlzIHNvbWVob3cgY29ycnVwdC4NCg0K VGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+ICAgICBCcmlhbg0K PiANCj4gPg0KPiA+IFRoYW5rcyAtIEZyZWQNCj4gPg0KPiA+IEZyb206IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlbXBsaW4sIEZyZWQgTA0KPiA+ IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNToyNCBQTQ0KPiA+IFRvOiBMb3Jlbnpv IENvbGl0dGkNCj4gPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KPiA+ DQo+ID4gSGkgTG9yZW56bywNCj4gPg0KPiA+IFJlc3BvbnNlcyBiZWxvdyBpbiDigJxncmVlbuKA nToNCj4gPg0KPiA+IEZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xl LmNvbV0NCj4gPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1IDU6MDQgUE0NCj4gPiBU bzogVGVtcGxpbiwgRnJlZCBMDQo+ID4gQ2M6IEZyZWQgQmFrZXIgKGZyZWQpOyB2Nm9wc0BpZXRm Lm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb24NCj4gPg0KPiA+ IE9uIFR1ZSwgTm92IDMsIDIwMTUgYXQgODo1OSBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3Jv dGU6DQo+ID4gSSBoYXZlIG9uZSB0ZXh0IGFkZGl0aW9uIHN1Z2dlc3Rpb24gYW5kIG9uZSBxdWVz dGlvbi4gT24gUC4gNywgaW4gVGFibGUgMSwNCj4gPiBzdWdnZXN0IGFkZGluZyBhIG5ldyBmaW5h bCByb3cgYXMgZm9sbG93czoNCj4gPg0KPiA+ICAgcmVxdWlyZXMgREFEICAgICAgICAgICAgICAg WWVzICAgICAgICAgICAgICAgICAgWWVzICAgICAgICAgICAgICAgICAgIE5vICAgICAgICAgICAg ICAgICBOL0ENCj4gPg0KPiA+IE1lYW5pbmcgdGhhdCBtdWx0aS1hZGRyZXNzZXMgY29uZmlndXJl ZCBieSBTTEFBQyBvciBESENQdjYgSUFfTkEvSUFfVEENCj4gPiBtdXN0IHVzZSBEQUQgdG8gY2hl Y2sgZm9yIGR1cGxpY2F0ZXMgb24gdGhlIGxpbmsgdGhleSB3ZXJlIG9idGFpbmVkLiBJbiBhDQo+ ID4gbXVsdGktYWRkcmVzc2luZyBlbnZpcm9ubWVudCB3aGVyZSBtaWxsaW9ucyBvZiBhZGRyZXNz ZXMgYXJlIHJlcXVpcmVkLA0KPiA+IHRoaXMgY291bGQgYW1vdW50IHRvIGEgc3Vic3RhbnRpYWwg YW1vdW50IG9mIERBRCBtdWx0aWNhc3QgdHJhZmZpYy4gT24gdGhlDQo+ID4gb3RoZXIgaGFuZCwg REFEIGlzIG5vdCBuZWVkZWQgZm9yIERIQ1B2NiBQRCBiZWNhdXNlIHRoZSBuZXR3b3JrIGhhcw0K PiA+IHVuYW1iaWd1b3VzbHkgZGVsZWdhdGVkIHRoZSBwcmVmaXggZm9yIHRoZSBub2RlJ3MgZXhj bHVzaXZlIHVzZS4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgIlJlcXVpcmVzIERBRDogTm8iIGlz IGNvcnJlY3QuIEV2ZW4gaWYgdGhlIGRldmljZSBnZXRzIGEgLzY0IHByZWZpeCBlbnRpcmVseSBm b3IgaXRzIG93biB1c2UsIGl0IHN0aWxsIG5lZWRzIHRvIGRvIERBRCB3aXRoDQo+IGFueSBvdGhl ciBkZXZpY2VzIG9uIHRoYXQgLzY0IChlLmcuLCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4p Lg0KPiA+DQo+ID4gSSdtIG5vdCBvcHBvc2VkIHRvIGFkZGluZyBhIGxpbmUgdG8gdGhlIHRhYmxl LCB0aG91Z2ggSSBkb24ndCB0aGluayBpdCBwcm92aWRlcyBtdWNoIHZhbHVlIC0gaWYgd2UgcHV0 IG91ciBtaW5kIHRvIGl0LCBJJ20gc3VyZSB3ZSBjb3VsZA0KPiBjb21lIHVwIHdpdGggbG90cyBv ZiB0aGluZ3Mgd2UgY291bGQgYWRkIHRvIHRoZSB0YWJsZSB0aGF0IGFyZW4ndCB0aGVyZSBhdCB0 aGUgbW9tZW50LiBNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBpZiB3ZSBhZGQgc29tZXRoaW5nIHRv DQo+IHRoZSB0YWJsZSBpdCBuZWVkcyB0byBiZSBjb3JyZWN0Lg0KPiA+DQo+ID4gV2hhdCBJIG1l YW4gaXMg4oCcUmVxdWlyZXMgREFEIG9uIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgcHJl Zml4IHdhcyByZWNlaXZlZOKAnSwNCj4gPiBidXQgdGhhdCB3YXMgdG9vIGxvbmcgdG8gZml0IGlu IHRoZSB0YWJsZS4gTGV04oCZcyBjYWxsIHRoZSBpbnRlcmZhY2Ug4oCcQeKAnS4gSWYgdGhlIG5v ZGUgZ2V0cw0KPiA+IFNMQUFDIGFkZHJlc3NlcyBvciBESENQIElBX05BL0lBX1RBIGFkZHJlc3Nl cyBvdmVyIGludGVyZmFjZSDigJxB4oCdLCB0aGVuIGl0IG5lZWRzDQo+ID4gdG8gZG8gREFEIG9u IGludGVyZmFjZSDigJxB4oCdIGZvciBlYWNoIHN1Y2ggYWRkcmVzcy4gSWYgdGhlIG5vZGUgZ2V0 cyBhIERIQ1B2NiBQRA0KPiA+IG92ZXIgaW50ZXJmYWNlIOKAnEHigJ0sIGhvd2V2ZXIsIGl0IGRv ZXMgbm90IG5lZWQgdG8gZG8gREFEIG92ZXIgaW50ZXJmYWNlIOKAnEHigJ0gYXQgYWxsLg0KPiA+ DQo+ID4gSWYgdGhlIG5vZGUgYXNzaWducyB0aGUgZGVsZWdhdGVkIHByZWZpeCB0byBpbnRlcmZh Y2Ug4oCcQuKAnSwgdGhlbiB5b3UgYXJlIHJpZ2h0IHRoYXQNCj4gPiB0aGF0IERBRCB3aWxsIGJl IHJlcXVpcmVkIGFtb25nIGFsbCB0ZXRoZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4gb24gaW50ZXJm YWNlIOKAnELigJ0uDQo+ID4gQnV0LCB0aGVyZSB3aWxsIHN0aWxsIGJlIG5vIG5lZWQgZm9yIERB RCBvbiBpbnRlcmZhY2Ug4oCcQeKAnS4gRG9lcyB0aGF0IGNsYXJpZnk/DQo+ID4NCj4gPiBJIGhh dmUgYSBxdWVzdGlvbiBhbHNvIG9uIHRhYmxlIDEuIFVuZGVyICIiVW5saW1pdGVkIiBlbmRwb2lu dHMiLCB3aHkgZG9lcw0KPiA+IGl0IHNheSAibm8iIGZvciBESENQdjYgUEQ/IEkgdGhpbmsgaXQg c2hvdWxkIHNheSAieWVzIiBpbnN0ZWFkLCBzaW5jZSBhIHByZWZpeA0KPiA+IG9idGFpbmVkIGJ5 IERIQ1B2NiBQRCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUgYW4gdW5saW1pdGVkIG51bWJlciBv Zg0KPiA+IGFkZHJlc3NlcyBvbiB0aGUgbGluayBvdmVyIHdoaWNoIHRoZSBwcmVmaXggd2FzIHJl Y2VpdmVkLg0KPiA+DQo+ID4gVGhlIHRhYmxlIGlzIHdyaXR0ZW4gZnJvbSB0aGUgcGVyc3BlY3Rp dmUgb2YgdGhlIG5ldHdvcmsgYXNzaWduaW5nIGFkZHJlc3NlcyB0byBkZXZpY2VzIHRoYXQgY29u bmVjdCB0byBpdC4gVGhlcmVmb3JlLCBpdCBzYXlzICJubyINCj4gYmVjYXVzZSBpZiB5b3UgdXNl IERIQ1B2NiBQRCB5b3UgY2FuJ3QgYXNzaWduIGFkZHJlc3Mgc3BhY2UgdG8gYW4gdW5saW1pdGVk IG51bWJlciBvZiBlbmRwb2ludHMgLSB5b3UgYXJlIGxpbWl0ZWQgdG8gaG93ZXZlciBtYW55DQo+ IC82NHMgeW91IGhhdmUgYXZhaWxhYmxlLg0KPiA+DQo+ID4gSWYgeW91IHVzZSBJQV9OQSBvciBT TEFBQywgYW55IG5ldHdvcmsgd2l0aCBhIC82NCBzdWJuZXQgaGFzLCBhdCBsZWFzdCBpbiB0aGVv cnksIGFuICJ1bmxpbWl0ZWQiIG51bWJlciBvZiBhZGRyZXNzZXMgdG8gYXNzaWduIHRvDQo+IGNs aWVudHMuIE9mIGNvdXJzZSwgdGhhdCdzIG9ubHkgdHJ1ZSBpbiB0aGVvcnkuIEluIHByYWN0aWNl LCB0aGVyZSdzIGdvaW5nIHRvIGJlIGEgbGltaXQgZHVlIHRvIHNjYWxpbmcgcmVhc29ucy4NCj4g Pg0KPiA+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMuIFRydWUgdGhhdCBTTEFBQyBhbmQgREhD UHY2IElBX05BL0lBX1RBIGNhbiBiZSB1c2VkDQo+ID4gdG8gYXNzaWduIGFuIHVubGltaXRlZCBu dW1iZXIgb2YgYWRkcmVzc2VzIHRvIGludGVyZmFjZSDigJxB4oCdLiBCdXQsIHNvIGNhbiBESENQ djYNCj4gPiBQRC4gV2hlbiB0aGUgbm9kZSByZWNlaXZlcyB0aGUgZGVsZWdhdGVkIHByZWZpeCAo ZS5nLiwgYSAvNjQpLCBpdCBjYW4gYXNzaWduIGFzDQo+ID4gbWFueSB1bmlxdWUgSVB2NiBhZGRy ZXNzZXMgYXMgaXQgbGlrZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEFuZCBhZ2FpbiwgaXQgbmVl ZCBub3QNCj4gPiBkbyBEQUQgZm9yIGFueSBvZiB0aGVtLg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMg bWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCg0K From nobody Mon Nov 2 18:11: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 A715F1A0021 for ; Mon, 2 Nov 2015 18:11:38 -0800 (PST) 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, 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 Y__IEKOQOe52 for ; Mon, 2 Nov 2015 18:11:29 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 371E41AC413 for ; Mon, 2 Nov 2015 18:11:27 -0800 (PST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 2 Nov 2015 20:11:26 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f175.google.com [209.85.223.175] #+LO+TS+TR X-Umn-Classification: local Received: by iody8 with SMTP id y8so5722992iod.1 for ; Mon, 02 Nov 2015 18:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZwLPLrFtCsQ+ZOu+woSSODF5gaDp3oqbgQJ7wu60azQ=; b=NHT7j9xCI+Kqnf4FUsLr8F3ncfx/P9nLJJP22hdsgramh+kulG0wM+qqDk54BSBnYp GWtTGQfxjaKO5eyQ98N5uj0k3Uov3n46enVu8twjM45BREQDEuGphSEF58PVNqsWHyx/ o4v3xJs+ZhJYAo7m+Kmt/WCQZH43J3LHnic8s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=ZwLPLrFtCsQ+ZOu+woSSODF5gaDp3oqbgQJ7wu60azQ=; b=m4encfMKDSwHAiMCiUp2+fcFzEQ6Fpv+OrBPNPbrf6kid9FE6O5Jwbs/79D73prWos w1ruK4WoD7GqFNUQoEh6NBAar7vZXj4A8WRzacoBVduYqLCOu53JG/3lehzTNZOUve0Q ZXVnfznCF6m4xXP+GjIwAmHAaU6CYESlaaeh1Ww0yDri4Fpw4UAXAkdoC2Q+kuScf/uL qENRNNKelXBnyLmfTK15CXv8p4KLI7kTxz4KSZTnt7vqSjSUbbHVEoMl6mO0q2jdrz00 GjM6i3IcFDF5M+uHuXQYrrPbQIALkmNjHjme3it+wa+lADnNBDrefItAGSCRv01MwO0n fA4Q== X-Gm-Message-State: ALoCoQkspuhvzuK5mzAzMM38MHaazEhRBMLMMOtraQ42u/PK7tIwoYLcPeirff3iLKL2nRrwGUchWhvCzK5x0JzSI3OCgOq5aI32JhACAxLQYImZZyVPiW9hhG5eJv7JIpq9AEvj9khC X-Received: by 10.107.18.91 with SMTP id a88mr27556500ioj.91.1446516685741; Mon, 02 Nov 2015 18:11:25 -0800 (PST) X-Received: by 10.107.18.91 with SMTP id a88mr27556483ioj.91.1446516685542; Mon, 02 Nov 2015 18:11:25 -0800 (PST) Received: from x-10-104-143-11.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:9432:866:7fc4:a980]) by smtp.gmail.com with ESMTPSA id lo2sm6950094igb.17.2015.11.02.18.11.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 18:11:24 -0800 (PST) References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> To: "v6ops@ietf.org" From: David Farmer Organization: University of Minnesota Message-ID: <563817CB.6080506@umn.edu> Date: Mon, 2 Nov 2015 20:11:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:11:38 -0000 I thought I brought up this issue previously, but I'd like to see something addressing excessive use of addresses, maybe adding this as an additional paragraph in section 8, recommendations. Conversely, it is RECOMMENDED that hosts and applications not excessively consume IPv6 addresses, such as generating a new address for every connection or with excessive frequency, for instance every few minutes or seconds. A general-purpose host utilizing several hundreds or thousands of IPv6 addresses seems excessive and unjustified in most situations. This could evoke network operators to deploy DHCPv6 simply to apply sanity limits on the number of IPv6 addresses available per host. On 11/1/15 23:15 , Fred Baker (fred) wrote: > In the discussion this morning, we wound up in a position that I could not call "consensus", even "rough consensus", but per a hum of those in the room, within shouting distance of achieving that. Several people spoke at the mike asking for a sentence or brief discussion to be added, or a section clarified. > > In the interest of expediency, let me ask those who spoke (and anyone else that has an issue) to respond to this note (copying the list) with suggested text. It might be best if this is stated as > > OLD TEXT > the text that should be replaced goes here > NEW TEXT > the text that should replace it goes here > > or > > LOCATION > identify the section the text should go into > PROPOSED TEXT > the text that should be added goes here > > I'll permit the authors to declare suggested text out of scope; some of the discussion this morning left them commenting on scope and scope creep. However, I do ask them to justify the exclusion to the list, rather than just ignore the email. > > This comment period ends 15 November. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Nov 2 18:21: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 BE5B41ACDBC for ; Mon, 2 Nov 2015 18:21:14 -0800 (PST) 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 rghAmk8lgiJK for ; Mon, 2 Nov 2015 18:21:12 -0800 (PST) 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 447041ACDCB for ; Mon, 2 Nov 2015 18:19:36 -0800 (PST) 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 tA32Ja8M038770; Mon, 2 Nov 2015 19:19:36 -0700 Received: from XCH-BLV-101.nw.nos.boeing.com (xch-blv-101.nw.nos.boeing.com [130.247.25.116]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA32JVwc038766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 19:19:31 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.14]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 18:19:31 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYIAAB83A Date: Tue, 3 Nov 2015 02:19:30 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3957A@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F394F7@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] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 02:21:15 -0000 QnVtcGluZyB1cCBhZ2FpbiwgaGVyZSBpcyBhIHZhbGlkIGFuZCB1c2VmdWwgaW5zdGFuY2Ugb2Yg bXVsdGlhZGRyZXNzaW5nOg0KDQoxKSBDbGllbnQgZ2V0cyBhIC82NCBwcmVmaXggZGVsZWdhdGlv biBmcm9tIGEgREhDUHY2IHNlcnZlciBvdmVyIGludGVyZmFjZSAiQSINCjIpIENsaWVudCBhc3Np Z25zIHRoZSAvNjQgdG8gYSBsb29wYmFjayBpbnRlcmZhY2UNCjMpIENsaWVudCBhc3NpZ25zIGFz IG1hbnkgYWRkcmVzc2VzIGZyb20gdGhlIC82NCBhcyBpdCBsaWtlcyB0bw0KICAgIGludGVyZmFj ZSAiQSIgKGNvdWxkIGJlIG1pbGxpb25zIG9yIG1vcmUpDQo0KSBDbGllbnQgaXMgYSBwdXJlIGhv c3QgKElQIGZvcndhcmRpbmcgdHVybmVkIG9mZikNCjUpIE5vIERBRCBuZWVkZWQgb24gYW55IGlu dGVyZmFjZQ0KDQpUaGFua3MgLSBGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVGVtcGxpbiwgRnJlZCBMDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTo1 OSBQTQ0KPiBUbzogQnJpYW4gRSBDYXJwZW50ZXI7IExvcmVuem8gQ29saXR0aQ0KPiBDYzogdjZv cHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0 LWFkZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb24NCj4gDQo+IEhpIEJyaWFuLA0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFtt YWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgTm92 ZW1iZXIgMDIsIDIwMTUgNTo0NiBQTQ0KPiA+IFRvOiBUZW1wbGluLCBGcmVkIEw7IExvcmVuem8g Q29saXR0aQ0KPiA+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNd IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4N Cj4gPiBPbiAwMy8xMS8yMDE1IDE0OjMxLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4gPiBC dW1waW5nIHVwIG9uZSBsZXZlbCDigJMgaXMgaXQgY2xlYXIgdG8gZXZlcnlvbmUgdGhhdCBpdCBp cyBPSyB0byBhc3NpZ24gYWRkcmVzc2VzDQo+ID4gPiB0YWtlbiBmcm9tIGEgREhDUHY2IGRlbGVn YXRlZCBwcmVmaXggdG8gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBwcmVmaXgNCj4gPiA+ IHdhcyByZWNlaXZlZD8NCj4gPg0KPiA+IElmIGl0IHdhcyBsZWdpdGltYXRlbHkgcmVjZWl2ZWQs IEkgY2FuJ3Qgc2VlIHdoeSBpdCB3b3VsZG4ndCBiZSBPSy4NCj4gDQo+IE9LLiBXaGVuIHRoZSBE SENQdjYgc2VydmVyIGdyYW50cyBhIHByZWZpeCBkZWxlZ2F0aW9uIHRvIHRoZSBjbGllbnQsDQo+ IHRoZSBzZXJ2ZXIgaXMgYXNzZXJ0aW5nIHRoYXQgdGhhdCBwcmVmaXggaXMgdW5pcXVlIGFuZCBp cyBub3cgdGhlIHNvbGUNCj4gcHJvcGVydHkgb2YgdGhlIGNsaWVudC4gU28sIHdoZW4geW91IHNh eSBsZWdpdGltYXRlbHkgcmVjZWl2ZWQgSQ0KPiBhZ3JlZSBhbmQgdGhhdCBpcyBhY3R1YWxseSBh IGNvcmUgcmVxdWlyZW1lbnQgb2YgREhDUHY2IFBELg0KPiBPdGhlcndpc2UsIGlmIHRoZSBESENQ djYgc2VydmVyIGdhdmUgb3V0IGR1cGxpY2F0ZSBwcmVmaXhlcywgdGhlDQo+IHJvdXRpbmcgc3lz dGVtIHdvdWxkIGJlY29tZSBob3BlbGVzc2x5IGNvcnJ1cHRlZCBhbmQgYWRkcmVzcw0KPiBkdXBs aWNhdGlvbiB3b3VsZCBiZSB0aGUgbGVhc3Qgb2Ygb3VyIHdvcnJpZXMuDQo+IA0KPiA+ID4gQW5k LCB0aGF0IERBRCBpcyBub3QgcmVxdWlyZWQgZm9yIHRob3NlIGFkZHJlc3Nlcz8NCj4gPg0KPiA+ IEhvdyBpcyB0aGF0IHNhZmU/IFdoYXQgaXMgdG8gc3RvcCBhIGhvc3QgcnVubmluZyBTTEFBQyBv bmNlIGl0DQo+ID4gc2VlcyB0aGF0IHByZWZpeCBpbiBhbiBSQSwgYW5kIGhpdHRpbmcgdGhlIHNh bWUgSUlEIGJ5IGNoYW5jZT8NCj4gPiBBdCBsZWFzdCB5b3UgbmVlZCB0byBzcGVjaWZ5IHRoYXQg dGhlIEEgYml0IG11c3Qgbm90IGJlIHNldC4NCj4gDQo+IEkgYW0gdGFsa2luZyBhYm91dCBEQUQg b24gaW50ZXJmYWNlICJBIiBiZWluZyB0aGUgaW50ZXJmYWNlIG92ZXINCj4gd2hpY2ggdGhlIGNs aWVudCByZWNlaXZlcyB0aGUgcHJlZml4IGRlbGVnYXRpb24uIE5vIG90aGVyIG5vZGUgb24NCj4g aW50ZXJmYWNlICJBIiBtYXkgdXNlIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LCBhbmQgbm8gcm91dGVy IG9uDQo+IGludGVyZmFjZSAiQSIgbWF5IGFkdmVydGlzZSB0aGUgcHJlZml4IGluIGFuIFJBLiBU aGUgcHJlZml4IGlzIHRoZQ0KPiBzb2xlIHByb3BlcnR5IG9mIHRoZSBjbGllbnQgdGhhdCByZWNl aXZlZCB0aGUgUEQsIHNvIHRoZSBjbGllbnQgaXMNCj4gZnJlZSB0byBhc3NpZ24gYWRkcmVzc2Vz IHdpdGhvdXQgbmVlZGluZyBEQUQuDQo+IA0KPiA+IENvbWUgdG8gdGhhdCwgYSBtYW51YWwgYWRk cmVzcyBtaWdodCBjb2xsaWRlLg0KPiANCj4gVGhlIGNsaWVudCBpdHNlbGYgaXMgdGhlIG9ubHkg bm9kZSB0aGF0IGlzIHBlcm1pdHRlZCB0byBhc3NpZ24gYWRkcmVzc2VzDQo+IGZyb20gdGhlIGRl bGVnYXRlZCBwcmVmaXggdG8gYW4gaW50ZXJmYWNlLCBzbyB0aGVyZSBpcyBubyByaXNrIG9mDQo+ IGNvbGxpc2lvbiB1bmxlc3MgdGhlIGNsaWVudCBpdHNlbGYgaXMgc29tZWhvdyBjb3JydXB0Lg0K PiANCj4gVGhhbmtzIC0gRnJlZA0KPiBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+IA0KPiA+ ICAgICBCcmlhbg0KPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzIC0gRnJlZA0KPiA+ID4NCj4gPiA+ IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRlbXBsaW4sIEZyZWQgTA0KPiA+ID4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAxNSA1 OjI0IFBNDQo+ID4gPiBUbzogTG9yZW56byBDb2xpdHRpDQo+ID4gPiBDYzogdjZvcHNAaWV0Zi5v cmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRy LWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4gPg0KPiA+ID4gSGkgTG9yZW56bywNCj4gPiA+ DQo+ID4gPiBSZXNwb25zZXMgYmVsb3cgaW4g4oCcZ3JlZW7igJ06DQo+ID4gPg0KPiA+ID4gRnJv bTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPiA+ID4gU2Vu dDogTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAxNSA1OjA0IFBNDQo+ID4gPiBUbzogVGVtcGxpbiwg RnJlZCBMDQo+ID4gPiBDYzogRnJlZCBCYWtlciAoZnJlZCk7IHY2b3BzQGlldGYub3JnPG1haWx0 bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYt djZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4gPg0KPiA+ID4gT24g VHVlLCBOb3YgMywgMjAxNSBhdCA4OjU5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1w bGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToN Cj4gPiA+IEkgaGF2ZSBvbmUgdGV4dCBhZGRpdGlvbiBzdWdnZXN0aW9uIGFuZCBvbmUgcXVlc3Rp b24uIE9uIFAuIDcsIGluIFRhYmxlIDEsDQo+ID4gPiBzdWdnZXN0IGFkZGluZyBhIG5ldyBmaW5h bCByb3cgYXMgZm9sbG93czoNCj4gPiA+DQo+ID4gPiAgIHJlcXVpcmVzIERBRCAgICAgICAgICAg ICAgIFllcyAgICAgICAgICAgICAgICAgIFllcyAgICAgICAgICAgICAgICAgICBObyAgICAgICAg ICAgICAgICAgTi9BDQo+ID4gPg0KPiA+ID4gTWVhbmluZyB0aGF0IG11bHRpLWFkZHJlc3NlcyBj b25maWd1cmVkIGJ5IFNMQUFDIG9yIERIQ1B2NiBJQV9OQS9JQV9UQQ0KPiA+ID4gbXVzdCB1c2Ug REFEIHRvIGNoZWNrIGZvciBkdXBsaWNhdGVzIG9uIHRoZSBsaW5rIHRoZXkgd2VyZSBvYnRhaW5l ZC4gSW4gYQ0KPiA+ID4gbXVsdGktYWRkcmVzc2luZyBlbnZpcm9ubWVudCB3aGVyZSBtaWxsaW9u cyBvZiBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkLA0KPiA+ID4gdGhpcyBjb3VsZCBhbW91bnQgdG8g YSBzdWJzdGFudGlhbCBhbW91bnQgb2YgREFEIG11bHRpY2FzdCB0cmFmZmljLiBPbiB0aGUNCj4g PiA+IG90aGVyIGhhbmQsIERBRCBpcyBub3QgbmVlZGVkIGZvciBESENQdjYgUEQgYmVjYXVzZSB0 aGUgbmV0d29yayBoYXMNCj4gPiA+IHVuYW1iaWd1b3VzbHkgZGVsZWdhdGVkIHRoZSBwcmVmaXgg Zm9yIHRoZSBub2RlJ3MgZXhjbHVzaXZlIHVzZS4NCj4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5r ICJSZXF1aXJlcyBEQUQ6IE5vIiBpcyBjb3JyZWN0LiBFdmVuIGlmIHRoZSBkZXZpY2UgZ2V0cyBh IC82NCBwcmVmaXggZW50aXJlbHkgZm9yIGl0cyBvd24gdXNlLCBpdCBzdGlsbCBuZWVkcyB0byBk byBEQUQgd2l0aA0KPiA+IGFueSBvdGhlciBkZXZpY2VzIG9uIHRoYXQgLzY0IChlLmcuLCB0ZXRo ZXJlZCBkZXZpY2VzLCBWTXMsIGV0Yy4pLg0KPiA+ID4NCj4gPiA+IEknbSBub3Qgb3Bwb3NlZCB0 byBhZGRpbmcgYSBsaW5lIHRvIHRoZSB0YWJsZSwgdGhvdWdoIEkgZG9uJ3QgdGhpbmsgaXQgcHJv dmlkZXMgbXVjaCB2YWx1ZSAtIGlmIHdlIHB1dCBvdXIgbWluZCB0byBpdCwgSSdtIHN1cmUgd2UN Cj4gY291bGQNCj4gPiBjb21lIHVwIHdpdGggbG90cyBvZiB0aGluZ3Mgd2UgY291bGQgYWRkIHRv IHRoZSB0YWJsZSB0aGF0IGFyZW4ndCB0aGVyZSBhdCB0aGUgbW9tZW50LiBNeSBtYWluIGNvbmNl cm4gaXMgdGhhdCBpZiB3ZSBhZGQgc29tZXRoaW5nDQo+IHRvDQo+ID4gdGhlIHRhYmxlIGl0IG5l ZWRzIHRvIGJlIGNvcnJlY3QuDQo+ID4gPg0KPiA+ID4gV2hhdCBJIG1lYW4gaXMg4oCcUmVxdWly ZXMgREFEIG9uIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgcHJlZml4IHdhcyByZWNlaXZl ZOKAnSwNCj4gPiA+IGJ1dCB0aGF0IHdhcyB0b28gbG9uZyB0byBmaXQgaW4gdGhlIHRhYmxlLiBM ZXTigJlzIGNhbGwgdGhlIGludGVyZmFjZSDigJxB4oCdLiBJZiB0aGUgbm9kZSBnZXRzDQo+ID4g PiBTTEFBQyBhZGRyZXNzZXMgb3IgREhDUCBJQV9OQS9JQV9UQSBhZGRyZXNzZXMgb3ZlciBpbnRl cmZhY2Ug4oCcQeKAnSwgdGhlbiBpdCBuZWVkcw0KPiA+ID4gdG8gZG8gREFEIG9uIGludGVyZmFj ZSDigJxB4oCdIGZvciBlYWNoIHN1Y2ggYWRkcmVzcy4gSWYgdGhlIG5vZGUgZ2V0cyBhIERIQ1B2 NiBQRA0KPiA+ID4gb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSwgaG93ZXZlciwgaXQgZG9lcyBub3Qg bmVlZCB0byBkbyBEQUQgb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSBhdCBhbGwuDQo+ID4gPg0KPiA+ ID4gSWYgdGhlIG5vZGUgYXNzaWducyB0aGUgZGVsZWdhdGVkIHByZWZpeCB0byBpbnRlcmZhY2Ug 4oCcQuKAnSwgdGhlbiB5b3UgYXJlIHJpZ2h0IHRoYXQNCj4gPiA+IHRoYXQgREFEIHdpbGwgYmUg cmVxdWlyZWQgYW1vbmcgYWxsIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLiBvbiBpbnRlcmZh Y2Ug4oCcQuKAnS4NCj4gPiA+IEJ1dCwgdGhlcmUgd2lsbCBzdGlsbCBiZSBubyBuZWVkIGZvciBE QUQgb24gaW50ZXJmYWNlIOKAnEHigJ0uIERvZXMgdGhhdCBjbGFyaWZ5Pw0KPiA+ID4NCj4gPiA+ IEkgaGF2ZSBhIHF1ZXN0aW9uIGFsc28gb24gdGFibGUgMS4gVW5kZXIgIiJVbmxpbWl0ZWQiIGVu ZHBvaW50cyIsIHdoeSBkb2VzDQo+ID4gPiBpdCBzYXkgIm5vIiBmb3IgREhDUHY2IFBEPyBJIHRo aW5rIGl0IHNob3VsZCBzYXkgInllcyIgaW5zdGVhZCwgc2luY2UgYSBwcmVmaXgNCj4gPiA+IG9i dGFpbmVkIGJ5IERIQ1B2NiBQRCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUgYW4gdW5saW1pdGVk IG51bWJlciBvZg0KPiA+ID4gYWRkcmVzc2VzIG9uIHRoZSBsaW5rIG92ZXIgd2hpY2ggdGhlIHBy ZWZpeCB3YXMgcmVjZWl2ZWQuDQo+ID4gPg0KPiA+ID4gVGhlIHRhYmxlIGlzIHdyaXR0ZW4gZnJv bSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIG5ldHdvcmsgYXNzaWduaW5nIGFkZHJlc3NlcyB0byBk ZXZpY2VzIHRoYXQgY29ubmVjdCB0byBpdC4gVGhlcmVmb3JlLCBpdCBzYXlzICJubyINCj4gPiBi ZWNhdXNlIGlmIHlvdSB1c2UgREhDUHY2IFBEIHlvdSBjYW4ndCBhc3NpZ24gYWRkcmVzcyBzcGFj ZSB0byBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIGVuZHBvaW50cyAtIHlvdSBhcmUgbGltaXRlZCB0 byBob3dldmVyDQo+IG1hbnkNCj4gPiAvNjRzIHlvdSBoYXZlIGF2YWlsYWJsZS4NCj4gPiA+DQo+ ID4gPiBJZiB5b3UgdXNlIElBX05BIG9yIFNMQUFDLCBhbnkgbmV0d29yayB3aXRoIGEgLzY0IHN1 Ym5ldCBoYXMsIGF0IGxlYXN0IGluIHRoZW9yeSwgYW4gInVubGltaXRlZCIgbnVtYmVyIG9mIGFk ZHJlc3NlcyB0byBhc3NpZ24gdG8NCj4gPiBjbGllbnRzLiBPZiBjb3Vyc2UsIHRoYXQncyBvbmx5 IHRydWUgaW4gdGhlb3J5LiBJbiBwcmFjdGljZSwgdGhlcmUncyBnb2luZyB0byBiZSBhIGxpbWl0 IGR1ZSB0byBzY2FsaW5nIHJlYXNvbnMuDQo+ID4gPg0KPiA+ID4gSSBkb27igJl0IHVuZGVyc3Rh bmQgdGhpcy4gVHJ1ZSB0aGF0IFNMQUFDIGFuZCBESENQdjYgSUFfTkEvSUFfVEEgY2FuIGJlIHVz ZWQNCj4gPiA+IHRvIGFzc2lnbiBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIGFkZHJlc3NlcyB0byBp bnRlcmZhY2Ug4oCcQeKAnS4gQnV0LCBzbyBjYW4gREhDUHY2DQo+ID4gPiBQRC4gV2hlbiB0aGUg bm9kZSByZWNlaXZlcyB0aGUgZGVsZWdhdGVkIHByZWZpeCAoZS5nLiwgYSAvNjQpLCBpdCBjYW4g YXNzaWduIGFzDQo+ID4gPiBtYW55IHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBhcyBpdCBsaWtlcyB0 byBpbnRlcmZhY2Ug4oCcQeKAnS4gQW5kIGFnYWluLCBpdCBuZWVkIG5vdA0KPiA+ID4gZG8gREFE IGZvciBhbnkgb2YgdGhlbS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3Bz QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg== From nobody Mon Nov 2 18:27: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 DEA841A87ED for ; Mon, 2 Nov 2015 18:27:53 -0800 (PST) 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 YQCZ5m0ei_e2 for ; Mon, 2 Nov 2015 18:27:52 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 B855C1ACDB4 for ; Mon, 2 Nov 2015 18:27:52 -0800 (PST) Received: by ykek133 with SMTP id k133so3130814yke.2 for ; Mon, 02 Nov 2015 18:27:52 -0800 (PST) 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=0T5xTy0+KOHlrvr0Wds+du3X8/hhQLOnfWgl6Dgp/gY=; b=HE9l66WDGHVNXidc1TYfDWhfpzIBsKt7FE7WN6fSS3cZLVBICvS4VFJq9ASsWEm92q EG+hxhTl5GaZXUuUT6q00eCJ3oq0oQUdVVgLddsr+WLmvkiq8vW6ka8P42Oxin/YlQ4X YqtxQcHEk9sp3pSByXk+of8o6n5UksjvZ6dmf1DK2ZEGi2R7+vgvB3XCV+sCIkJ5t8ui j2lXdMREcbRJxZMcGupx1GeaGhqmuT1pVKv7PP2YGuL7Avjv1gijxpbr9JQqm4+7eVbA 2jX7QHRnfeB/tuFaPPNRoV47DPEGql1LQHWKAZGWoBVhbY/QlGkfVJKy242fBTR6cRRi hsAQ== 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=0T5xTy0+KOHlrvr0Wds+du3X8/hhQLOnfWgl6Dgp/gY=; b=E6rwpQppqkId6Q+GoLmD3LeWrjjF3nFbEEJAMrFxn6ZeJbPps5BW+AbkNS3CaurRNc D7PHZCmgqFwoBdEHyetUBMX1kNm0ibqWVqlOY31031eStvWDM0r1T/p7TkXcwifeOugz XyRuWe44FB1DZH7OU4MVkVglHUAuV+9LIZxFEYnk1cVk0OsuJu70HAegTPetHSbiu+Sf 1qIfKRK7tFUnLsa+7tArTxXHc1TRNnB+Y2zufOikPFJEbXNu6Z6oruAN61Un9/TaCO2M 3qM9Htdg5EVQMTFxwykcFDT9wX4DSP+1eslmMJTq9+dDOBUn7yI0/bT+DfjpIWd00l47 wmTQ== X-Gm-Message-State: ALoCoQlllW8HaRXf7cFX8WwQEdzXha9fBPm6B3cxZSO7P2h+Kdp3a/IxItXpQbr7OmGKlE6MHzJw X-Received: by 10.13.246.70 with SMTP id g67mr20852061ywf.116.1446517671910; Mon, 02 Nov 2015 18:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 18:27:32 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F3957A@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3957A@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 11:27:32 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=94eb2c0338d4ff66ae052399a376 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 02:27:54 -0000 --94eb2c0338d4ff66ae052399a376 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 11:19 AM, Templin, Fred L wrote: > Bumping up again, here is a valid and useful instance of multiaddressing: > > 1) Client gets a /64 prefix delegation from a DHCPv6 server over interface > "A" > 2) Client assigns the /64 to a loopback interface > 3) Client assigns as many addresses from the /64 as it likes to > interface "A" (could be millions or more) > 4) Client is a pure host (IP forwarding turned off) > 5) No DAD needed on any interface > Why is the client assigning the addresses to interface A instead of loopback? There is no need for the client to respond to ND to those addresses. --94eb2c0338d4ff66ae052399a376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 11:19 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
Bumping up a= gain, here is a valid and useful instance of multiaddressing:

1) Client gets a /64 prefix delegation from a DHCPv6 server over interface = "A"
2) Client assigns the /64 to a loopback interface
3) Client assigns as many addresses from the /64 as it likes to
=C2=A0 =C2=A0 interface "A" (could be millions or more)
4) Client is a pure host (IP forwarding turned off)
5) No DAD needed on any interface

Why i= s the client assigning the addresses to interface A instead of loopback? Th= ere is no need for the client to respond to ND to those addresses.
--94eb2c0338d4ff66ae052399a376-- From nobody Mon Nov 2 18:35: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 74A071ACE54 for ; Mon, 2 Nov 2015 18:35:12 -0800 (PST) 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 c_Ni1G-Oh4Ui for ; Mon, 2 Nov 2015 18:35:08 -0800 (PST) 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 7DBF11ACE53 for ; Mon, 2 Nov 2015 18:35:08 -0800 (PST) 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 tA32ZAwf017389; Mon, 2 Nov 2015 18:35:10 -0800 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA32Z6wh017370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 18:35:06 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.102]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 18:35:03 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYIAAB83AgACJrgD//3rpYA== Date: Tue, 3 Nov 2015 02:35:03 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F395B5@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3957A@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_2134F8430051B64F815C691A62D9831832F395B5XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 02:35:12 -0000 --_000_2134F8430051B64F815C691A62D9831832F395B5XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhlIGNsaWVudCBhc3NpZ25zIHRoZSBhZGRyZXNzZXMgdG8gaW50ZXJm YWNlIOKAnEHigJ0gaW5zdGVhZCBvZiB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlDQpiZWNhdXNlIG90 aGVyd2lzZSBpdCB3b3VsZCBoYXZlIG5vIHdheSBvZiBrbm93aW5nIHRoYXQgcGFja2V0cyB3aXRo IGEgc291cmNlDQphZGRyZXNzIHRha2VuIGZyb20gdGhlIHByZWZpeCBuZWVkIHRvIGdvIG91dCBp bnRlcmZhY2Ug4oCcQeKAnS4gVGhhdCBpcyBiZWNhdXNlIHRoZQ0KcHJlZml4IGl0c2VsZiBpcyBh c3NpZ25lZCB0byB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIHNvIGFkZHJlc3NlcyBuZWVkIHRvIGJl DQphc3NpZ25lZCB0byBpbnRlcmZhY2Ug4oCcQeKAnSB0byBkaXNhc3NvY2lhdGUgdGhlbSBmcm9t IHRoZSBsb29wYmFjayBpbnRlcmZhY2UuDQoNCkZyZWQNCg0KRnJvbTogTG9yZW56byBDb2xpdHRp IFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMiwg MjAxNSA2OjI4IFBNDQpUbzogVGVtcGxpbiwgRnJlZCBMDQpDYzogQnJpYW4gRSBDYXJwZW50ZXI7 IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWhv c3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KDQpPbiBUdWUsIE5vdiAzLCAyMDE1IGF0 IDExOjE5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFp bHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCkJ1bXBpbmcgdXAgYWdhaW4s IGhlcmUgaXMgYSB2YWxpZCBhbmQgdXNlZnVsIGluc3RhbmNlIG9mIG11bHRpYWRkcmVzc2luZzoN Cg0KMSkgQ2xpZW50IGdldHMgYSAvNjQgcHJlZml4IGRlbGVnYXRpb24gZnJvbSBhIERIQ1B2NiBz ZXJ2ZXIgb3ZlciBpbnRlcmZhY2UgIkEiDQoyKSBDbGllbnQgYXNzaWducyB0aGUgLzY0IHRvIGEg bG9vcGJhY2sgaW50ZXJmYWNlDQozKSBDbGllbnQgYXNzaWducyBhcyBtYW55IGFkZHJlc3NlcyBm cm9tIHRoZSAvNjQgYXMgaXQgbGlrZXMgdG8NCiAgICBpbnRlcmZhY2UgIkEiIChjb3VsZCBiZSBt aWxsaW9ucyBvciBtb3JlKQ0KNCkgQ2xpZW50IGlzIGEgcHVyZSBob3N0IChJUCBmb3J3YXJkaW5n IHR1cm5lZCBvZmYpDQo1KSBObyBEQUQgbmVlZGVkIG9uIGFueSBpbnRlcmZhY2UNCg0KV2h5IGlz IHRoZSBjbGllbnQgYXNzaWduaW5nIHRoZSBhZGRyZXNzZXMgdG8gaW50ZXJmYWNlIEEgaW5zdGVh ZCBvZiBsb29wYmFjaz8gVGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIGNsaWVudCB0byByZXNwb25k IHRvIE5EIHRvIHRob3NlIGFkZHJlc3Nlcy4NCg== --_000_2134F8430051B64F815C691A62D9831832F395B5XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY2xpZW50IGFzc2lnbnMgdGhlIGFkZHJl c3NlcyB0byBpbnRlcmZhY2Ug4oCcQeKAnSBpbnN0ZWFkIG9mIHRoZSBsb29wYmFjayBpbnRlcmZh Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YmVjYXVzZSBvdGhlcndpc2UgaXQgd291bGQgaGF2ZSBubyB3 YXkgb2Yga25vd2luZyB0aGF0IHBhY2tldHMgd2l0aCBhIHNvdXJjZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5hZGRyZXNzIHRha2VuIGZyb20gdGhlIHByZWZpeCBuZWVkIHRvIGdvIG91dCBpbnRlcmZhY2Ug 4oCcQeKAnS4gVGhhdCBpcyBiZWNhdXNlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5wcmVmaXggaXRz ZWxmIGlzIGFzc2lnbmVkIHRvIHRoZSBsb29wYmFjayBpbnRlcmZhY2Ugc28gYWRkcmVzc2VzIG5l ZWQgdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YXNzaWduZWQgdG8gaW50ZXJmYWNlIOKAnEHigJ0g dG8gZGlzYXNzb2NpYXRlIHRoZW0gZnJvbSB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVu em8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1IDY6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBs aW4sIEZyZWQgTDxicj4NCjxiPkNjOjwvYj4gQnJpYW4gRSBDYXJwZW50ZXI7IHY2b3BzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9z dC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMywg MjAxNSBhdCAxMToxOSBBTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CdW1waW5nIHVwIGFnYWluLCBoZXJlIGlzIGEgdmFsaWQgYW5kIHVz ZWZ1bCBpbnN0YW5jZSBvZiBtdWx0aWFkZHJlc3Npbmc6PGJyPg0KPGJyPg0KMSkgQ2xpZW50IGdl dHMgYSAvNjQgcHJlZml4IGRlbGVnYXRpb24gZnJvbSBhIERIQ1B2NiBzZXJ2ZXIgb3ZlciBpbnRl cmZhY2UgJnF1b3Q7QSZxdW90Ozxicj4NCjIpIENsaWVudCBhc3NpZ25zIHRoZSAvNjQgdG8gYSBs b29wYmFjayBpbnRlcmZhY2U8YnI+DQozKSBDbGllbnQgYXNzaWducyBhcyBtYW55IGFkZHJlc3Nl cyBmcm9tIHRoZSAvNjQgYXMgaXQgbGlrZXMgdG88YnI+DQombmJzcDsgJm5ic3A7IGludGVyZmFj ZSAmcXVvdDtBJnF1b3Q7IChjb3VsZCBiZSBtaWxsaW9ucyBvciBtb3JlKTxicj4NCjQpIENsaWVu dCBpcyBhIHB1cmUgaG9zdCAoSVAgZm9yd2FyZGluZyB0dXJuZWQgb2ZmKTxicj4NCjUpIE5vIERB RCBuZWVkZWQgb24gYW55IGludGVyZmFjZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGlzIHRoZSBjbGllbnQgYXNzaWduaW5n IHRoZSBhZGRyZXNzZXMgdG8gaW50ZXJmYWNlIEEgaW5zdGVhZCBvZiBsb29wYmFjaz8gVGhlcmUg aXMgbm8gbmVlZCBmb3IgdGhlIGNsaWVudCB0byByZXNwb25kIHRvIE5EIHRvIHRob3NlIGFkZHJl c3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D9831832F395B5XCHBLV504nwnosb_-- From nobody Mon Nov 2 18:36: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 032C01ACE54 for ; Mon, 2 Nov 2015 18:36:11 -0800 (PST) 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 8xfftnUSw23t for ; Mon, 2 Nov 2015 18:36:09 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 1DCEB1ACE3F for ; Mon, 2 Nov 2015 18:36:09 -0800 (PST) Received: by ykba4 with SMTP id a4so3200711ykb.3 for ; Mon, 02 Nov 2015 18:36:08 -0800 (PST) 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=MGzxUY1N6p5fK9rs8jJQa9ZrRCNxziU9RypQRaFAefo=; b=pwX1ObuRZM5IgkrJT9A6xkj3CnSj46F8QedTJqCLel1almobFAXozA4/PJxfYZu0ru rNL/e6Y48D9Vc6jy003Btez35pNyXTwrGpn/V3WynNwZr5HylB9DObIV56zBv/g+GaPl o3OhImxpCQU1W2ki4CHnCF6YtimJ0BMPz9O8eMY/3LkULZ8l/bjOQmdXBEaX1dyqX4bd suqAFOxqooluwmBTnuCrLv83j79etSNzldpkTGBD0fnN5BjfpwFqG/CG6mFVVrkhtSLS m4q00KZZi/2W/KWM39BJEKd+dGg4Qd9gLg+qvOFdnBrekv+OXYiug2il4JSEInZAODip 6hlQ== 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=MGzxUY1N6p5fK9rs8jJQa9ZrRCNxziU9RypQRaFAefo=; b=je/TGZ2oeaHd/apsi9hAEtOGiZHNKhVmgia6skYdajyL+u3l2WdGcd9oYrGwfsb0Hh AOtNPQ7LowyLLMi3Vn0l906GBJzl8E0EFRYoKDlNUwqfl/XEuPpXctgFMg+UpFFWZtFi P554ELl4zANGLaTpgintmQnlf+3rFEL15VUiXw32CYmIkkDjAAnggUDhNHFiANVtMqWa tKidb3m9UtBNSkrMqhXJhYcOChfsbxkciz+yEk4KjSLdZOtgl1hvB2z0wN8GzCe25Y3S 9fOjMtFdD9CgVgkk+pgzuNz/LUVU5+yYMx/pS4V0k4umpN6iSAgJjmNuVYFib/Z+5t39 6UQg== X-Gm-Message-State: ALoCoQlJxxMAaooob2ovyFHRaSRV+EUXJ5Ih6aamdXHYxwvMq1nHBDI81sYisQtNlDMzAU2wWTdb X-Received: by 10.129.137.198 with SMTP id z189mr19091853ywf.307.1446518168271; Mon, 02 Nov 2015 18:36:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 18:35:48 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 11:35:48 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=94eb2c06bf26952310052399c14a Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 02:36:11 -0000 --94eb2c06bf26952310052399c14a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 3, 2015 at 10:24 AM, Templin, Fred L wrote: > > I don't think "Requires DAD: No" is correct. Even if the device gets a /6= 4 > prefix entirely for its own use, it still needs to do DAD with any other > devices on that /64 (e.g., tethered devices, VMs, etc.). > > > > I'm not opposed to adding a line to the table, though I don't think it > provides much value - if we put our mind to it, I'm sure we could come up > with lots of things we could add to the table that aren't there at the > moment. My main concern is that if we add something to the table it needs > to be correct. > > > > What I mean is =E2=80=9CRequires DAD on the interface over which the pref= ix was > received=E2=80=9D, > > but that was too long to fit in the table. Let=E2=80=99s call the interfa= ce =E2=80=9CA=E2=80=9D. > If the node gets > > SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface =E2=80=9CA= =E2=80=9D, then it > needs > > to do DAD on interface =E2=80=9CA=E2=80=9D for each such address. If the = node gets a > DHCPv6 PD > > over interface =E2=80=9CA=E2=80=9D, however, it does not need to do DAD o= ver interface =E2=80=9CA=E2=80=9D > at all. > > > > If the node assigns the delegated prefix to interface =E2=80=9CB=E2=80=9D= , then you are > right that > > that DAD will be required among all tethered devices, VMs, etc. on > interface =E2=80=9CB=E2=80=9D. > > But, there will still be no need for DAD on interface =E2=80=9CA=E2=80=9D= . Does that > clarify? > I didn't need clarification, I already knew what you meant. My point is that: - I don't think we can clarify it without overflowing the space in the table cell - If we clarify it using text outside the table cell, then that means we need to explain the other table rows as well, for consistency. - That opens us up to fresh discussions on what text to write in those explanations, which could potentially become long and involved. - It's not clear to me that the above is worth having this extra row in the table. Thus I'd prefer not to an extra row. > I have a question also on table 1. Under ""Unlimited" endpoints", why doe= s > it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a > prefix > obtained by DHCPv6 PD can be used to configure an unlimited number of > addresses on the link over which the prefix was received. > > > > The table is written from the perspective of the network assigning > addresses to devices that connect to it. Therefore, it says "no" because = if > you use DHCPv6 PD you can't assign address space to an unlimited number o= f > endpoints - you are limited to however many /64s you have available. > > > > If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in > theory, an "unlimited" number of addresses to assign to clients. Of cours= e, > that's only true in theory. In practice, there's going to be a limit due = to > scaling reasons. > > > > I don=E2=80=99t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA c= an be used > > to assign an unlimited number of addresses to interface =E2=80=9CA=E2=80= =9D. But, so can > DHCPv6 > > PD. When the node receives the delegated prefix (e.g., a /64), it can > assign as > > many unique IPv6 addresses as it likes to interface =E2=80=9CA=E2=80=9D. = And again, it > need not > > do DAD for any of them. > I think you're confusing unlimited addresses with unlimited endpoints. With IA_NA or SLAAC, you can number billions of endpoints, each of which might only have a few addresses. With DHCPv6 PD, you can only number as many endpoints as you have /64s. Each of those endpoints might be using an unlimited number of addresses, but there is still a limited number of them. --94eb2c06bf26952310052399c14a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 10:24 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

I don't think "Requires DAD: No&= quot; is correct. Even if the device gets a /64 prefix entirely for its own= use, it still needs to do DAD with any other devices on that /64 (e.g., te= thered devices, VMs, etc.).

=C2=A0

I'm not opposed to adding a line to the table, t= hough I don't think it provides much value - if we put our mind to it, = I'm sure we could come up with lots of things we could add to the table= that aren't there at the moment. My main concern is that if we add something to the table it needs to be correct.=

=C2=A0

What I mean is =E2=80=9CRequir= es DAD on the interface over which the prefix was received=E2=80=9D,=

but that was too long to fit in the t= able. Let=E2=80=99s call the interface =E2=80=9CA=E2=80=9D. If the node get= s

SLAAC addresses or DHCP IA_NA/IA_TA a= ddresses over interface =E2=80=9CA=E2=80=9D, then it needs

to do DAD on interface =E2=80=9CA=E2= =80=9D for each such address. If the node gets a DHCPv6 PD

over interface =E2=80=9CA=E2=80=9D, h= owever, it does not need to do DAD over interface =E2=80=9CA=E2=80=9D at al= l.

=C2=A0

If the node assigns the delegated pre= fix to interface =E2=80=9CB=E2=80=9D, then you are right that=

that DAD will be required among all t= ethered devices, VMs, etc. on interface =E2=80=9CB=E2=80=9D.<= /span>

But, there will still be no need for = DAD on interface =E2=80=9CA=E2=80=9D. Does that clarify?


I didn&#= 39;t need clarification, I already knew what you meant. My point is that:
  • I don't think we can clarify it without overflowing th= e space in the table cell
  • If we clarify it using text outside the t= able cell, then that means we need to explain the other table rows as well,= for consistency.
  • That opens us up to fresh discussions on what tex= t to write in those explanations, which could potentially become long and i= nvolved.
  • It's not clear to me that the above is worth having th= is extra row in the table.
Thus I'd prefer not to an extr= a row.

I have a question also on table 1. Under ""= ;Unlimited" endpoints", why does
it say "no" for DHCPv6 PD? I think it should say "yes" = instead, since a prefix
obtained by DHCPv6 PD can be used to configure an unlimited number of
addresses on the link over which the prefix was received.

=C2=A0

The table is written from the perspective of the net= work assigning addresses to devices that connect to it. Therefore, it says = "no" because if you use DHCPv6 PD you can't assign address sp= ace to an unlimited number of endpoints - you are limited to however many /64s you have available.

=C2=A0

If you use IA_NA or SLAAC, any network with a /64 su= bnet has, at least in theory, an "unlimited" number of addresses = to assign to clients. Of course, that's only true in theory. In practic= e, there's going to be a limit due to scaling reasons.

=C2=A0

I don=E2=80=99t understand thi= s. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used<= /p>

to assign an unlimited number of addr= esses to interface =E2=80=9CA=E2=80=9D. But, so can DHCPv6

PD. When the node receives the delega= ted prefix (e.g., a /64), it can assign as

many unique IPv6 addresses as it like= s to interface =E2=80=9CA=E2=80=9D. And again, it need not

do DAD for any of them.=


I think you're = confusing unlimited addresses with unlimited endpoints. With IA_NA or SLAAC= , you can number billions of endpoints, each of which might only have a few= addresses. With DHCPv6 PD, you can only number as many endpoints as you ha= ve /64s. Each of those endpoints might be using an unlimited number of addr= esses, but there is still a limited number of them.
--94eb2c06bf26952310052399c14a-- From nobody Mon Nov 2 18:54: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 E48441ACDFB for ; Mon, 2 Nov 2015 18:54:39 -0800 (PST) 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 eydUbsrRocBP for ; Mon, 2 Nov 2015 18:54:37 -0800 (PST) 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 85C851ACD69 for ; Mon, 2 Nov 2015 18:54:37 -0800 (PST) Received: by pasz6 with SMTP id z6so4493167pas.2 for ; Mon, 02 Nov 2015 18:54:37 -0800 (PST) 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=Vkp3gl/yzkrExPkqIq5VAbJQb/7FNRmxeK6EdJ1RCoo=; b=OLKzC5iJ5BedOY8aVBwNp1jLPAa+KVtrk/jSS/WKeaAm9QE5yzFqlDycKfmL8imecR gBr9y9LfjaD5sjMqW0gZpNkKy6W9upZmbRuu4nQReuHexvwOJIpemUm58grFD+zMxWfF apFtqHZ64ng7i1k8nsRROEoWy+w5vTDwx1n3ZLOTKktf9U1AX8lSszTYlZD67vQQkvog 99YvYuUsWFRPzcnYZL29ygCFYwHG/UaGwFu4J3jl9YpuSXR8Qgv8qQQSiuhb8izMwq5j MGjfUxMUMZMJo52+o7c1UiOBPJHfc0PqNO81ljAFSi5F19o+XXyeLLQPQT3hLmlcCWB4 bnGQ== X-Received: by 10.66.218.230 with SMTP id pj6mr31351771pac.104.1446519277241; Mon, 02 Nov 2015 18:54:37 -0800 (PST) Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ia3sm26561043pbb.5.2015.11.02.18.54.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 18:54:36 -0800 (PST) To: "Templin, Fred L" , Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563821EB.3040508@gmail.com> Date: Tue, 3 Nov 2015 15:54:35 +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: <2134F8430051B64F815C691A62D9831832F394F7@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" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 02:54:40 -0000 Hi Fred, On 03/11/2015 14:59, Templin, Fred L wrote: > Hi Brian, >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, November 02, 2015 5:46 PM >> To: Templin, Fred L; Lorenzo Colitti >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussio= n >> >> On 03/11/2015 14:31, Templin, Fred L wrote: >>> Bumping up one level =E2=80=93 is it clear to everyone that it is OK = to assign addresses >>> taken from a DHCPv6 delegated prefix to the interface over which the = prefix >>> was received? >> >> If it was legitimately received, I can't see why it wouldn't be OK. >=20 > OK. When the DHCPv6 server grants a prefix delegation to the client, > the server is asserting that that prefix is unique and is now the sole > property of the client. So, when you say legitimately received I > agree and that is actually a core requirement of DHCPv6 PD. > Otherwise, if the DHCPv6 server gave out duplicate prefixes, the > routing system would become hopelessly corrupted and address > duplication would be the least of our worries. >=20 >>> And, that DAD is not required for those addresses? >> >> How is that safe? What is to stop a host running SLAAC once it >> sees that prefix in an RA, and hitting the same IID by chance? >> At least you need to specify that the A bit must not be set. >=20 > I am talking about DAD on interface "A" being the interface over > which the client receives the prefix delegation. No other node on > interface "A" may use the delegated prefix, and no router on > interface "A" may advertise the prefix in an RA. The prefix is the > sole property of the client that received the PD, so the client is > free to assign addresses without needing DAD. That usage of "may" might confuse some people, so let's pretend you used a "MUST NOT" construct instead. I could still construct a host stack that would ignore the issue: its logic would be "I sent an RS and got no RA/PIO with A=3D1; but I see traffic from prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix." >> Come to that, a manual address might collide. >=20 > The client itself is the only node that is permitted to assign addresse= s > from the delegated prefix to an interface, so there is no risk of > collision unless the client itself is somehow corrupt. Or another client on the same LAN gets too clever. Brian >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> Brian >> >>> >>> Thanks - Fred >>> >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fre= d L >>> Sent: Monday, November 02, 2015 5:24 PM >>> To: Lorenzo Colitti >>> Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussi= on >>> >>> Hi Lorenzo, >>> >>> Responses below in =E2=80=9Cgreen=E2=80=9D: >>> >>> From: Lorenzo Colitti [mailto:lorenzo@google.com] >>> Sent: Monday, November 02, 2015 5:04 PM >>> To: Templin, Fred L >>> Cc: Fred Baker (fred); v6ops@ietf.org >>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussi= on >>> >>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > wrote: >>> I have one text addition suggestion and one question. On P. 7, in Tab= le 1, >>> suggest adding a new final row as follows: >>> >>> requires DAD Yes Yes = No N/A >>> >>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_T= A >>> must use DAD to check for duplicates on the link they were obtained. = In a >>> multi-addressing environment where millions of addresses are required= , >>> this could amount to a substantial amount of DAD multicast traffic. O= n the >>> other hand, DAD is not needed for DHCPv6 PD because the network has >>> unambiguously delegated the prefix for the node's exclusive use. >>> >>> I don't think "Requires DAD: No" is correct. Even if the device gets = a /64 prefix entirely for its own use, it still needs to do DAD with >> any other devices on that /64 (e.g., tethered devices, VMs, etc.). >>> >>> I'm not opposed to adding a line to the table, though I don't think i= t provides much value - if we put our mind to it, I'm sure we could >> come up with lots of things we could add to the table that aren't ther= e at the moment. My main concern is that if we add something to >> the table it needs to be correct. >>> >>> What I mean is =E2=80=9CRequires DAD on the interface over which the = prefix was received=E2=80=9D, >>> but that was too long to fit in the table. Let=E2=80=99s call the int= erface =E2=80=9CA=E2=80=9D. If the node gets >>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface =E2=80=9C= A=E2=80=9D, then it needs >>> to do DAD on interface =E2=80=9CA=E2=80=9D for each such address. If = the node gets a DHCPv6 PD >>> over interface =E2=80=9CA=E2=80=9D, however, it does not need to do D= AD over interface =E2=80=9CA=E2=80=9D at all. >>> >>> If the node assigns the delegated prefix to interface =E2=80=9CB=E2=80= =9D, then you are right that >>> that DAD will be required among all tethered devices, VMs, etc. on in= terface =E2=80=9CB=E2=80=9D. >>> But, there will still be no need for DAD on interface =E2=80=9CA=E2=80= =9D. Does that clarify? >>> >>> I have a question also on table 1. Under ""Unlimited" endpoints", why= does >>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since= a prefix >>> obtained by DHCPv6 PD can be used to configure an unlimited number of= >>> addresses on the link over which the prefix was received. >>> >>> The table is written from the perspective of the network assigning ad= dresses to devices that connect to it. Therefore, it says "no" >> because if you use DHCPv6 PD you can't assign address space to an unli= mited number of endpoints - you are limited to however many >> /64s you have available. >>> >>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at leas= t in theory, an "unlimited" number of addresses to assign to >> clients. Of course, that's only true in theory. In practice, there's g= oing to be a limit due to scaling reasons. >>> >>> I don=E2=80=99t understand this. True that SLAAC and DHCPv6 IA_NA/IA_= TA can be used >>> to assign an unlimited number of addresses to interface =E2=80=9CA=E2= =80=9D. But, so can DHCPv6 >>> PD. When the node receives the delegated prefix (e.g., a /64), it can= assign as >>> many unique IPv6 addresses as it likes to interface =E2=80=9CA=E2=80=9D= =2E And again, it need not >>> do DAD for any of them. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >=20 From nobody Mon Nov 2 18:56: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 97D741ACE60 for ; Mon, 2 Nov 2015 18:56:10 -0800 (PST) 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 mn2Rtc2jK58v for ; Mon, 2 Nov 2015 18:56:07 -0800 (PST) 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 61EB11ACE5D for ; Mon, 2 Nov 2015 18:56:07 -0800 (PST) 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 tA32u5o5031776 for ; Tue, 3 Nov 2015 03:56:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BBAAF201CF6 for ; Tue, 3 Nov 2015 04:02:02 +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 B2F5120160D for ; Tue, 3 Nov 2015 04:02:02 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA32u0qZ005300 for ; Tue, 3 Nov 2015 03:56:03 +0100 To: v6ops@ietf.org References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <5638223E.5090404@gmail.com> Date: Tue, 3 Nov 2015 11:55:58 +0900 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: <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 02:56:10 -0000 Le 03/11/2015 10:31, Templin, Fred L a écrit : > Bumping up one level – is it clear to everyone that it is OK to > assign addresses taken from a DHCPv6 delegated prefix to the interface over which the > prefix was received? And, that DAD is not required for those addresses? This indeed new enough at least to me. I agree that if the prefix is delegated for Host with DHCP-PD then it has a tighter bind to that Host, tighter than a prefix _advertised_ to it with an RA. In that sense, certainly yes the Host may self-form and assign an address on its interface over which the application DHCP-PD received it earlier. And, since the prefix is administratively unique, it would make little sense for the Host to DAD that address on that interface. Moreover, it would bring some advantages for privacy. Privacy addresses as we know them make only the IID variable, while still keeping a trackable prefix (the advertised prefix). With this way of prefix delegation, the Host may decide more ways to obfuscate its identity: use sometimes the allocated prefix, other times the advertised prefix, in some hard-to-detect sequence. But, if a Host forms an address out of the delegated prefix and wants to talk to its Gateway on that interface, maybe it wants to send an RA to that Gateway so the Gateway forms an address out of the delegated prefix too. At that point DAD would be needed. Alex > > Thanks - Fred > > *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Templin, > Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:* Lorenzo > Colitti *Cc:* v6ops@ietf.org *Subject:* Re: [v6ops] > draft-ietf-v6ops-host-addr-availability discussion > > Hi Lorenzo, > > Responses below in “green”: > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* Monday, > November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:* Fred Baker > (fred); v6ops@ietf.org *Subject:* Re: [v6ops] > draft-ietf-v6ops-host-addr-availability discussion > > On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > > > wrote: > > I have one text addition suggestion and one question. On P. 7, in > Table 1, suggest adding a new final row as follows: > > requires DAD Yes Yes No > N/A > > Meaning that multi-addresses configured by SLAAC or DHCPv6 > IA_NA/IA_TA must use DAD to check for duplicates on the link they > were obtained. In a multi-addressing environment where millions of > addresses are required, this could amount to a substantial amount of > DAD multicast traffic. On the other hand, DAD is not needed for > DHCPv6 PD because the network has unambiguously delegated the prefix > for the node's exclusive use. > > I don't think "Requires DAD: No" is correct. Even if the device gets > a /64 prefix entirely for its own use, it still needs to do DAD with > any other devices on that /64 (e.g., tethered devices, VMs, etc.). > > I'm not opposed to adding a line to the table, though I don't think > it provides much value - if we put our mind to it, I'm sure we could > come up with lots of things we could add to the table that aren't > there at the moment. My main concern is that if we add something to > the table it needs to be correct. > > What I mean is “Requires DAD on the interface over which the prefix > was received”, > > but that was too long to fit in the table. Let’s call the interface > “A”. If the node gets > > SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, > then it needs > > to do DAD on interface “A” for each such address. If the node gets a > DHCPv6 PD > > over interface “A”, however, it does not need to do DAD over > interface “A” at all. > > If the node assigns the delegated prefix to interface “B”, then you > are right that > > that DAD will be required among all tethered devices, VMs, etc. on > interface “B”. > > But, there will still be no need for DAD on interface “A”. Does that > clarify? > > I have a question also on table 1. Under ""Unlimited" endpoints", why > does it say "no" for DHCPv6 PD? I think it should say "yes" instead, > since a prefix obtained by DHCPv6 PD can be used to configure an > unlimited number of addresses on the link over which the prefix was > received. > > The table is written from the perspective of the network assigning > addresses to devices that connect to it. Therefore, it says "no" > because if you use DHCPv6 PD you can't assign address space to an > unlimited number of endpoints - you are limited to however many /64s > you have available. > > If you use IA_NA or SLAAC, any network with a /64 subnet has, at > least in theory, an "unlimited" number of addresses to assign to > clients. Of course, that's only true in theory. In practice, there's > going to be a limit due to scaling reasons. > > I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can > be used > > to assign an unlimited number of addresses to interface “A”. But, so > can DHCPv6 > > PD. When the node receives the delegated prefix (e.g., a /64), it can > assign as > > many unique IPv6 addresses as it likes to interface “A”. And again, > it need not > > do DAD for any of them. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 2 19: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 556961ACEBB for ; Mon, 2 Nov 2015 19:04:03 -0800 (PST) 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 Qu1IDjHpBLEt for ; Mon, 2 Nov 2015 19:04:02 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 6014E1ACEB2 for ; Mon, 2 Nov 2015 19:04:02 -0800 (PST) Received: by ykek133 with SMTP id k133so3739772yke.2 for ; Mon, 02 Nov 2015 19:04:01 -0800 (PST) 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=H9iuavxm6GvBN8G+uFyl6MVP9awB+iemE66SSghYtrw=; b=gNBi6mRZDp0uZh+LJ5X4npPAsU5zRhqnWuTvHwySqs05oYuCDqdtFBbMvbh5gLkauU WzddTncr0JnQrrdKGNrD3Z1HzmFteTEvcFYDMnGyDhzRWs9AmYKEhT40bVYZCp8tzuD2 yWV2E3vnv6VfxIsinwXqp69R9c7GRpkgOICRbjeND45WOb8LgW6/iN9TAIZ7blYkTlI6 7O7krpxb1QtCeGwUbs3TSDwPqwSTEFfO74PL5A7zIhEEnENmIm3teHjJ4eyyQq5peQnQ 5m2JWBMfM6rHWcEZRCSwqZwJ8GDitg7cnYW01O995tpHq/UYLRHSgJjam7v7Xrq3tNtv i4fA== 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=H9iuavxm6GvBN8G+uFyl6MVP9awB+iemE66SSghYtrw=; b=a40FAh1GQSGHKHCC3/PCmemyS2VV7lPYN2QG6dsaAwMpjMuvCRAuGxUuKfmjXv3J+N US2SXlCa48oZH8JmqbF4qMKv8my3cZBZddN+lN2FtzJb4Ydq/DAhMRJpHYNF3gU/XXy4 6zXk1EbM0EyAQoqcwgyeOZVyMC5IGCHTZst0hcf7m+jIz1/himY80jts3cG0BhwaB3Af NRlXm3JVkNaJd8Dt4A2ZexTvlkPraLuU/IO/tYO3AZxMfQl0PguAGljlLVbpYCy6J/VY XhAQdsHPMiHoQtHfquHzd3aU0aMAazEfG8RXqUYRdzcBV+TNgY1F6+Uw5zS/+DipKeFX cn/A== X-Gm-Message-State: ALoCoQlMIjwtolDCq+4T2aR6ZRGjIaw2qlPZIiMetS4n3i1w2mvVPvHuT7pv8xPWur2s42nW6yVS X-Received: by 10.129.136.5 with SMTP id y5mr4621029ywf.35.1446519841398; Mon, 02 Nov 2015 19:04:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 19:03:41 -0800 (PST) In-Reply-To: <5638223E.5090404@gmail.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 12:03:41 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114effba4f085505239a257f Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 03:04:03 -0000 --001a114effba4f085505239a257f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 3, 2015 at 11:55 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > Le 03/11/2015 10:31, Templin, Fred L a =C3=A9crit : > >> Bumping up one level =E2=80=93 is it clear to everyone that it is OK to >> assign addresses taken from a DHCPv6 delegated prefix to the interface >> over which the >> prefix was received? And, that DAD is not required for those addresses? >> > Is this a statement we need to make in this draft, though? --001a114effba4f085505239a257f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 11:55 AM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
Le 03/11/2015 10:31, Templin, Fred L a =C3=A9crit :
Bumping up one level =E2=80=93 is it clear to everyone that it is OK to
assign addresses taken from a DHCPv6 delegated prefix to the interface over= which the
prefix was received? And, that DAD is not required for those addresses?
=

Is this a statement we need t= o make in this draft, though?
--001a114effba4f085505239a257f-- From nobody Mon Nov 2 19:05: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 BC7EB1ACF04 for ; Mon, 2 Nov 2015 19:05:11 -0800 (PST) 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 R1UnnSzVT4GC for ; Mon, 2 Nov 2015 19:05:09 -0800 (PST) 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 5E76E1ACEEE for ; Mon, 2 Nov 2015 19:05:09 -0800 (PST) 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 tA3357kV000945; Tue, 3 Nov 2015 04:05:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BEA6D201CF6; Tue, 3 Nov 2015 04:11:04 +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 B340D200FD3; Tue, 3 Nov 2015 04:11:04 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA33518C027973; Tue, 3 Nov 2015 04:05:05 +0100 To: Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <5637401A.1050807@gmail.com> From: Alexandre Petrescu Message-ID: <5638245C.7080401@gmail.com> Date: Tue, 3 Nov 2015 12:05:00 +0900 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 WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 03:05:11 -0000 Le 03/11/2015 09:28, Lorenzo Colitti a Ă©crit : > On Mon, Nov 2, 2015 at 7:51 PM, Alexandre Petrescu > > wrote: > > The right recommendation is the following: > > "in a 3GPP network which uses exclusively SLAAC for IPv6 address > configuration on the UE the network must not limit its ability to set > multiple distinct IPv6 prefixes in a RA to the UE. By default there > should be two." > > > On 3GPP there is only one Prefix Information Option in the RA - > http://tools.ietf.org/html/rfc6459#section-5.2 . We can't change that > because the behaviour is defined by 3GPP, not IETF. We might be able to > ask 3GPP to change it, but I don't think this document is the place to > do that. 3GPP networks already fulfill the spirit of this draft by > providing an entire /64 to each device. I wanted to avoid, but again it loops to me not understanding the spirit of the draft. Maybe it's only me. Is there any other network that does _not_ provide a /64 to the Host? > This is not a good example either. One wouldn't give an > INFORMATIONAL document as a recommendation to follow. > > > It's not a recommendation to follow, it's just an example of how having > multiple addresses can allow future applications. > > An example of how the availability of multiple addresses per > host has > already stimulated successful new applications: > [...] > o tethering. In tethering a UE such as a smartphone connects > several IP devices on its LAN through the access network and to > the Internet. This is realized with DHCPv6-PD [AERO] or some > other techniques like "/64 sharing" [RFC7278] or other forms of > bridging. > > > I'm not sure that tethering is a good example for this section. It's > existed for a long time, so it's not really a new application, and we > already mention it in an earlier section in the draft. Sure, tethering was there already, and in the text as well. All I changed is the way the draft mentions tethering, by putting first DHCPv6-PD. If need is, I can give more text with example of more standard protocols based on Mobile IP that achieve the same tethering. Alex From nobody Mon Nov 2 19:08: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 C8C951AD06C for ; Mon, 2 Nov 2015 19:08:25 -0800 (PST) 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 Bm2ZlL3_fXOU for ; Mon, 2 Nov 2015 19:08:25 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 D20CD1AD069 for ; Mon, 2 Nov 2015 19:08:24 -0800 (PST) Received: by ykba4 with SMTP id a4so3743011ykb.3 for ; Mon, 02 Nov 2015 19:08:24 -0800 (PST) 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=3S/Tpzg1ct2vbT+x2VsfYamZSxjzbaPMRgD0UOZFzEI=; b=ivNlpYXb8i7nskSBvFMqDcVyL9rj93T+NkocxMVbX0VyCZZNmyg6Z6U/sO3WXucusz DA0CaCNUiWEE9vJl9J7LAHj+wYyrAqPbRXm+eDmzHqQIfaZVlPMP5s4JoX1zyUQ9ptVq EeR2DeQi3W96p+8zwLqDWM0amV/z5bcSQpc4HzPL3OyIStxUCHDk4CAPCBJv1/XOWUGT WZg+gL7zwLJ/Bugn+TifylDBvLkpfGRzh8xvqC/CKC3zbPR/f7j+AnGiKwIdSPvGlii8 oKjPiruXPXGeqeeA28kRSYUC7wrbJa//Fh2ycOYwPL6F+4dDRtja5drxh1sF+qWsthH7 y7yg== 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=3S/Tpzg1ct2vbT+x2VsfYamZSxjzbaPMRgD0UOZFzEI=; b=BrrrSGl43zga0I/4q7/oCgT4HKsrm/9FAuqYn/auHW9B+gpyhDN2mq2j+iN8tfKfEz XffAm53AnEaP0SSd/w9g8a8MNolxE+xihygP2+3krTJ3kO1hhzgyjs2cyehS4ZhWfB5I TrB25MUL0OqJYqWMUIsB4OW61OiKbzHrU+7iJkQUrzVu6/hikamd53d/eI4acYs6uCL9 jmK4mOJq8E7LDAbja303HsPMTxjlddzC2xiyQhHAZTkVOTy47hdeFG4xURjrMGChMQa2 k0tiJ35GeuY+8JLAwxBvwMPl2z7uEAQ46b6vGJegzTeQqECxLy08K9C1pMGoylPSd585 Q/Zg== X-Gm-Message-State: ALoCoQlQGOewXNKR/OuHsdMbZ1Tg6/mvDiT92mGqyd6oj2EhLfTk8y5qgZFC9czYAprpBep5hvQM X-Received: by 10.13.204.73 with SMTP id o70mr21132594ywd.337.1446520104063; Mon, 02 Nov 2015 19:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 19:08:04 -0800 (PST) In-Reply-To: <5638245C.7080401@gmail.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <5637401A.1050807@gmail.com> <5638245C.7080401@gmail.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 12:08:04 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a11481d4af7118505239a3427 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 03:08:25 -0000 --001a11481d4af7118505239a3427 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 12:05 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Is there any other network that does _not_ provide a /64 to the Host? Sure. You can configure a network that only provides addresses via DHCPv6. --001a11481d4af7118505239a3427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 12:05 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
Is t= here any other network that does _not_ provide a /64 to the Host?

Sure. You can configure a network that only provides= addresses via DHCPv6.
--001a11481d4af7118505239a3427-- From nobody Mon Nov 2 19:13: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 8421A1AD333 for ; Mon, 2 Nov 2015 19:13:57 -0800 (PST) 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 D42sTGzyPZSb for ; Mon, 2 Nov 2015 19:13:56 -0800 (PST) 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 3B7BD1AD2F2 for ; Mon, 2 Nov 2015 19:13:56 -0800 (PST) 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 tA33Drr4002593; Tue, 3 Nov 2015 04:13:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 79B90201EFD; Tue, 3 Nov 2015 04:19:51 +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 64176201EE6; Tue, 3 Nov 2015 04:19:51 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA33Dmh0000402; Tue, 3 Nov 2015 04:13:51 +0100 To: Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <5637401A.1050807@gmail.com> <5638245C.7080401@gmail.com> From: Alexandre Petrescu Message-ID: <5638266B.8030502@gmail.com> Date: Tue, 3 Nov 2015 12:13:47 +0900 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 WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 03:13:57 -0000 Le 03/11/2015 12:08, Lorenzo Colitti a Ă©crit : > On Tue, Nov 3, 2015 at 12:05 PM, Alexandre Petrescu > > wrote: > > Is there any other network that does _not_ provide a /64 to the Host? > > > Sure. You can configure a network that only provides addresses via DHCPv6. One can't do that because no default route. Alex From nobody Mon Nov 2 20:24: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 0E55F1B2D2B for ; Mon, 2 Nov 2015 20:24:42 -0800 (PST) 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 xFk03aR-P3wb for ; Mon, 2 Nov 2015 20:24:37 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id B13191B2D2D for ; Mon, 2 Nov 2015 20:24:37 -0800 (PST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 2 Nov 2015 22:24:34 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f177.google.com [209.85.223.177] #+LO+TS+TR X-Umn-Classification: local Received: by iody8 with SMTP id y8so7854840iod.1 for ; Mon, 02 Nov 2015 20:24:34 -0800 (PST) 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=+r+q3hmIyj87yJrNVwovDGu8czVt5muu66CfrOx2lkw=; b=rvw1JcJys+9z+j7OdpTrs5R2DE9KhSR7NqXXybojcuZ66PaFeRpW9TdIYgr2VwUsPO 18d7KiTpAFUPKKBGgXsy2Ku6nPzkhoMI2ONfUJErKVhZawDItEpEK6dcAbe9xbAxRj9i dWF0+/7VAwsR/jhJce7+F6iZZbik7VC/NGfEA= 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=+r+q3hmIyj87yJrNVwovDGu8czVt5muu66CfrOx2lkw=; b=V0pCFH9j/e/ZIiW0T0fTPosc+LOwQlcrLdicQQtHZI7dw2+UEODfIE0sNTQOk4vv5c EE1A6oaBXdhRK6SRI9418GJ1dYrWzRBiW3d8+MnJcgXNvBOWaxekwAwQlUMqc1kbHbhb P5m/occU3uxH7eBdVB3cYqxzvXwX8ZItYqjhm6qs0lVoggEV82pmzOqTKRdsoI7nAETT wi2ToRtS4aZotY+vocXraGf50CR7bw6X/5v6YAVsJIVzbxoQlZUohvcex8RB9IFDUR0l r2YBRO/d6dQ/Uy7oytVapMcxIWU8hLymF0gzkphqzZO+iWOAfE5wSKjWZq+9dVhmH+OW mRwQ== X-Gm-Message-State: ALoCoQmHPcLmsfknYFlAneud+Z/6DplOwMHP5UJ7+haAaYLcLFGw2T/axwaJ5aY2Ykf57QNUzYTzyB1i4aXA6fYGPZWEp6pQ3CrTkKGkKsp02V3p5M19OXdauXOmUMbdK8RagCyW4wGi X-Received: by 10.107.184.70 with SMTP id i67mr30751794iof.42.1446524674211; Mon, 02 Nov 2015 20:24:34 -0800 (PST) X-Received: by 10.107.184.70 with SMTP id i67mr30751786iof.42.1446524674048; Mon, 02 Nov 2015 20:24:34 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id d7sm7121651igl.1.2015.11.02.20.24.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 20:24:32 -0800 (PST) References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <5637401A.1050807@gmail.com> <5638245C.7080401@gmail.com> <5638266B.8030502@gmail.com> In-Reply-To: <5638266B.8030502@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (13B143) From: David Farmer Date: Mon, 2 Nov 2015 22:24:31 -0600 To: Alexandre Petrescu Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 04:24:42 -0000 > On Nov 2, 2015, at 21:13, Alexandre Petrescu wrote: >=20 > Le 03/11/2015 12:08, Lorenzo Colitti a =C3=A9crit : >> On Tue, Nov 3, 2015 at 12:05 PM, Alexandre Petrescu >> > wrot= e: >>=20 >> Is there any other network that does _not_ provide a /64 to the Host? >>=20 >>=20 >> Sure. You can configure a network that only provides addresses via DHCPv6= . >=20 > One can't do that because no default route. >=20 > Alex If you set the A=3D0, M=3D1 in the RA, a host can only get an address via DH= CPv6 and it is not allowed to use SLAAC. Furthermore, ISC and other DHCPv6 s= ervers allow you to limit the number of addresses a host can have. I think i= t is "limit-addrs-per-ia" for ISC, and I think it defaults to 1. --=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 Nov 2 20:39: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 602C11B2DA8 for ; Mon, 2 Nov 2015 20:39:11 -0800 (PST) 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 GEvPZlyWasME for ; Mon, 2 Nov 2015 20:39:09 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 847AD1B2D9C for ; Mon, 2 Nov 2015 20:39:09 -0800 (PST) Received: by ykdr3 with SMTP id r3so5195297ykd.1 for ; Mon, 02 Nov 2015 20:39:08 -0800 (PST) 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=JIDylqV02fEgu1jJM0G/83BTB/4FrSJUBj2u5KhR85o=; b=h4A7Toy8O1fnNdl5xp2yizvISt4MirMobAMuCtZ6VkJwwz+4l2tQwQS9p+ozZzt4Ia Srl5LQKype2P59NlU3jwgyTTKDvKumwJ56SH6SYGrkPZ7Qr+tvIIIFeKCtFD6HDWhYsJ SxXhzHRHArltAH8byP2XvCKKR7mIFhuxPMCeL+iSjNlE4ZPpBZaFmgL1cOI6MTG6hUOH BFv/mbnZrDFgrATpoSS/jGPMZDEPcUCPu1wRbpFeiZbOFEsR5qhgpX2QOhAIR9A3C2gg 5qX+FvZc6vMTxMCbvoO0ito+CNsUr4uibKl42PSzZOMITt6IjgUXtUvpAeOM2DTidaDp 0zyw== 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=JIDylqV02fEgu1jJM0G/83BTB/4FrSJUBj2u5KhR85o=; b=PYPn63sJFIXfLNPGtzVTpolYhEzVDhGhM2SE861EEcCRyncJ4cfq8/65qz4i8eSw6P gUFamr9woxLtVNBMSxmgZUhjX88y4BD9XvE36FJlKQnSKiYVZWJ9w5XbPC9OAdjpLdvL L07RZC4w4pN5U5jkvB23gOx6ajvXkFAT4R1MiRkfO14RKTtdS4N4Bt58E0FI8tcfhgFK C0SXeV8ElvPQzf3EFMIq07GqzH6ylXq+kzqVL5r9B7lBcaQ0iok31vprNYkocFygVBSb T1JuKfUMAexSqzzd7WnwEkqGY7f0ugs5SAxpxgrj6Vl/in+811TEQDzTPwrpBc9xce7U cwYg== X-Gm-Message-State: ALoCoQlAM/2ZT0BJbLQWLo2EPaVf7DZfWN/yeiyZKk63HPe2AkSmqT6OXjgZZxTZKgdylV+dhnIp X-Received: by 10.129.44.3 with SMTP id s3mr19176629yws.141.1446525548689; Mon, 02 Nov 2015 20:39:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 20:38:49 -0800 (PST) In-Reply-To: <563817CB.6080506@umn.edu> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <563817CB.6080506@umn.edu> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 13:38:49 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a114278de7d710605239b79e8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 04:39:11 -0000 --001a114278de7d710605239b79e8 Content-Type: text/plain; charset=UTF-8 David, that statement makes sense, but I'm worried about scope creep. The document is focused on recommendations to network operators; if we start adding recommendations to hosts as well, that might well change the scope of the draft substantially, and might be the start of a process that results in a large amount of text being added and takes substantial time to complete. Example: adding that recommendation to the recommendations section might result in criticism that that recommendation is not adequately justified/motivated by the rest of the draft's text. The response to that criticism might be to add text to the draft to motivate it, but that text would obviously need to go through the WG, we'd have to gain consensus on it, etc. Also, on the text itself: if a host is given an IPv6 prefix via DHCPv6 PD, I don't know if it's "excessive and unjustified" for it to decide, for example, to use a different IPv6 address for each server it talks to. The extra load on the network might well be nil. Cheers, Lorenzo On Tue, Nov 3, 2015 at 11:11 AM, David Farmer wrote: > I thought I brought up this issue previously, but I'd like to see > something addressing excessive use of addresses, maybe adding this as an > additional paragraph in section 8, recommendations. > > Conversely, it is RECOMMENDED that hosts and applications not > excessively consume IPv6 addresses, such as generating a new address > for every connection or with excessive frequency, for instance every > few minutes or seconds. A general-purpose host utilizing several > hundreds or thousands of IPv6 addresses seems excessive and > unjustified in most situations. This could evoke network operators > to deploy DHCPv6 simply to apply sanity limits on the number of > IPv6 addresses available per host. > > > > On 11/1/15 23:15 , Fred Baker (fred) wrote: > >> In the discussion this morning, we wound up in a position that I could >> not call "consensus", even "rough consensus", but per a hum of those in the >> room, within shouting distance of achieving that. Several people spoke at >> the mike asking for a sentence or brief discussion to be added, or a >> section clarified. >> >> In the interest of expediency, let me ask those who spoke (and anyone >> else that has an issue) to respond to this note (copying the list) with >> suggested text. It might be best if this is stated as >> >> OLD TEXT >> the text that should be replaced goes here >> NEW TEXT >> the text that should replace it goes here >> >> or >> >> LOCATION >> identify the section the text should go into >> PROPOSED TEXT >> the text that should be added goes here >> >> I'll permit the authors to declare suggested text out of scope; some of >> the discussion this morning left them commenting on scope and scope creep. >> However, I do ask them to justify the exclusion to the list, rather than >> just ignore the email. >> >> This comment period ends 15 November. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114278de7d710605239b79e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

that statement makes sense, but = I'm worried about scope creep. The document is focused on recommendatio= ns to network operators; if we start adding recommendations to hosts as wel= l, that might well change the scope of the draft substantially, and might b= e the start of a process that results in a large amount of text being added= and takes substantial time to complete.

Example: = adding that recommendation to the recommendations section might result in c= riticism that that recommendation is not adequately justified/motivated by = the rest of the draft's text. The response to that criticism might be t= o add text to the draft to motivate it, but that text would obviously need = to go through the WG, we'd have to gain consensus on it, etc.

Also, on the text itself: if a host is given an IPv6 prefix= via DHCPv6 PD, I don't know if it's "excessive and unjustifie= d" for it to decide, for example, to use a different IPv6 address for = each server it talks to. The extra load on the network might well be nil.

Cheers,
Lorenzo

On Tue, Nov 3, 2015 at 11:11 AM= , David Farmer <farmer@umn.edu> wrote:
I thought I brought up this issue previously, but I'd like to= see something addressing excessive use of addresses, maybe adding this as = an additional paragraph in section 8, recommendations.

=C2=A0 =C2=A0Conversely, it is RECOMMENDED that hosts and applications not<= br> =C2=A0 =C2=A0excessively consume IPv6 addresses, such as generating a new a= ddress
=C2=A0 =C2=A0for every connection or with excessive frequency, for instance= every
=C2=A0 =C2=A0few minutes or seconds.=C2=A0 A general-purpose host utilizing= several
=C2=A0 =C2=A0hundreds or thousands of IPv6 addresses seems excessive and =C2=A0 =C2=A0unjustified in most situations. This could evoke network opera= tors
=C2=A0 =C2=A0to deploy DHCPv6 simply to apply sanity limits on the number o= f
=C2=A0 =C2=A0IPv6 addresses available per host.



On 11/1/15 23:15 , Fred Baker (fred) wrote:
In the discussion this morning, we wound up in a position that I could not = call "consensus", even "rough consensus", but per a hum= of those in the room, within shouting distance of achieving that. Several = people spoke at the mike asking for a sentence or brief discussion to be ad= ded, or a section clarified.

In the interest of expediency, let me ask those who spoke (and anyone else = that has an issue) to respond to this note (copying the list) with suggeste= d text. It might be best if this is stated as

OLD TEXT
the text that should be replaced goes here
NEW TEXT
the text that should replace it goes here

or

LOCATION
identify the section the text should go into
PROPOSED TEXT
the text that should be added goes here

I'll permit the authors to declare suggested text out of scope; some of= the discussion this morning left them commenting on scope and scope creep.= However, I do ask them to justify the exclusion to the list, rather than j= ust ignore the email.

This comment period ends 15 November.



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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: <= a href=3D"mailto:farmer@umn.edu" target=3D"_blank">farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0Phone: 1-612-626-0815
Minneapolis, MN 55414-3029=C2=A0 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=3D

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

--001a114278de7d710605239b79e8-- From nobody Mon Nov 2 20:51: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 40FC21B2D73 for ; Mon, 2 Nov 2015 20:51:03 -0800 (PST) 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 PVmpomPbskuE for ; Mon, 2 Nov 2015 20:51:00 -0800 (PST) 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 475191B2DD5 for ; Mon, 2 Nov 2015 20:50:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV75578; Tue, 03 Nov 2015 04:50:56 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 Nov 2015 04:50:53 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 12:50:45 +0800 From: "Liubing (Leo)" To: "Howard, Lee" , "'IPv6 Operations'" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFc2B3a5k3jNVg0ytx1KEdeZRp56I8SYAgADIgyA= Date: Tue, 3 Nov 2015 04:50:45 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C23196B9@nkgeml506-mbx.china.huawei.com> References: <5637FDD0.70300@jvknet.com> 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.194.186.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56383D31.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 04:51:03 -0000 Hi Lee, Thanks for the note. Their reviews will definitely help. Btw, if it is possible, can you help to change the draft identity from "dra= ft-ietf-v6ops-ula-usage-recommendations" to " draft-ietf-v6ops-ula-usage-co= nsiderations"? I think it is good to align with the draft's title, and more= important, it could avoid unnecessary confusion of this work's intent.=20 Many thanks for your help. Best regards, Bing -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Tuesday, November 03, 2015 9:49 AM To: Victor Kuarsingh; 'IPv6 Operations' Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and= Brian Carpenter. Can I ask each of you to do a review of the current docum= ent, and send comments to the mailing list? That will give the authors and= the WG something to work from. Following that, we can discuss whether we need additional discussion at a m= eeting, or WGLC. Thanks, Lee On 11/3/15, 9:20 AM, "Victor Kuarsingh" wrote: >WG, > >My input is that we should continue this work. Given ULAs are already=20 >in use, having a document which outlines those use cases is, in my=20 >mind, operationally beneficial. > >Perhaps we should be more clear that we would not be recommending the=20 >use of ULAs, but keep to a unbiased document which outlines how they=20 >have been used (just a use case discussion). We can also include=20 >objective technical points as to the pros/cons related to each use case. > >It was also noted in another email (based on WG v6ops discussion=20 >yesterday), that one such valid example was Cable Modem management IPs=20 >assigned ULA based addressing. This is a valid technical use case. > >I am willing to help if required on this document. > >regards, > >Victor K > >On 2015-11-02 6:17 PM, Howard, Lee wrote: >> This document hasn=B9t had any revisions or discussion in a while. >> Is there anyone interested in working on it? >> >> If we do not hear any interest, we will abandon this draft. >> >> Thanks, >> Lee >> >> >> ________________________________ >> >> This E-mail and any of its attachments may contain Time Warner Cable=20 >>proprietary information, which is privileged, confidential, or subject=20 >>to copyright belonging to Time Warner Cable. This E-mail is intended=20 >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby=20 >>notified that any dissemination, distribution, copying, or action=20 >>taken in relation to the contents of and attachments to this E-mail is=20 >>strictly prohibited and may be unlawful. If you have received this=20 >>E-mail in error, please notify the sender immediately and permanently=20 >>delete the original and any copy of this E-mail and any printout. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 2 20:55: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 2AE2E1ACDE7 for ; Mon, 2 Nov 2015 20:55:49 -0800 (PST) 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 LPAruPqwrKXx for ; Mon, 2 Nov 2015 20:55:47 -0800 (PST) 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 C0FE21B2DA6 for ; Mon, 2 Nov 2015 20:55:46 -0800 (PST) Received: by ykft191 with SMTP id t191so5476328ykf.0 for ; Mon, 02 Nov 2015 20:55:46 -0800 (PST) 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=DnHkXTiRsfaLGfCljpbokT53IYQ/y/SWrBunnhIIr/k=; b=mi6DQEvErMxMOqHgB+c6Y5tydiumU+H7CE3BSw3INDGtBTWK99rvln3oagBop2Ui3r jCaE4snf2GX7LLAWfSHMo4sarvj0IrEwkCdtofk3awrtxea8wwjMIVX1GVSjhq/++Fm6 byrGV5H4nbfrQquDyoFMmiyasnwtjhcuVGxg3kwo5dwqkqINdMsjVkmTQQ4qkin+pEoo Lzp8olgFUN6Tt2QkLt4uIXHp7sHI4EF0Ro18lLgl3NMj+V2Ya7uZKac+r++2xVhL4J8Y bwe1KqrJprHDHzpREMZgtnm060Ray29iJ7LHtBKhplOMb1cTXGC9aFEJ2jIl+d6kipMY dFQg== 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=DnHkXTiRsfaLGfCljpbokT53IYQ/y/SWrBunnhIIr/k=; b=mb+kJfjSnAT181CWpt8o3g/BLUVKLwGvXIwljKh00qXCWOetVuCwlxX8y1wiaLiyWk TMJWc/0MKITpm3TFvudT8ii0k5dmv+dCeVVkBm6ZpyvGrD5PoGJJW6qLa68UpmuSdmfP g6E2KQdYRkJCNV+g13n0BqMY6jDtAjayCxJQNkGauzOQLEhS+3oTi4jJ1QIXGl2bXtNN cJ0NjsCK5hN5vdCogdbua/Bpfh3JW8QuUvQVqAR9pFPeY3UO1qLgaV9CrlqiFPCq8hl6 yHMVKVwgbNiFpAWrFoHZxCoX2l3+30hz1LHNTLvoP6p3CrHsdP1uRdvZ9Y4asA1PY/Sr vDlA== X-Gm-Message-State: ALoCoQkh39Sk6WSl7AYXAbRUWD4zbu/o4KWRHWDJa3/2DTVTM6ZlvXsDtDYW8SYSphun7yNYxLdK X-Received: by 10.129.44.3 with SMTP id s3mr19206717yws.141.1446526546017; Mon, 02 Nov 2015 20:55:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 20:55:26 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 13:55:26 +0900 Message-ID: To: "Howard, Lee" Content-Type: multipart/alternative; boundary=001a114278deef61b305239bb499 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 04:55:49 -0000 --001a114278deef61b305239bb499 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My recollection is that we never got around to publishing this document because we never managed to agree on what to say in the recommendations. I think that because the working group does not actually have consensus on what ULAs should be used for. Generalizing and handwaving a bit, I think that the major disagreement is between: 1. Some proponents of ULAs are suggesting that ULAs (are being | can be | should be) used in similar ways to RFC 1918, including using them behi= nd NPT66 or in the absence of global addresses, and say that the document should list those as use cases. 2. A fair number of WG members are vehemently opposed to such uses, and say that WG documents should explicitly call out such practices as harmful. We heard a few of those members at the mike yesterday during th= e discussion of the design choices draft. For as long as that disagreement exists, it will be hard to make a recommendation, which is likely to make it hard to get consensus on this draft. We can go through that disagreement again, but I don't personally think the outcome will be any different from the one we had last time around. I happen to be in camp #2 and would be happy to support this draft if it said that ULA-only deployments, NPT66 and NAT66 are harmful and should be avoided. But I'm sure a fair number of people disagree with me. On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee wrote: > I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, a= nd > Brian Carpenter. Can I ask each of you to do a review of the current > document, and send comments to the mailing list? That will give the > authors > and the WG something to work from. > > Following that, we can discuss whether we need additional discussion at a > meeting, or WGLC. > > Thanks, > > Lee > > > On 11/3/15, 9:20 AM, "Victor Kuarsingh" wrote: > > >WG, > > > >My input is that we should continue this work. Given ULAs are already > >in use, having a document which outlines those use cases is, in my mind, > >operationally beneficial. > > > >Perhaps we should be more clear that we would not be recommending the > >use of ULAs, but keep to a unbiased document which outlines how they > >have been used (just a use case discussion). We can also include > >objective technical points as to the pros/cons related to each use case. > > > >It was also noted in another email (based on WG v6ops discussion > >yesterday), that one such valid example was Cable Modem management IPs > >assigned ULA based addressing. This is a valid technical use case. > > > >I am willing to help if required on this document. > > > >regards, > > > >Victor K > > > >On 2015-11-02 6:17 PM, Howard, Lee wrote: > >> This document hasn=C2=B9t had any revisions or discussion in a while. > >> Is there anyone interested in working on it? > >> > >> If we do not hear any interest, we will abandon this draft. > >> > >> Thanks, > >> Lee > >> > >> > >> ________________________________ > >> > >> This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is addressed= . > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114278deef61b305239bb499 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My recollection is that we never got around to publishing = this document because we never managed to agree on what to say in the recom= mendations. I think=C2=A0that because the working group does not actually h= ave consensus on what ULAs should be used for.=C2=A0

Gen= eralizing and handwaving a bit, I think that the major disagreement is betw= een:
  1. Some proponents of ULAs are suggesting that ULAs (ar= e being | can be | should be) used in similar ways to RFC 1918, including u= sing them behind NPT66 or in the absence of global addresses, and say that = the document should list those as use cases.
  2. A fair number of W= G members are vehemently opposed to such uses, and say that WG documents sh= ould explicitly call out such practices as harmful.=C2=A0We heard a few of = those members at the mike yesterday during the discussion of the design cho= ices draft.
For as long as that disagreement exists, it w= ill be hard to make a recommendation, which is likely to make it hard to ge= t consensus on this draft. We can go through that disagreement again, but I= don't personally think the outcome will be any different from the one = we had last time around.

I happen to be in c= amp #2 and would be happy to support this draft if it said that ULA-only de= ployments, NPT66 and NAT66 are harmful and should be avoided. But I'm s= ure a fair number of people disagree with me.

On Tue, Nov 3, 2015 at 9:49 AM, How= ard, Lee <lee.howard@twcable.com> wrote:
I see interest from Victor Kuarsingh, David Farmer, Ale= xandre Petrescu, and
Brian Carpenter. Can I ask each of you to do a review of the current
document, and send comments to the mailing list?=C2=A0 That will give the authors
and the WG something to work from.

Following that, we can discuss whether we need additional discussion at a meeting, or WGLC.

Thanks,

Lee


On 11/3/15, 9:20 AM, "Victor Kuarsingh" <victor@jvknet.com> wrote:

>WG,
>
>My input is that we should continue this work.=C2=A0 Given ULAs are alr= eady
>in use, having a document which outlines those use cases is, in my mind= ,
>operationally beneficial.
>
>Perhaps we should be more clear that we would not be recommending the >use of ULAs, but keep to a unbiased document which outlines how they >have been used (just a use case discussion).=C2=A0 We can also include<= br> >objective technical points as to the pros/cons related to each use case= .
>
>It was also noted in another email (based on WG v6ops discussion
>yesterday), that one such valid example was Cable Modem management IPs<= br> >assigned ULA based addressing.=C2=A0 This is a valid technical use case= .
>
>I am willing to help if required on this document.
>
>regards,
>
>Victor K
>
>On 2015-11-02 6:17 PM, Howard, Lee wrote:
>> This document hasn=C2=B9t had any revisions or discussion in a whi= le.
>> Is there anyone interested in working on it?
>>
>> If we do not hear any interest, we will abandon this draft.
>>
>> Thanks,
>> Lee
>>
>>
>> ________________________________
>>
>> This E-mail and any of its attachments may contain Time Warner Cab= le
>>proprietary information, which is privileged, confidential, or subj= ect
>>to copyright belonging to Time Warner Cable. This E-mail is intende= d
>>solely for the use of the individual or entity to which it is addre= ssed.
>>If you are not the intended recipient of this E-mail, you are hereb= y
>>notified that any dissemination, distribution, copying, or action t= aken
>>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this<= br> >>E-mail in error, please notify the sender immediately and permanent= ly
>>delete the original and any copy of this E-mail and any printout. >>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >


________________________________

This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a114278deef61b305239bb499-- From nobody Mon Nov 2 21:11: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 3B5D41B2E15 for ; Mon, 2 Nov 2015 21:11:47 -0800 (PST) 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 JP-2Yk2Q1g5H for ; Mon, 2 Nov 2015 21:11:44 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BC91B2BA8 for ; Mon, 2 Nov 2015 21:10:37 -0800 (PST) Received: by wmeg8 with SMTP id g8so5515514wme.1 for ; Mon, 02 Nov 2015 21:10:35 -0800 (PST) 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=c3H77rkb5J3MpGUqqVEexXe5G9QcGlJxGLBLbKv+k14=; b=M+5pSutTR1drvt3HBHZId3kSUNT+5MM4eyD5OMc5XS8Ft3oKarJjpByVNEok/SKLBw Vy6/PPeKPajXwzOP2wch3S7xcW73kpaqcpGN41XpQVsIoQt/psWxHc+N1wi+A2bnYas3 GO6jwZUpJGkEuO6RYipp+iuCxk3StAiG1MdJEJYDiXdO2q6f6F5yGFEhK+ywwWMPeLbT 8KtBWxTLAreZFAomv89InN0YjLOndlP8OklZ6TcNohbs9rDAsl67qwm1eOvj8wvDtJQ9 OX3GzePK/wh13cTa/8iRPu7mYrxkES+j/O67WvqHBY4P8MVriyTkTQ9IsfBAudDJLOFl aL0g== MIME-Version: 1.0 X-Received: by 10.28.8.129 with SMTP id 123mr16076865wmi.25.1446527435879; Mon, 02 Nov 2015 21:10:35 -0800 (PST) Received: by 10.194.174.130 with HTTP; Mon, 2 Nov 2015 21:10:35 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> Date: Mon, 2 Nov 2015 21:10:35 -0800 Message-ID: From: Ca By To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11441216f93a6005239be9fd Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 05:11:47 -0000 --001a11441216f93a6005239be9fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, November 2, 2015, Lorenzo Colitti wrote: > My recollection is that we never got around to publishing this document > because we never managed to agree on what to say in the recommendations. = I > think that because the working group does not actually have consensus on > what ULAs should be used for. > > Generalizing and handwaving a bit, I think that the major disagreement is > between: > > 1. Some proponents of ULAs are suggesting that ULAs (are being | can > be | should be) used in similar ways to RFC 1918, including using them > behind NPT66 or in the absence of global addresses, and say that the > document should list those as use cases. > 2. A fair number of WG members are vehemently opposed to such uses, > and say that WG documents should explicitly call out such practices as > harmful. We heard a few of those members at the mike yesterday during = the > discussion of the design choices draft. > > For as long as that disagreement exists, it will be hard to make a > recommendation, which is likely to make it hard to get consensus on this > draft. We can go through that disagreement again, but I don't personally > think the outcome will be any different from the one we had last time > around. > > I happen to be in camp #2 and would be happy to support this draft if it > said that ULA-only deployments, NPT66 and NAT66 are harmful and should be > avoided. But I'm sure a fair number of people disagree with me. > ULA discussion is the same as the extension header discussion which is the same as the multi-homing story and dhcpv6. > On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee > wrote: > >> I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, >> and >> Brian Carpenter. Can I ask each of you to do a review of the current >> document, and send comments to the mailing list? That will give the >> authors >> and the WG something to work from. >> >> Following that, we can discuss whether we need additional discussion at = a >> meeting, or WGLC. >> >> Thanks, >> >> Lee >> >> >> On 11/3/15, 9:20 AM, "Victor Kuarsingh" > > wrote: >> >> >WG, >> > >> >My input is that we should continue this work. Given ULAs are already >> >in use, having a document which outlines those use cases is, in my mind= , >> >operationally beneficial. >> > >> >Perhaps we should be more clear that we would not be recommending the >> >use of ULAs, but keep to a unbiased document which outlines how they >> >have been used (just a use case discussion). We can also include >> >objective technical points as to the pros/cons related to each use case= . >> > >> >It was also noted in another email (based on WG v6ops discussion >> >yesterday), that one such valid example was Cable Modem management IPs >> >assigned ULA based addressing. This is a valid technical use case. >> > >> >I am willing to help if required on this document. >> > >> >regards, >> > >> >Victor K >> > >> >On 2015-11-02 6:17 PM, Howard, Lee wrote: >> >> This document hasn=C2=B9t had any revisions or discussion in a while. >> >> Is there anyone interested in working on it? >> >> >> >> If we do not hear any interest, we will abandon this draft. >> >> >> >> Thanks, >> >> Lee >> >> >> >> >> >> ________________________________ >> >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> >>proprietary information, which is privileged, confidential, or subject >> >>to copyright belonging to Time Warner Cable. This E-mail is intended >> >>solely for the use of the individual or entity to which it is addresse= d. >> >>If you are not the intended recipient of this E-mail, you are hereby >> >>notified that any dissemination, distribution, copying, or action take= n >> >>in relation to the contents of and attachments to this E-mail is >> >>strictly prohibited and may be unlawful. If you have received this >> >>E-mail in error, please notify the sender immediately and permanently >> >>delete the original and any copy of this E-mail and any printout. >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> >> ________________________________ >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject t= o >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified t= hat >> any dissemination, distribution, copying, or action taken in relation to >> the contents of and attachments to this E-mail is strictly prohibited an= d >> may be unlawful. If you have received this E-mail in error, please notif= y >> the sender immediately and permanently delete the original and any copy = of >> this E-mail and any printout. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --001a11441216f93a6005239be9fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, November 2, 2015, Lorenzo Colitti <lorenzo@google.com> wrote:
My recollection is that we never got around = to publishing this document because we never managed to agree on what to sa= y in the recommendations. I think=C2=A0that because the working group does = not actually have consensus on what ULAs should be used for.=C2=A0

=
Generalizing and handwaving a bit, I think that the major disagr= eement is between:
  1. Some proponents of ULAs are suggesting= that ULAs (are being | can be | should be) used in similar ways to RFC 191= 8, including using them behind NPT66 or in the absence of global addresses,= and say that the document should list those as use cases.
  2. A fa= ir number of WG members are vehemently opposed to such uses, and say that W= G documents should explicitly call out such practices as harmful.=C2=A0We h= eard a few of those members at the mike yesterday during the discussion of = the design choices draft.
For as long as that disagreemen= t exists, it will be hard to make a recommendation, which is likely to make= it hard to get consensus on this draft. We can go through that disagreemen= t again, but I don't personally think the outcome will be any different= from the one we had last time around.

I hap= pen to be in camp #2 and would be happy to support this draft if it said th= at ULA-only deployments, NPT66 and NAT66 are harmful and should be avoided.= But I'm sure a fair number of people disagree with me.

ULA discussion is the same as the extension he= ader discussion which is the same as the multi-homing story and dhcpv6.


On Tue, Nov 3, 2015 a= t 9:49 AM, Howard, Lee <lee.= howard@twcable.com> wrote:
= I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and=
Brian Carpenter. Can I ask each of you to do a review of the current
document, and send comments to the mailing list?=C2=A0 That will give the authors
and the WG something to work from.

Following that, we can discuss whether we need additional discussion at a meeting, or WGLC.

Thanks,

Lee


On 11/3/15, 9:20 AM, "Victor Kuarsingh" <= victor@jvknet.com> wrote:

>WG,
>
>My input is that we should continue this work.=C2=A0 Given ULAs are alr= eady
>in use, having a document which outlines those use cases is, in my mind= ,
>operationally beneficial.
>
>Perhaps we should be more clear that we would not be recommending the >use of ULAs, but keep to a unbiased document which outlines how they >have been used (just a use case discussion).=C2=A0 We can also include<= br> >objective technical points as to the pros/cons related to each use case= .
>
>It was also noted in another email (based on WG v6ops discussion
>yesterday), that one such valid example was Cable Modem management IPs<= br> >assigned ULA based addressing.=C2=A0 This is a valid technical use case= .
>
>I am willing to help if required on this document.
>
>regards,
>
>Victor K
>
>On 2015-11-02 6:17 PM, Howard, Lee wrote:
>> This document hasn=C2=B9t had any revisions or discussion in a whi= le.
>> Is there anyone interested in working on it?
>>
>> If we do not hear any interest, we will abandon this draft.
>>
>> Thanks,
>> Lee
>>
>>
>> ________________________________
>>
>> This E-mail and any of its attachments may contain Time Warner Cab= le
>>proprietary information, which is privileged, confidential, or subj= ect
>>to copyright belonging to Time Warner Cable. This E-mail is intende= d
>>solely for the use of the individual or entity to which it is addre= ssed.
>>If you are not the intended recipient of this E-mail, you are hereb= y
>>notified that any dissemination, distribution, copying, or action t= aken
>>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this<= br> >>E-mail in error, please notify the sender immediately and permanent= ly
>>delete the original and any copy of this E-mail and any printout. >>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >


________________________________

This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a11441216f93a6005239be9fd-- From nobody Mon Nov 2 21:13: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 1E6D71B2BA7 for ; Mon, 2 Nov 2015 21:13:49 -0800 (PST) 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 Qom1CcN_8RrI for ; Mon, 2 Nov 2015 21:13:48 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699951B2E9D for ; Mon, 2 Nov 2015 21:13:10 -0800 (PST) Received: by wmeg8 with SMTP id g8so75400042wme.0 for ; Mon, 02 Nov 2015 21:13:09 -0800 (PST) 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=z2R4HjJk9LIeS+wf7lhxX89eAZNKp84HEzbFGWMqLwU=; b=gkIhP6ba457UEoeSgN4/IQTZ+Q6vmzzC8sCrMwIVmd/04L/tvW1sV6LcjoHziP/7lF mm3ypisVJRCQa45X93OSpBYrkwryL7RUYjMUBuyjjknEa6xG+XWDe4dceYC8V1pxli69 LSdsrU9KDJHpg7EwvrnOz/TQtQfjz6vBE/AZv+rtJVL4AwCj71nYKo+0dqiDMYOWrGLL gr5lAwzpA80QK4RE3qeoxw0bb2U35yho1kRF+MLA90WpP2pA9R2TOMJ6WHb5fUF7ioPO 8zeXGhpi+kXa8QO0zVxLU5u52afk5mZwLERu352R2wDMnx3Ojj90CRFoSt6U7s6/s89j 6b7g== 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=z2R4HjJk9LIeS+wf7lhxX89eAZNKp84HEzbFGWMqLwU=; b=bbOhs431ycW7MLYJZAhT7ArSSeBG5bOEC3JZnKcjGT+8GSrQ6zA+DWw5GYpdPWMBND iCC6+QqRF02zvc1ZarEcUZfdkV4XjhtdZ0MnGtwPximD9NObaEjOMNevQPJcX/0rHfMS ZudI4DwK8VFkoY8Ippd/zjjgNCHH3qUahlKTMvOmGc/hh+WaoxHiLytGF7gGUAqfjQkn lbCMIuf49W//9dRMmWAOd+x0LilG52+0YYAh9xAYMhQ+TJ9Gp4+MQy2HyLm7kaNvmI9s DKQNTTwRf8bgD9N84XqAuhXS2lerheQxaX1jvXuqdv0fGDLCLz/J9ZZObtfwT6+IXPLy wdeg== X-Gm-Message-State: ALoCoQmMCk/islgB8wSnKvruHRQzrQsftDboPiTcuCsNhp0daDtzRkORl0VNbymEcFWrZxynv9i/ X-Received: by 10.28.143.1 with SMTP id r1mr18126923wmd.80.1446527588972; Mon, 02 Nov 2015 21:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.2 with HTTP; Mon, 2 Nov 2015 21:12:49 -0800 (PST) In-Reply-To: <5637E08A.9080207@gmail.com> References: <824F2230-A92F-4587-81DD-9EE3418558B9@gmail.com> <5637E08A.9080207@gmail.com> From: Erik Kline Date: Tue, 3 Nov 2015 14:12:49 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1146821819876905239bf339 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability-01 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, 03 Nov 2015 05:13:49 -0000 --001a1146821819876905239bf339 Content-Type: text/plain; charset=UTF-8 On 3 November 2015 at 07:15, Brian E Carpenter wrote: > On 02/11/2015 17:11, David Schinazi wrote: > > Ran, > > > > Thanks for the support! > > > > The edits mentioned by Lorenzo during v6ops today were added to the > draft this morning when we submitted -02. > > > > https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 < > https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02> > > Ship it like that, please. > > Brian > > Agreed. --001a1146821819876905239bf339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 November 2015 at 07:15, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 02/11/2015 17:11, David Schinazi wrote:
> Ran,
>
> Thanks for the support!
>
> The edits mentioned by Lorenzo during v6ops today were added to the dr= aft this morning when we submitted -02.
>
> https://tools.ietf= .org/html/draft-ietf-v6ops-host-addr-availability-02 <https://tools.ietf.org/html/draft-ietf-v6ops= -host-addr-availability-02>

Ship it like that, please.

=C2=A0 =C2=A0Brian


Agreed.
--001a1146821819876905239bf339-- From nobody Mon Nov 2 21:33: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 830131AD055 for ; Mon, 2 Nov 2015 21:33:34 -0800 (PST) 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 lXTQt29J3QYz for ; Mon, 2 Nov 2015 21:33:31 -0800 (PST) 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 A21431ACF54 for ; Mon, 2 Nov 2015 21:33:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV78372; Tue, 03 Nov 2015 05:33:27 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 Nov 2015 05:33:26 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 13:33:20 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , "Howard, Lee" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFc2B3a5k3jNVg0ytx1KEdeZRp56I8SYAgABE2ACAAI56kA== Date: Tue, 3 Nov 2015 05:33:19 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> References: <5637FDD0.70300@jvknet.com> 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.194.186.201] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2319739nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56384727.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 05:33:34 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2319739nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56byBhbmQgYWxsLA0KDQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQoNCj4gRm9y IGFzIGxvbmcgYXMgdGhhdCBkaXNhZ3JlZW1lbnQgZXhpc3RzLCBpdCB3aWxsIGJlIGhhcmQgdG8g bWFrZSBhIHJlY29tbWVuZGF0aW9uLA0KPiB3aGljaCBpcyBsaWtlbHkgdG8gbWFrZSBpdCBoYXJk IHRvIGdldCBjb25zZW5zdXMgb24gdGhpcyBkcmFmdC4NCj4gV2UgY2FuIGdvIHRocm91Z2ggdGhh dCBkaXNhZ3JlZW1lbnQgYWdhaW4sIGJ1dCBJIGRvbid0IHBlcnNvbmFsbHkgdGhpbmsNCj4gdGhl IG91dGNvbWUgd2lsbCBiZSBhbnkgZGlmZmVyZW50IGZyb20gdGhlIG9uZSB3ZSBoYWQgbGFzdCB0 aW1lIGFyb3VuZC4NCltCaW5nXSBJIGJhc2ljYWxseSBhZ3JlZSB3aXRoIHRoaXMgY2xhaW0uIEJ1 dCB0aGF0IGlzIGFjdHVhbGx5IHdoeSB3ZSBjaGFuZ2VkIHRoZSBkb2N1bWVudOKAmXMgcHVycG9z ZSBmcm9tIHJlY29tbWVuZGF0aW9ucyB0byBjb25zaWRlcmF0aW9ucywgdGhhdCBpdCBvbmx5IGRp c2N1c3NlcyBwcm9zIGFuZCBjb25zIG9mIHRob3NlIHBvc3NpYmxlIHNjZW5hcmlvcywgYW5kIE5P VCBtYWtlIGFueSBmb3JtYWwgcmVjb21tZW5kYXRpb24uDQpCdXQgbWF5YmUgYmVjYXVzZSB0aGUg ZHJhZnTigJlzIHNob3J0IG5hbWUgd2FzIG5vdCBjaGFuZ2VkIGFjY29yZGluZ2x5LCBpdCBoYXMg YmVlbiBzdGlsbCDigJxkcmFmdC1pZXRmLXY2b3BzLXVsYS1yZWNvbW1lbmRhdGlvbnPigJ0sIHdo aWNoIG1hZGUgcGVvcGxlIG1pc3VuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0Lg0K DQpJ4oCZdmUgcmVxdWVzdGVkIHRvIHRoZSBjaGFpcnMgdG8gY2hhbmdlIHRoZSBkcmFmdOKAmXMg c2hvcnQgbmFtZSB0byDigJxkcmFmdC1pZXRmLXY2b3BzLXVsYS1jb25zaWRlcmF0aW9uc+KAnSwg SSBob3BlIGl0IGlzIGRvYWJsZS4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQpGcm9tOiB2Nm9w cyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENv bGl0dGkNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDE6NTUgUE0NClRvOiBIb3dh cmQsIExlZQ0KQ2M6IElQdjYgT3BlcmF0aW9ucw0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQt aWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zIC0gd29yayBvciBhYmFuZG9uPw0K DQpNeSByZWNvbGxlY3Rpb24gaXMgdGhhdCB3ZSBuZXZlciBnb3QgYXJvdW5kIHRvIHB1Ymxpc2hp bmcgdGhpcyBkb2N1bWVudCBiZWNhdXNlIHdlIG5ldmVyIG1hbmFnZWQgdG8gYWdyZWUgb24gd2hh dCB0byBzYXkgaW4gdGhlIHJlY29tbWVuZGF0aW9ucy4gSSB0aGluayB0aGF0IGJlY2F1c2UgdGhl IHdvcmtpbmcgZ3JvdXAgZG9lcyBub3QgYWN0dWFsbHkgaGF2ZSBjb25zZW5zdXMgb24gd2hhdCBV TEFzIHNob3VsZCBiZSB1c2VkIGZvci4NCg0KR2VuZXJhbGl6aW5nIGFuZCBoYW5kd2F2aW5nIGEg Yml0LCBJIHRoaW5rIHRoYXQgdGhlIG1ham9yIGRpc2FncmVlbWVudCBpcyBiZXR3ZWVuOg0KDQog IDEuICBTb21lIHByb3BvbmVudHMgb2YgVUxBcyBhcmUgc3VnZ2VzdGluZyB0aGF0IFVMQXMgKGFy ZSBiZWluZyB8IGNhbiBiZSB8IHNob3VsZCBiZSkgdXNlZCBpbiBzaW1pbGFyIHdheXMgdG8gUkZD IDE5MTgsIGluY2x1ZGluZyB1c2luZyB0aGVtIGJlaGluZCBOUFQ2NiBvciBpbiB0aGUgYWJzZW5j ZSBvZiBnbG9iYWwgYWRkcmVzc2VzLCBhbmQgc2F5IHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBs aXN0IHRob3NlIGFzIHVzZSBjYXNlcy4NCiAgMi4gIEEgZmFpciBudW1iZXIgb2YgV0cgbWVtYmVy cyBhcmUgdmVoZW1lbnRseSBvcHBvc2VkIHRvIHN1Y2ggdXNlcywgYW5kIHNheSB0aGF0IFdHIGRv Y3VtZW50cyBzaG91bGQgZXhwbGljaXRseSBjYWxsIG91dCBzdWNoIHByYWN0aWNlcyBhcyBoYXJt ZnVsLiBXZSBoZWFyZCBhIGZldyBvZiB0aG9zZSBtZW1iZXJzIGF0IHRoZSBtaWtlIHllc3RlcmRh eSBkdXJpbmcgdGhlIGRpc2N1c3Npb24gb2YgdGhlIGRlc2lnbiBjaG9pY2VzIGRyYWZ0Lg0KRm9y IGFzIGxvbmcgYXMgdGhhdCBkaXNhZ3JlZW1lbnQgZXhpc3RzLCBpdCB3aWxsIGJlIGhhcmQgdG8g bWFrZSBhIHJlY29tbWVuZGF0aW9uLCB3aGljaCBpcyBsaWtlbHkgdG8gbWFrZSBpdCBoYXJkIHRv IGdldCBjb25zZW5zdXMgb24gdGhpcyBkcmFmdC4gV2UgY2FuIGdvIHRocm91Z2ggdGhhdCBkaXNh Z3JlZW1lbnQgYWdhaW4sIGJ1dCBJIGRvbid0IHBlcnNvbmFsbHkgdGhpbmsgdGhlIG91dGNvbWUg d2lsbCBiZSBhbnkgZGlmZmVyZW50IGZyb20gdGhlIG9uZSB3ZSBoYWQgbGFzdCB0aW1lIGFyb3Vu ZC4NCg0KSSBoYXBwZW4gdG8gYmUgaW4gY2FtcCAjMiBhbmQgd291bGQgYmUgaGFwcHkgdG8gc3Vw cG9ydCB0aGlzIGRyYWZ0IGlmIGl0IHNhaWQgdGhhdCBVTEEtb25seSBkZXBsb3ltZW50cywgTlBU NjYgYW5kIE5BVDY2IGFyZSBoYXJtZnVsIGFuZCBzaG91bGQgYmUgYXZvaWRlZC4gQnV0IEknbSBz dXJlIGEgZmFpciBudW1iZXIgb2YgcGVvcGxlIGRpc2FncmVlIHdpdGggbWUuDQoNCk9uIFR1ZSwg Tm92IDMsIDIwMTUgYXQgOTo0OSBBTSwgSG93YXJkLCBMZWUgPGxlZS5ob3dhcmRAdHdjYWJsZS5j b208bWFpbHRvOmxlZS5ob3dhcmRAdHdjYWJsZS5jb20+PiB3cm90ZToNCkkgc2VlIGludGVyZXN0 IGZyb20gVmljdG9yIEt1YXJzaW5naCwgRGF2aWQgRmFybWVyLCBBbGV4YW5kcmUgUGV0cmVzY3Us IGFuZA0KQnJpYW4gQ2FycGVudGVyLiBDYW4gSSBhc2sgZWFjaCBvZiB5b3UgdG8gZG8gYSByZXZp ZXcgb2YgdGhlIGN1cnJlbnQNCmRvY3VtZW50LCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbWFp bGluZyBsaXN0PyAgVGhhdCB3aWxsIGdpdmUgdGhlDQphdXRob3JzDQphbmQgdGhlIFdHIHNvbWV0 aGluZyB0byB3b3JrIGZyb20uDQoNCkZvbGxvd2luZyB0aGF0LCB3ZSBjYW4gZGlzY3VzcyB3aGV0 aGVyIHdlIG5lZWQgYWRkaXRpb25hbCBkaXNjdXNzaW9uIGF0IGENCm1lZXRpbmcsIG9yIFdHTEMu DQoNClRoYW5rcywNCg0KTGVlDQoNCg0KT24gMTEvMy8xNSwgOToyMCBBTSwgIlZpY3RvciBLdWFy c2luZ2giIDx2aWN0b3JAanZrbmV0LmNvbTxtYWlsdG86dmljdG9yQGp2a25ldC5jb20+PiB3cm90 ZToNCg0KPldHLA0KPg0KPk15IGlucHV0IGlzIHRoYXQgd2Ugc2hvdWxkIGNvbnRpbnVlIHRoaXMg d29yay4gIEdpdmVuIFVMQXMgYXJlIGFscmVhZHkNCj5pbiB1c2UsIGhhdmluZyBhIGRvY3VtZW50 IHdoaWNoIG91dGxpbmVzIHRob3NlIHVzZSBjYXNlcyBpcywgaW4gbXkgbWluZCwNCj5vcGVyYXRp b25hbGx5IGJlbmVmaWNpYWwuDQo+DQo+UGVyaGFwcyB3ZSBzaG91bGQgYmUgbW9yZSBjbGVhciB0 aGF0IHdlIHdvdWxkIG5vdCBiZSByZWNvbW1lbmRpbmcgdGhlDQo+dXNlIG9mIFVMQXMsIGJ1dCBr ZWVwIHRvIGEgdW5iaWFzZWQgZG9jdW1lbnQgd2hpY2ggb3V0bGluZXMgaG93IHRoZXkNCj5oYXZl IGJlZW4gdXNlZCAoanVzdCBhIHVzZSBjYXNlIGRpc2N1c3Npb24pLiAgV2UgY2FuIGFsc28gaW5j bHVkZQ0KPm9iamVjdGl2ZSB0ZWNobmljYWwgcG9pbnRzIGFzIHRvIHRoZSBwcm9zL2NvbnMgcmVs YXRlZCB0byBlYWNoIHVzZSBjYXNlLg0KPg0KPkl0IHdhcyBhbHNvIG5vdGVkIGluIGFub3RoZXIg ZW1haWwgKGJhc2VkIG9uIFdHIHY2b3BzIGRpc2N1c3Npb24NCj55ZXN0ZXJkYXkpLCB0aGF0IG9u ZSBzdWNoIHZhbGlkIGV4YW1wbGUgd2FzIENhYmxlIE1vZGVtIG1hbmFnZW1lbnQgSVBzDQo+YXNz aWduZWQgVUxBIGJhc2VkIGFkZHJlc3NpbmcuICBUaGlzIGlzIGEgdmFsaWQgdGVjaG5pY2FsIHVz ZSBjYXNlLg0KPg0KPkkgYW0gd2lsbGluZyB0byBoZWxwIGlmIHJlcXVpcmVkIG9uIHRoaXMgZG9j dW1lbnQuDQo+DQo+cmVnYXJkcywNCj4NCj5WaWN0b3IgSw0KPg0KPk9uIDIwMTUtMTEtMDIgNjox NyBQTSwgSG93YXJkLCBMZWUgd3JvdGU6DQo+PiBUaGlzIGRvY3VtZW50IGhhc27CuXQgaGFkIGFu eSByZXZpc2lvbnMgb3IgZGlzY3Vzc2lvbiBpbiBhIHdoaWxlLg0KPj4gSXMgdGhlcmUgYW55b25l IGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiBpdD8NCj4+DQo+PiBJZiB3ZSBkbyBub3QgaGVhciBh bnkgaW50ZXJlc3QsIHdlIHdpbGwgYWJhbmRvbiB0aGlzIGRyYWZ0Lg0KPj4NCj4+IFRoYW5rcywN Cj4+IExlZQ0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4N Cj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRp bWUgV2FybmVyIENhYmxlDQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2 aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+dG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+c29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuDQo+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5DQo+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+PmluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+ c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzDQo+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseQ0KPj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3Jn PG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2319739nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9 kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MzIzMDQ2OTY4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo1MDk2NTU1MTIgMTgwMTc0Njk2MCA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMDY0ODM0NDg4 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTI1NzUwMzM1Mjt9DQpAbGlzdCBsMg0KCXttc28t bGlzdC1pZDoxMzEwMjgzMjk2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNjA0NjI0MjkyIC0yMDIyMjg1NDA4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4w cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIExvcmVuem8gYW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciBhcyBsb25nIGFz IHRoYXQgZGlzYWdyZWVtZW50IGV4aXN0cywgaXQgd2lsbCBiZSBoYXJkIHRvIG1ha2UgYSByZWNv bW1lbmRhdGlvbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHdoaWNoIGlzIGxpa2VseSB0byBtYWtlIGl0IGhhcmQg dG8gZ2V0IGNvbnNlbnN1cyBvbiB0aGlzIGRyYWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgV2UgY2FuIGdvIHRo cm91Z2ggdGhhdCBkaXNhZ3JlZW1lbnQgYWdhaW4sIGJ1dCBJIGRvbid0IHBlcnNvbmFsbHkgdGhp bmsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IHRoZSBvdXRjb21lIHdpbGwgYmUgYW55IGRpZmZlcmVudCBmcm9tIHRo ZSBvbmUgd2UgaGFkIGxhc3QgdGltZSBhcm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gSSBiYXNpY2FsbHkgYWdyZWUgd2l0aCB0aGlzIGNsYWlt LiBCdXQgdGhhdCBpcyBhY3R1YWxseSB3aHkgd2UgY2hhbmdlZCB0aGUgZG9jdW1lbnTigJlzIHB1 cnBvc2UgZnJvbSByZWNvbW1lbmRhdGlvbnMgdG8gY29uc2lkZXJhdGlvbnMsIHRoYXQNCiBpdCBv bmx5IGRpc2N1c3NlcyBwcm9zIGFuZCBjb25zIG9mIHRob3NlIHBvc3NpYmxlIHNjZW5hcmlvcywg YW5kIE5PVCBtYWtlIGFueSBmb3JtYWwgcmVjb21tZW5kYXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgbWF5YmUgYmVjYXVzZSB0aGUgZHJhZnTigJlz IHNob3J0IG5hbWUgd2FzIG5vdCBjaGFuZ2VkIGFjY29yZGluZ2x5LCBpdCBoYXMgYmVlbiBzdGls bCDigJxkcmFmdC1pZXRmLXY2b3BzLXVsYS1yZWNvbW1lbmRhdGlvbnPigJ0sIHdoaWNoIG1hZGUg cGVvcGxlDQogbWlzdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSByZXF1ZXN0ZWQgdG8gdGhlIGNoYWly cyB0byBjaGFuZ2UgdGhlIGRyYWZ04oCZcyBzaG9ydCBuYW1lIHRvIOKAnGRyYWZ0LWlldGYtdjZv cHMtdWxhLWNvbnNpZGVyYXRpb25z4oCdLCBJIGhvcGUgaXQgaXMgZG9hYmxlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvcmVuem8gQ29saXR0aTxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAwMywgMjAxNSAxOjU1IFBNPGJyPg0KPGI+VG86PC9iPiBI b3dhcmQsIExlZTxicj4NCjxiPkNjOjwvYj4gSVB2NiBPcGVyYXRpb25zPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0 aW9ucyAtIHdvcmsgb3IgYWJhbmRvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk15IHJlY29sbGVjdGlvbiBpcyB0aGF0IHdlIG5ldmVyIGdvdCBhcm91bmQgdG8gcHVibGlzaGlu ZyB0aGlzIGRvY3VtZW50IGJlY2F1c2Ugd2UgbmV2ZXIgbWFuYWdlZCB0byBhZ3JlZSBvbiB3aGF0 IHRvIHNheSBpbiB0aGUgcmVjb21tZW5kYXRpb25zLiBJIHRoaW5rJm5ic3A7dGhhdCBiZWNhdXNl IHRoZSB3b3JraW5nIGdyb3VwIGRvZXMgbm90IGFjdHVhbGx5IGhhdmUgY29uc2Vuc3VzDQogb24g d2hhdCBVTEFzIHNob3VsZCBiZSB1c2VkIGZvci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5HZW5lcmFsaXppbmcgYW5kIGhhbmR3YXZpbmcgYSBiaXQsIEkg dGhpbmsgdGhhdCB0aGUgbWFqb3IgZGlzYWdyZWVtZW50IGlzIGJldHdlZW46PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPlNvbWUgcHJvcG9uZW50cyBvZiBVTEFzIGFyZSBzdWdnZXN0aW5nIHRoYXQgVUxBcyAo YXJlIGJlaW5nIHwgY2FuIGJlIHwgc2hvdWxkIGJlKSB1c2VkIGluIHNpbWlsYXIgd2F5cyB0byBS RkMgMTkxOCwgaW5jbHVkaW5nIHVzaW5nIHRoZW0gYmVoaW5kIE5QVDY2IG9yIGluIHRoZSBhYnNl bmNlIG9mIGdsb2JhbCBhZGRyZXNzZXMsIGFuZCBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxk IGxpc3QgdGhvc2UgYXMgdXNlDQogY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj5BIGZhaXIgbnVtYmVyIG9mIFdHIG1lbWJlcnMgYXJlIHZlaGVtZW50bHkgb3Bwb3NlZCB0 byBzdWNoIHVzZXMsIGFuZCBzYXkgdGhhdCBXRyBkb2N1bWVudHMgc2hvdWxkIGV4cGxpY2l0bHkg Y2FsbCBvdXQgc3VjaCBwcmFjdGljZXMgYXMgaGFybWZ1bC4mbmJzcDtXZSBoZWFyZCBhIGZldyBv ZiB0aG9zZSBtZW1iZXJzIGF0IHRoZSBtaWtlIHllc3RlcmRheSBkdXJpbmcgdGhlIGRpc2N1c3Np b24gb2YgdGhlIGRlc2lnbiBjaG9pY2VzDQogZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9saT48 L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb3Ig YXMgbG9uZyBhcyB0aGF0IGRpc2FncmVlbWVudCBleGlzdHMsIGl0IHdpbGwgYmUgaGFyZCB0byBt YWtlIGEgcmVjb21tZW5kYXRpb24sIHdoaWNoIGlzIGxpa2VseSB0byBtYWtlIGl0IGhhcmQgdG8g Z2V0IGNvbnNlbnN1cyBvbiB0aGlzIGRyYWZ0LiBXZSBjYW4gZ28gdGhyb3VnaCB0aGF0IGRpc2Fn cmVlbWVudCBhZ2FpbiwgYnV0IEkgZG9uJ3QgcGVyc29uYWxseSB0aGluaw0KIHRoZSBvdXRjb21l IHdpbGwgYmUgYW55IGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgd2UgaGFkIGxhc3QgdGltZSBhcm91 bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgaGFwcGVuIHRvIGJlIGluIGNhbXAgIzIgYW5kIHdvdWxkIGJlIGhhcHB5IHRvIHN1cHBv cnQgdGhpcyBkcmFmdCBpZiBpdCBzYWlkIHRoYXQgVUxBLW9ubHkgZGVwbG95bWVudHMsIE5QVDY2 IGFuZCBOQVQ2NiBhcmUgaGFybWZ1bCBhbmQgc2hvdWxkIGJlIGF2b2lkZWQuIEJ1dCBJJ20gc3Vy ZSBhIGZhaXIgbnVtYmVyIG9mIHBlb3BsZSBkaXNhZ3JlZSB3aXRoIG1lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBOb3YgMywgMjAxNSBh dCA5OjQ5IEFNLCBIb3dhcmQsIExlZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlZS5ob3dhcmRAdHdj YWJsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5sZWUuaG93YXJkQHR3Y2FibGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgc2VlIGludGVyZXN0IGZyb20gVmljdG9yIEt1YXJzaW5naCwgRGF2aWQg RmFybWVyLCBBbGV4YW5kcmUgUGV0cmVzY3UsIGFuZDxicj4NCkJyaWFuIENhcnBlbnRlci4gQ2Fu IEkgYXNrIGVhY2ggb2YgeW91IHRvIGRvIGEgcmV2aWV3IG9mIHRoZSBjdXJyZW50PGJyPg0KZG9j dW1lbnQsIGFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3Q/Jm5ic3A7IFRoYXQg d2lsbCBnaXZlIHRoZTxicj4NCmF1dGhvcnM8YnI+DQphbmQgdGhlIFdHIHNvbWV0aGluZyB0byB3 b3JrIGZyb20uPGJyPg0KPGJyPg0KRm9sbG93aW5nIHRoYXQsIHdlIGNhbiBkaXNjdXNzIHdoZXRo ZXIgd2UgbmVlZCBhZGRpdGlvbmFsIGRpc2N1c3Npb24gYXQgYTxicj4NCm1lZXRpbmcsIG9yIFdH TEMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkxlZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxicj4NCk9uIDExLzMvMTUsIDk6MjAgQU0sICZxdW90O1ZpY3RvciBLdWFyc2luZ2gm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2aWN0b3JAanZrbmV0LmNvbSI+dmljdG9yQGp2a25l dC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7V0csPGJyPg0KJmd0Ozxicj4NCiZn dDtNeSBpbnB1dCBpcyB0aGF0IHdlIHNob3VsZCBjb250aW51ZSB0aGlzIHdvcmsuJm5ic3A7IEdp dmVuIFVMQXMgYXJlIGFscmVhZHk8YnI+DQomZ3Q7aW4gdXNlLCBoYXZpbmcgYSBkb2N1bWVudCB3 aGljaCBvdXRsaW5lcyB0aG9zZSB1c2UgY2FzZXMgaXMsIGluIG15IG1pbmQsPGJyPg0KJmd0O29w ZXJhdGlvbmFsbHkgYmVuZWZpY2lhbC48YnI+DQomZ3Q7PGJyPg0KJmd0O1BlcmhhcHMgd2Ugc2hv dWxkIGJlIG1vcmUgY2xlYXIgdGhhdCB3ZSB3b3VsZCBub3QgYmUgcmVjb21tZW5kaW5nIHRoZTxi cj4NCiZndDt1c2Ugb2YgVUxBcywgYnV0IGtlZXAgdG8gYSB1bmJpYXNlZCBkb2N1bWVudCB3aGlj aCBvdXRsaW5lcyBob3cgdGhleTxicj4NCiZndDtoYXZlIGJlZW4gdXNlZCAoanVzdCBhIHVzZSBj YXNlIGRpc2N1c3Npb24pLiZuYnNwOyBXZSBjYW4gYWxzbyBpbmNsdWRlPGJyPg0KJmd0O29iamVj dGl2ZSB0ZWNobmljYWwgcG9pbnRzIGFzIHRvIHRoZSBwcm9zL2NvbnMgcmVsYXRlZCB0byBlYWNo IHVzZSBjYXNlLjxicj4NCiZndDs8YnI+DQomZ3Q7SXQgd2FzIGFsc28gbm90ZWQgaW4gYW5vdGhl ciBlbWFpbCAoYmFzZWQgb24gV0cgdjZvcHMgZGlzY3Vzc2lvbjxicj4NCiZndDt5ZXN0ZXJkYXkp LCB0aGF0IG9uZSBzdWNoIHZhbGlkIGV4YW1wbGUgd2FzIENhYmxlIE1vZGVtIG1hbmFnZW1lbnQg SVBzPGJyPg0KJmd0O2Fzc2lnbmVkIFVMQSBiYXNlZCBhZGRyZXNzaW5nLiZuYnNwOyBUaGlzIGlz IGEgdmFsaWQgdGVjaG5pY2FsIHVzZSBjYXNlLjxicj4NCiZndDs8YnI+DQomZ3Q7SSBhbSB3aWxs aW5nIHRvIGhlbHAgaWYgcmVxdWlyZWQgb24gdGhpcyBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0K Jmd0O3JlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZndDtWaWN0b3IgSzxicj4NCiZndDs8YnI+DQom Z3Q7T24gMjAxNS0xMS0wMiA2OjE3IFBNLCBIb3dhcmQsIExlZSB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyBUaGlzIGRvY3VtZW50IGhhc27CuXQgaGFkIGFueSByZXZpc2lvbnMgb3IgZGlzY3Vzc2lvbiBp biBhIHdoaWxlLjxicj4NCiZndDsmZ3Q7IElzIHRoZXJlIGFueW9uZSBpbnRlcmVzdGVkIGluIHdv cmtpbmcgb24gaXQ/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiB3ZSBkbyBub3QgaGVh ciBhbnkgaW50ZXJlc3QsIHdlIHdpbGwgYWJhbmRvbiB0aGlzIGRyYWZ0Ljxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7IExlZTxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGU8YnI+DQomZ3Q7Jmd0O3By b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3Q8YnI+DQomZ3Q7Jmd0O3RvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBX YXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkPGJyPg0KJmd0OyZndDtzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC48YnI+DQomZ3Q7Jmd0O0lmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5PGJyPg0KJmd0OyZndDtub3RpZmllZCB0 aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0 YWtlbjxicj4NCiZndDsmZ3Q7aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRh Y2htZW50cyB0byB0aGlzIEUtbWFpbCBpczxicj4NCiZndDsmZ3Q7c3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzPGJyPg0KJmd0 OyZndDtFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgcGVybWFuZW50bHk8YnI+DQomZ3Q7Jmd0O2RlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFu eSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8 L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KPGJyPg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvDQogd2hpY2gg aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0 byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIG1heQ0KIGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2319739nkgeml506mbxchi_-- From nobody Mon Nov 2 22: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 390501B29AA for ; Mon, 2 Nov 2015 22:00:24 -0800 (PST) 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 WUwSvo45b4xc for ; Mon, 2 Nov 2015 22:00:22 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 53E2A1AD1A3 for ; Mon, 2 Nov 2015 22:00:22 -0800 (PST) Received: by ykft191 with SMTP id t191so6356635ykf.0 for ; Mon, 02 Nov 2015 22:00:21 -0800 (PST) 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=GKSasYup33+JiU+a0yYa9mx1NnqphHfdL+Szv3no5p0=; b=ICpXj2r68WRC8jmBgdJ6CB/8rm5GVjaI1Bzlar9VnODI5EMgBziARwrw87H6Fe2SUr 0mD9WOgPCxZoTVEURGk027MDhQThP3CTq6YZflgYf4DesjG9mvnh3LcbQIzg7z7sKU7z KMVvq42z4khThWWiVO5LAWQov+vxfQ+hKgb/lUfNZauR2ZiYtLmKLYLo3+hwMlcQvAh+ kdv/AUbeKKoytQg+xdXu7EPKbmK5wBThiP0zBeHUD6usJJ+COUfWzMAxyuDkRGGM2JGi fu0F8bm+bhIGym1QM6pQsITVFyXDl//cX7aEicHkqOPcjoWlm5r4MjREOeZQhC+VXTo6 oikw== 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=GKSasYup33+JiU+a0yYa9mx1NnqphHfdL+Szv3no5p0=; b=YmoHwfPMVdRCfQXAIqLfg74do/3Z8ElgZNZ2kBGXf/JDvBWdlJhhQNghSJaqr8keqv asWSWrz9+eihQ3pBRIyg9LddcNia/eiKO2oc15Z/z20ijO7BReHS2O1t9XoH08GJqzJY KN9Or08ILNGIzfatusQdBPZVlbKhskXngpoMWVPvdQfOyKIsj8zoRXeKWVVuWll7YYBi INAQuwuhvUlBG/1o39GhGdHggcx7hWH/vuW50kBS/cy80rJQyPxEDOaJmFwi8Sdd1GiL iSENZNPbI081nUZVLcfFqktVAiINsrmwoYeVDzlV3bA1lTMr715fcU9+400G6/j/xShi Eotg== X-Gm-Message-State: ALoCoQm21jXfJX3qKRt7Ng0HD/w9VoKyhsMmY8NjB4wl0U4BbVUQMQSVPuWgAjtikuHjicVaYB7e X-Received: by 10.129.44.3 with SMTP id s3mr19325120yws.141.1446530421604; Mon, 02 Nov 2015 22:00:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 22:00:02 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 15:00:02 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a114278def0244305239c9b59 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 06:00:24 -0000 --001a114278def0244305239c9b59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) wrote: > [Bing] I basically agree with this claim. But that is actually why we > changed the document=E2=80=99s purpose from recommendations to considerat= ions, that > it only discusses pros and cons of those possible scenarios, and NOT make > any formal recommendation. > >From the discussion of the deployment considerations draft in the v6ops session yesterday, several WG members (I remember at least James Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough to list these deployment models with their pros and cons. Instead, these deployment models should be listed separately as "deployment models that are considered harmful". --001a114278def0244305239c9b59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <leo.liubing@huawei.com= > wrote:

[Bing] I basically agree with this claim. = But that is actually why we changed the document=E2=80=99s purpose from rec= ommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make = any formal recommendation.


From the discussion of the deployment considerations draft in the v6= ops session yesterday, several WG members (I remember at least James Woodya= tt, Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough= to list these deployment models with their pros and cons. Instead, these d= eployment models should be listed separately as "deployment models tha= t are considered harmful".
--001a114278def0244305239c9b59-- From nobody Mon Nov 2 22:17: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 93D9E1B29D0 for ; Mon, 2 Nov 2015 22:17:31 -0800 (PST) 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 D2Vb2PkbY0QL for ; Mon, 2 Nov 2015 22:17:29 -0800 (PST) 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 813B01AD0C2 for ; Mon, 2 Nov 2015 22:17:29 -0800 (PST) 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 A6A4B1FCAB6; Tue, 3 Nov 2015 06:17:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6D56316004F; Tue, 3 Nov 2015 06:18:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5D5A3160069; Tue, 3 Nov 2015 06:18:06 +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 KR_uYdELihtY; Tue, 3 Nov 2015 06:18:06 +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 157B716004F; Tue, 3 Nov 2015 06:18:06 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3C7DA3BBB9D8; Tue, 3 Nov 2015 17:17:23 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5637FDD0.70300@jvknet.com> In-reply-to: Your message of "Tue, 03 Nov 2015 13:55:26 +0900." Date: Tue, 03 Nov 2015 17:17:23 +1100 Message-Id: <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 06:17:31 -0000 In message , Lorenzo Colitti writes: > > My recollection is that we never got around to publishing this document > because we never managed to agree on what to say in the recommendations. I > think that because the working group does not actually have consensus on > what ULAs should be used for. > > Generalizing and handwaving a bit, I think that the major disagreement is > between: > > 1. Some proponents of ULAs are suggesting that ULAs (are being | can be > | should be) used in similar ways to RFC 1918, including using them behind > NPT66 or in the absence of global addresses, and say that the document > should list those as use cases. > 2. A fair number of WG members are vehemently opposed to such uses, and > say that WG documents should explicitly call out such practices as > harmful. We heard a few of those members at the mike yesterday during the > discussion of the design choices draft. A lot of this is to do with how addresses are provisioned. If they are provising manually (PA or PI) then you can get away without ULA as your internal addressing is not going to evaperate on you when you become disconnected. If your addresses are provisioned automatically then ULA is *critical* to providing internal stability when the PA prefix goes away. No, we should not be encouraging ignoring lease times. We should also demonstrate that ULA in conjuction with other GUA is not harmful. One way to do that would be generate a ULA prefix in BA and only provide DNS using addresses from the the ULA prefix. Even better would be to get a second GUA prefix and migrate the network from one to the other over the course of the week. Bring up the second GUA on Tuesday and withdraw the first prefix on Thursday. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 2 22:18: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 1E7FA1B2A43 for ; Mon, 2 Nov 2015 22:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 wuNG-CXbig2Z for ; Mon, 2 Nov 2015 22:18:48 -0800 (PST) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id CBA221B2A23 for ; Mon, 2 Nov 2015 22:18:47 -0800 (PST) X-SENDER-IP: 10.64.163.152 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,237,1444708800"; d="scan'208,217";a="447135610" Received: from unknown (HELO exchpapp11.corp.twcable.com) ([10.64.163.152]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 03 Nov 2015 01:10:22 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp11.corp.twcable.com (10.64.163.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 01:18:46 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 01:18:46 -0500 From: "Howard, Lee" To: Lorenzo Colitti , "Liubing (Leo)" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYD//769AIAACpaAgAAHdwCAAItVAA== Date: Tue, 3 Nov 2015 06:18:45 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21918.005 x-tm-as-result: No--41.482000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D25E7DDFC9709LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 06:18:51 -0000 --_000_D25E7DDFC9709LeeHowardtwcablecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Lorenzo Colitti > Date: Tuesday, November 3, 2015 at 2:00 AM To: "Liubing (Leo)" > Cc: Lee Howard >, 'IP= v6 Operations' > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) > wrote: [Bing] I basically agree with this claim. But that is actually why we chang= ed the document's purpose from recommendations to considerations, that it o= nly discusses pros and cons of those possible scenarios, and NOT make any f= ormal recommendation. >From the discussion of the deployment considerations draft in the v6ops ses= sion yesterday, several WG members (I remember at least James Woodyatt, Dav= e Thaler, Igor Gashinsky, and myself) believed that it is not enough to lis= t these deployment models with their pros and cons. Instead, these deployme= nt models should be listed separately as "deployment models that are consid= ered harmful". Trying to find a way forward with the document. . . You specifically want to recommend against ULA plus NPT66 or NAT66, right? The relevant sections in the current document say (in part): Although NPTv6 works differently from traditional stateful NAT/NAPT (which is discouraged in [RFC5902]), it introduces sim= ilar additional complexity to applications, which may cause applications to break. Thus this document does not recommend the use of ULA+NPTv6. ... Although NPTv6 is a mechanism that has fewer architectural problems than a traditional stateful Network Address Translator in an IPv6 environment [RFC6296], i= t still breaks end-to-end transparency and hence in general is not recommended by the IETF. ... There's also a full section called, " Do Not Treat ULA Equal to RFC1918. " And so on. It seems pretty clear. Is this language insufficiently strong fo= r you? What words would you use instead? Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D25E7DDFC9709LeeHowardtwcablecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Lorenzo Colitti <lorenzo@google.com>
Date: Tuesday, November 3, 2015 at = 2:00 AM
To: "Liubing (Leo)" <<= a href=3D"mailto:leo.liubing@huawei.com">leo.liubing@huawei.com>
Cc: Lee Howard <lee.howard@twcable.com>, 'IPv6 Operations'= <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6o= ps-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <leo.liubing= @huawei.com> wrote:

[Bing] I basically agree with thi= s claim. But that is actually why we changed the document’s purpose f= rom recommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make = any formal recommendation.


From the discussion of the deployment considerations draft in the v6op= s session yesterday, several WG members (I remember at least James Woodyatt= , Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough t= o list these deployment models with their pros and cons. Instead, these deployment models should be listed sep= arately as "deployment models that are considered harmful".

Trying to find a way forward with the document. . .

You specifically want to recommend against ULA plus NPT66 or NAT66, right?<= /div>
The relevant sections in the current document say (in part):

	Although NPTv6 works differently from

         traditional stateful NAT/NAPT (which is dis=
couraged in
         [RFC5902]), it int=
roduces similar additional complexity to
         applications, which may cause applications to break.

         Thus this document does not recommend the use of ULA+NPTv6.
…
	Although NPTv6 is a mechanism that has fewer architectural
      problems than a traditional stateful Network Address Translator in
      an IPv6 environment [RFC6296],=
 it still breaks end-to-end
      transparency and hence in general is not recommended by the IETF.
…

There’s also a full section ca= lled, "

Do Not Treat ULA Equal to RFC1918.

”


And s= o on. It seems pretty clear. Is this language insufficiently strong for you= ? What words would you use instead?

Thank= s,

Lee




This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
 --_000_D25E7DDFC9709LeeHowardtwcablecom_-- From nobody Mon Nov 2 22:43: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 DD9121B2E71 for ; Mon, 2 Nov 2015 22:43:42 -0800 (PST) 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, 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 jRV_16uIkD8z for ; Mon, 2 Nov 2015 22:43:41 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA981B2E70 for ; Mon, 2 Nov 2015 22:43:41 -0800 (PST) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 3 Nov 2015 00:43:38 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f178.google.com [209.85.223.178] #+LO+TS+TR X-Umn-Classification: local Received: by iodd200 with SMTP id d200so9920985iod.0 for ; Mon, 02 Nov 2015 22:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=DLVoiUzj8PLzUmubNyP9VHyqXG+r+Mw0WZXCz9L5w7c=; b=jzmxYw5uTjdNBdj20TFa9V76STmH/FYyBZhby69n3fzUlEvY1cXumFjFuaOLc9eKdS I2jeizmRkY5/8YNEtP8SqNUyaqloJDo4+kJAdBevqycjjdWJrTqFAQaiNkF1ptMyq0K3 1Gj78pSF449uztc2t0/LJJ9qXo7NdUdC8MMaQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=DLVoiUzj8PLzUmubNyP9VHyqXG+r+Mw0WZXCz9L5w7c=; b=IaaEwWAl7jgMb92ICzjfXpf0TcGNElo9DcD0FR3PotKFOl1VgkeCJK5jvjOKK2Ry7A nR0kwT1AYHGLEaey9IB4mEtFICmRyb8CC7WUxsqdDZIaDi1egcdb+uVokcV/71k0K/0S b0OPCiIz5aiVSm1yun7rB5oy+xAJOfHQrAI1mz/tA3qhNf9+wPvdrSmDdXwKuAA7rzSI FR3ke5bpIw708engWKKNB3W1vMNL6/om3GZUWOaQSyEF1538tQr67bBnbYUlx9eWQcVY TMwNODYtDcVUidTqnoaTN/su8WaS4f8aitHzWuuxK7GGjAcqNzIukbndULWpXxcQrej6 nv/A== X-Gm-Message-State: ALoCoQnCBAXyQe2l60ADsXb9YzdrnWkKZ+YSXLi0MGE4H6hlDbdkAjA9/ealRtDjzCJEzVp0QNAICS6LQKxJF31jhB6esaVx6hEQhS9q0Jqtdxyu7gZ8q8cU9XuTqx91NzFCMzQJUo7t X-Received: by 10.107.136.196 with SMTP id s65mr25570227ioi.135.1446533017808; Mon, 02 Nov 2015 22:43:37 -0800 (PST) X-Received: by 10.107.136.196 with SMTP id s65mr25570221ioi.135.1446533017665; Mon, 02 Nov 2015 22:43:37 -0800 (PST) Received: from x-134-84-0-209.vpn.umn.edu (x-134-84-0-209.vpn.umn.edu. [134.84.0.209]) by smtp.gmail.com with ESMTPSA id 31sm9043208iod.4.2015.11.02.22.43.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 22:43:35 -0800 (PST) References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> To: Lorenzo Colitti , "Liubing (Leo)" From: David Farmer Organization: University of Minnesota Message-ID: <56385749.7040208@umn.edu> Date: Tue, 3 Nov 2015 00:42:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 06:43:43 -0000 On 11/3/15 00:00 , Lorenzo Colitti wrote: > On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) > wrote: > > [Bing] I basically agree with this claim. But that is actually why > we changed the document’s purpose from recommendations to > considerations, that it only discusses pros and cons of those > possible scenarios, and NOT make any formal recommendation. > > > From the discussion of the deployment considerations draft in the v6ops > session yesterday, several WG members (I remember at least James > Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is > not enough to list these deployment models with their pros and cons. > Instead, these deployment models should be listed separately as > "deployment models that are considered harmful". To clarify, are you saying Connected Networks with ULA-Only (NPTv6 & ALP) section 4.2.1 deployment models are harmful? I agree with this, with the caveat we have to acknowledge these exist in order to call them harmful. I've heard in the past that some what them removed completely. I prefer to keep them and call them harmful. Or are you saying all ULA deployment models are harmful? If you are saying this I need to better understand what you mean and way you think this. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Nov 2 23:02: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 BAF1C1B2F0A for ; Mon, 2 Nov 2015 23:02:19 -0800 (PST) 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 6BcTi7ks1U-L for ; Mon, 2 Nov 2015 23:02:18 -0800 (PST) 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 B73251B2EF9 for ; Mon, 2 Nov 2015 23:02:08 -0800 (PST) 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 tA3728Qj050288; Tue, 3 Nov 2015 00:02:08 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3726IO050283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 00:02:06 -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; Mon, 2 Nov 2015 23:02:06 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAAnxsA//+/N6A= Date: Tue, 3 Nov 2015 07:02:05 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F399D2@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 07:02:19 -0000 SGkgTG9yZW56bywNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXSANClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNjozNiBQTQ0KVG86IFRl bXBsaW4sIEZyZWQgTA0KQ2M6IEZyZWQgQmFrZXIgKGZyZWQpOyB2Nm9wc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5 IGRpc2N1c3Npb24NCg0KT24gVHVlLCBOb3YgMywgMjAxNSBhdCAxMDoyNCBBTSwgVGVtcGxpbiwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCkkgZG9uJ3QgdGhpbmsg IlJlcXVpcmVzIERBRDogTm8iIGlzIGNvcnJlY3QuIEV2ZW4gaWYgdGhlIGRldmljZSBnZXRzIGEg LzY0IHByZWZpeCBlbnRpcmVseSBmb3IgaXRzIG93biB1c2UsIGl0IHN0aWxsIG5lZWRzIHRvIGRv IERBRCB3aXRoIGFueSBvdGhlciBkZXZpY2VzIG9uIHRoYXQgLzY0IChlLmcuLCB0ZXRoZXJlZCBk ZXZpY2VzLCBWTXMsIGV0Yy4pLg0KwqANCkknbSBub3Qgb3Bwb3NlZCB0byBhZGRpbmcgYSBsaW5l IHRvIHRoZSB0YWJsZSwgdGhvdWdoIEkgZG9uJ3QgdGhpbmsgaXQgcHJvdmlkZXMgbXVjaCB2YWx1 ZSAtIGlmIHdlIHB1dCBvdXIgbWluZCB0byBpdCwgSSdtIHN1cmUgd2UgY291bGQgY29tZSB1cCB3 aXRoIGxvdHMgb2YgdGhpbmdzIHdlIGNvdWxkIGFkZCB0byB0aGUgdGFibGUgdGhhdCBhcmVuJ3Qg dGhlcmUgYXQgdGhlIG1vbWVudC4gTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgaWYgd2UgYWRkIHNv bWV0aGluZyB0byB0aGUgdGFibGUgaXQgbmVlZHMgdG8gYmUgY29ycmVjdC4NCsKgDQpXaGF0IEkg bWVhbiBpcyDigJxSZXF1aXJlcyBEQUQgb24gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBw cmVmaXggd2FzIHJlY2VpdmVk4oCdLA0KYnV0IHRoYXQgd2FzIHRvbyBsb25nIHRvIGZpdCBpbiB0 aGUgdGFibGUuIExldOKAmXMgY2FsbCB0aGUgaW50ZXJmYWNlIOKAnEHigJ0uIElmIHRoZSBub2Rl IGdldHMNClNMQUFDIGFkZHJlc3NlcyBvciBESENQIElBX05BL0lBX1RBIGFkZHJlc3NlcyBvdmVy IGludGVyZmFjZSDigJxB4oCdLCB0aGVuIGl0IG5lZWRzDQp0byBkbyBEQUQgb24gaW50ZXJmYWNl IOKAnEHigJ0gZm9yIGVhY2ggc3VjaCBhZGRyZXNzLiBJZiB0aGUgbm9kZSBnZXRzIGEgREhDUHY2 IFBEDQpvdmVyIGludGVyZmFjZSDigJxB4oCdLCBob3dldmVyLCBpdCBkb2VzIG5vdCBuZWVkIHRv IGRvIERBRCBvdmVyIGludGVyZmFjZSDigJxB4oCdIGF0IGFsbC4NCsKgDQpJZiB0aGUgbm9kZSBh c3NpZ25zIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHRvIGludGVyZmFjZSDigJxC4oCdLCB0aGVuIHlv dSBhcmUgcmlnaHQgdGhhdA0KdGhhdCBEQUQgd2lsbCBiZSByZXF1aXJlZCBhbW9uZyBhbGwgdGV0 aGVyZWQgZGV2aWNlcywgVk1zLCBldGMuIG9uIGludGVyZmFjZSDigJxC4oCdLg0KQnV0LCB0aGVy ZSB3aWxsIHN0aWxsIGJlIG5vIG5lZWQgZm9yIERBRCBvbiBpbnRlcmZhY2Ug4oCcQeKAnS4gRG9l cyB0aGF0IGNsYXJpZnk/DQoNCkkgZGlkbid0IG5lZWQgY2xhcmlmaWNhdGlvbiwgSSBhbHJlYWR5 IGtuZXcgd2hhdCB5b3UgbWVhbnQuIE15IHBvaW50IGlzIHRoYXQ6DQrigKIgSSBkb24ndCB0aGlu ayB3ZSBjYW4gY2xhcmlmeSBpdCB3aXRob3V0IG92ZXJmbG93aW5nIHRoZSBzcGFjZSBpbiB0aGUg dGFibGUgY2VsbA0K4oCiIElmIHdlIGNsYXJpZnkgaXQgdXNpbmcgdGV4dCBvdXRzaWRlIHRoZSB0 YWJsZSBjZWxsLCB0aGVuIHRoYXQgbWVhbnMgd2UgbmVlZCB0byBleHBsYWluIHRoZSBvdGhlciB0 YWJsZSByb3dzIGFzIHdlbGwsIGZvciBjb25zaXN0ZW5jeS4NCuKAoiBUaGF0IG9wZW5zIHVzIHVw IHRvIGZyZXNoIGRpc2N1c3Npb25zIG9uIHdoYXQgdGV4dCB0byB3cml0ZSBpbiB0aG9zZSBleHBs YW5hdGlvbnMsIHdoaWNoIGNvdWxkIHBvdGVudGlhbGx5IGJlY29tZSBsb25nIGFuZCBpbnZvbHZl ZC4NCuKAoiBJdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZSBhYm92ZSBpcyB3b3J0aCBoYXZp bmcgdGhpcyBleHRyYSByb3cgaW4gdGhlIHRhYmxlLg0KVGh1cyBJJ2QgcHJlZmVyIG5vdCB0byBh biBleHRyYSByb3cuDQoNCkZMVCA+Pj4gSXQgc2VlbXMgdG8gbWUgeW91IGRpZCBuZWVkIGNsYXJp ZmljYXRpb24sIGFuZCB5ZXMgREFEIGF2b2lkYW5jZSBpcyBhDQpGVEwgPj4+IGJpZyBkZWFsIHdv cnRoIG5vdGluZyBpbiB0aGUgdGFibGUuDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIGFsc28gb24gdGFi bGUgMS4gVW5kZXIgIiJVbmxpbWl0ZWQiIGVuZHBvaW50cyIsIHdoeSBkb2VzDQppdCBzYXkgIm5v IiBmb3IgREhDUHY2IFBEPyBJIHRoaW5rIGl0IHNob3VsZCBzYXkgInllcyIgaW5zdGVhZCwgc2lu Y2UgYSBwcmVmaXgNCm9idGFpbmVkIGJ5IERIQ1B2NiBQRCBjYW4gYmUgdXNlZCB0byBjb25maWd1 cmUgYW4gdW5saW1pdGVkIG51bWJlciBvZg0KYWRkcmVzc2VzIG9uIHRoZSBsaW5rIG92ZXIgd2hp Y2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWQuDQrCoA0KVGhlIHRhYmxlIGlzIHdyaXR0ZW4gZnJv bSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIG5ldHdvcmsgYXNzaWduaW5nIGFkZHJlc3NlcyB0byBk ZXZpY2VzIHRoYXQgY29ubmVjdCB0byBpdC4gVGhlcmVmb3JlLCBpdCBzYXlzICJubyIgYmVjYXVz ZSBpZiB5b3UgdXNlIERIQ1B2NiBQRCB5b3UgY2FuJ3QgYXNzaWduIGFkZHJlc3Mgc3BhY2UgdG8g YW4gdW5saW1pdGVkIG51bWJlciBvZiBlbmRwb2ludHMgLSB5b3UgYXJlIGxpbWl0ZWQgdG8gaG93 ZXZlciBtYW55IC82NHMgeW91IGhhdmUgYXZhaWxhYmxlLg0KDQpGTFQ+Pj4gQnV0LCB0aGVyZSBh cmUgYmlsbGlvbnMgb2YgLzY0cyBhdmFpbGFibGUgZXZlbiBpbiBqdXN0IGEgLzMyLiBJZiB5b3Ug d2FudCB0bw0KRkxUPj4+IGRlbGVnYXRlIC82NHMgdG8gYmlsbGlvbnMgb2Ygbm9kZXMsIGp1c3Qg dXNlIERIQ1B2NiBQRC4NCsKgDQpJZiB5b3UgdXNlIElBX05BIG9yIFNMQUFDLCBhbnkgbmV0d29y ayB3aXRoIGEgLzY0IHN1Ym5ldCBoYXMsIGF0IGxlYXN0IGluIHRoZW9yeSwgYW4gInVubGltaXRl ZCIgbnVtYmVyIG9mIGFkZHJlc3NlcyB0byBhc3NpZ24gdG8gY2xpZW50cy4gT2YgY291cnNlLCB0 aGF0J3Mgb25seSB0cnVlIGluIHRoZW9yeS4gSW4gcHJhY3RpY2UsIHRoZXJlJ3MgZ29pbmcgdG8g YmUgYSBsaW1pdCBkdWUgdG8gc2NhbGluZyByZWFzb25zLg0KDQpGTFQ+Pj4gU2NhbGluZyBsaW1p dHMgYXBwbHkgdG8gdGhlIG51bWJlciBvZiBub2RlcyB0aGF0IGNhbiBiZSBhY2NvbW1vZGF0ZWQN CkZMVD4+PiBvbiBhIGxpbmsgdGhhdCBpcyBzZXJ2aWNlZCBieSBTTEFBQyBhbmQvb3IgREhDUHY2 IElBX05BL0lBX1RBLCB5ZXMuDQpGTFQ+Pj4gSXQgaXMgcHJvYmFibHkgYSByZXNlYXJjaCBxdWVz dGlvbiBhcyB0byB3aGV0aGVyIHRoZSBzY2FsaW5nIGxpbWl0cyBmb3INCkZMVD4+PiBESENQdjYg UEQgYXJlIG1vcmUgb3IgbGVzcyBwcmVzc2luZyB0aGFuIHRoZSBzY2FsaW5nIGxpbWl0cyBmb3IN CkZMVD4+PiBTTEFBQy9ESENQdjYgSUFfTkEvSUFfVEEuIFRoZSBsaW5lIGluIHlvdXIgdGFibGUg aXMgdGhlcmVmb3JlDQpGTFQ+Pj4gbWVhbmluZ2xlc3MgYW5kIGNvdWxkIGJlIHJlbW92ZWQuDQrC oA0KSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcy4gVHJ1ZSB0aGF0IFNMQUFDIGFuZCBESENQdjYg SUFfTkEvSUFfVEEgY2FuIGJlIHVzZWQNCnRvIGFzc2lnbiBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9m IGFkZHJlc3NlcyB0byBpbnRlcmZhY2Ug4oCcQeKAnS4gQnV0LCBzbyBjYW4gREhDUHY2DQpQRC4g V2hlbiB0aGUgbm9kZSByZWNlaXZlcyB0aGUgZGVsZWdhdGVkIHByZWZpeCAoZS5nLiwgYSAvNjQp LCBpdCBjYW4gYXNzaWduIGFzDQptYW55IHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBhcyBpdCBsaWtl cyB0byBpbnRlcmZhY2Ug4oCcQeKAnS4gQW5kIGFnYWluLCBpdCBuZWVkIG5vdA0KZG8gREFEIGZv ciBhbnkgb2YgdGhlbS4NCg0KSSB0aGluayB5b3UncmUgY29uZnVzaW5nIHVubGltaXRlZCBhZGRy ZXNzZXMgd2l0aCB1bmxpbWl0ZWQgZW5kcG9pbnRzLiBXaXRoIElBX05BIG9yIFNMQUFDLCB5b3Ug Y2FuIG51bWJlciBiaWxsaW9ucyBvZiBlbmRwb2ludHMsIGVhY2ggb2Ygd2hpY2ggbWlnaHQgb25s eSBoYXZlIGEgZmV3IGFkZHJlc3Nlcy4gV2l0aCBESENQdjYgUEQsIHlvdSBjYW4gb25seSBudW1i ZXIgYXMgbWFueSBlbmRwb2ludHMgYXMgeW91IGhhdmUgLzY0cy4gRWFjaCBvZiB0aG9zZSBlbmRw b2ludHMgbWlnaHQgYmUgdXNpbmcgYW4gdW5saW1pdGVkIG51bWJlciBvZiBhZGRyZXNzZXMsIGJ1 dCB0aGVyZSBpcyBzdGlsbCBhIGxpbWl0ZWQgbnVtYmVyIG9mIHRoZW0uDQoNCkZMVD4+PiBBZ2Fp biwgdGhlIHNjYWxpbmcgcXVlc3Rpb24gY29tZXMgdG8gd2hldGhlciBhIHNpbmdsZSBsaW5rIGNh biBhY2NvbW1vZGF0ZQ0KRkxUPj4+IG1vcmUgZW5kcG9pbnRzIHVzaW5nIFNMQUFDL0RIQ1B2NiBJ QV9OQS9JQV9UQSBvciBESENQdjYgUEQgaWYgdGhlDQpGTFQ+Pj4gbnVtYmVyIG9mIGVsaWdpYmxl IC82NHMgbnVtYmVycyBpbiB0aGUgYmlsbGlvbnMuDQo= From nobody Mon Nov 2 23:11: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 140E21B2DA5 for ; Mon, 2 Nov 2015 23:11:01 -0800 (PST) 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 RFYUdp5Y2zJe for ; Mon, 2 Nov 2015 23:10:58 -0800 (PST) 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 898891ACD3D for ; Mon, 2 Nov 2015 23:10:58 -0800 (PST) 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 tA37AveK013959; Tue, 3 Nov 2015 01:10:57 -0600 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA37Ar5U013925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 01:10:53 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.155]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 23:10:51 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYIAAmQqA//+47LA= Date: Tue, 3 Nov 2015 07:10:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> In-Reply-To: <563821EB.3040508@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] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 07:11:01 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNjo1NSBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBMb3JlbnpvIENvbGl0dGkNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb djZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9u DQo+IA0KPiBIaSBGcmVkLA0KPiBPbiAwMy8xMS8yMDE1IDE0OjU5LCBUZW1wbGluLCBGcmVkIEwg d3JvdGU6DQo+ID4gSGkgQnJpYW4sDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTo0NiBQ TQ0KPiA+PiBUbzogVGVtcGxpbiwgRnJlZCBMOyBMb3JlbnpvIENvbGl0dGkNCj4gPj4gQ2M6IHY2 b3BzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMt aG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4+DQo+ID4+IE9uIDAzLzExLzIw MTUgMTQ6MzEsIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPj4+IEJ1bXBpbmcgdXAgb25lIGxl dmVsIOKAkyBpcyBpdCBjbGVhciB0byBldmVyeW9uZSB0aGF0IGl0IGlzIE9LIHRvIGFzc2lnbiBh ZGRyZXNzZXMNCj4gPj4+IHRha2VuIGZyb20gYSBESENQdjYgZGVsZWdhdGVkIHByZWZpeCB0byB0 aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeA0KPiA+Pj4gd2FzIHJlY2VpdmVkPw0K PiA+Pg0KPiA+PiBJZiBpdCB3YXMgbGVnaXRpbWF0ZWx5IHJlY2VpdmVkLCBJIGNhbid0IHNlZSB3 aHkgaXQgd291bGRuJ3QgYmUgT0suDQo+ID4NCj4gPiBPSy4gV2hlbiB0aGUgREhDUHY2IHNlcnZl ciBncmFudHMgYSBwcmVmaXggZGVsZWdhdGlvbiB0byB0aGUgY2xpZW50LA0KPiA+IHRoZSBzZXJ2 ZXIgaXMgYXNzZXJ0aW5nIHRoYXQgdGhhdCBwcmVmaXggaXMgdW5pcXVlIGFuZCBpcyBub3cgdGhl IHNvbGUNCj4gPiBwcm9wZXJ0eSBvZiB0aGUgY2xpZW50LiBTbywgd2hlbiB5b3Ugc2F5IGxlZ2l0 aW1hdGVseSByZWNlaXZlZCBJDQo+ID4gYWdyZWUgYW5kIHRoYXQgaXMgYWN0dWFsbHkgYSBjb3Jl IHJlcXVpcmVtZW50IG9mIERIQ1B2NiBQRC4NCj4gPiBPdGhlcndpc2UsIGlmIHRoZSBESENQdjYg c2VydmVyIGdhdmUgb3V0IGR1cGxpY2F0ZSBwcmVmaXhlcywgdGhlDQo+ID4gcm91dGluZyBzeXN0 ZW0gd291bGQgYmVjb21lIGhvcGVsZXNzbHkgY29ycnVwdGVkIGFuZCBhZGRyZXNzDQo+ID4gZHVw bGljYXRpb24gd291bGQgYmUgdGhlIGxlYXN0IG9mIG91ciB3b3JyaWVzLg0KPiA+DQo+ID4+PiBB bmQsIHRoYXQgREFEIGlzIG5vdCByZXF1aXJlZCBmb3IgdGhvc2UgYWRkcmVzc2VzPw0KPiA+Pg0K PiA+PiBIb3cgaXMgdGhhdCBzYWZlPyBXaGF0IGlzIHRvIHN0b3AgYSBob3N0IHJ1bm5pbmcgU0xB QUMgb25jZSBpdA0KPiA+PiBzZWVzIHRoYXQgcHJlZml4IGluIGFuIFJBLCBhbmQgaGl0dGluZyB0 aGUgc2FtZSBJSUQgYnkgY2hhbmNlPw0KPiA+PiBBdCBsZWFzdCB5b3UgbmVlZCB0byBzcGVjaWZ5 IHRoYXQgdGhlIEEgYml0IG11c3Qgbm90IGJlIHNldC4NCj4gPg0KPiA+IEkgYW0gdGFsa2luZyBh Ym91dCBEQUQgb24gaW50ZXJmYWNlICJBIiBiZWluZyB0aGUgaW50ZXJmYWNlIG92ZXINCj4gPiB3 aGljaCB0aGUgY2xpZW50IHJlY2VpdmVzIHRoZSBwcmVmaXggZGVsZWdhdGlvbi4gTm8gb3RoZXIg bm9kZSBvbg0KPiA+IGludGVyZmFjZSAiQSIgbWF5IHVzZSB0aGUgZGVsZWdhdGVkIHByZWZpeCwg YW5kIG5vIHJvdXRlciBvbg0KPiA+IGludGVyZmFjZSAiQSIgbWF5IGFkdmVydGlzZSB0aGUgcHJl Zml4IGluIGFuIFJBLiBUaGUgcHJlZml4IGlzIHRoZQ0KPiA+IHNvbGUgcHJvcGVydHkgb2YgdGhl IGNsaWVudCB0aGF0IHJlY2VpdmVkIHRoZSBQRCwgc28gdGhlIGNsaWVudCBpcw0KPiA+IGZyZWUg dG8gYXNzaWduIGFkZHJlc3NlcyB3aXRob3V0IG5lZWRpbmcgREFELg0KPiANCj4gVGhhdCB1c2Fn ZSBvZiAibWF5IiBtaWdodCBjb25mdXNlIHNvbWUgcGVvcGxlLCBzbyBsZXQncyBwcmV0ZW5kDQo+ IHlvdSB1c2VkIGEgIk1VU1QgTk9UIiBjb25zdHJ1Y3QgaW5zdGVhZC4gSSBjb3VsZCBzdGlsbCBj b25zdHJ1Y3QNCj4gYSBob3N0IHN0YWNrIHRoYXQgd291bGQgaWdub3JlIHRoZSBpc3N1ZTogaXRz IGxvZ2ljIHdvdWxkIGJlDQo+ICJJIHNlbnQgYW4gUlMgYW5kIGdvdCBubyBSQS9QSU8gd2l0aCBB PTE7IGJ1dCBJIHNlZSB0cmFmZmljIGZyb20NCj4gcHJlZml4IDJiYWQ6ZGVhZDpiZWVmOjovNjQs IHNvIEknbGwgZG8gU0xBQUMgYW5kIERBRCBpbiB0aGF0IHByZWZpeC4iDQoNClRoZSBtYWxpY2lv dXMgKG9yIG90aGVyd2lzZSBicm9rZW4pIGhvc3QgJ0EnIGNvdWxkIGNvbmZpZ3VyZSBhbnkgbnVt YmVyDQpvZiBhZGRyZXNzZXMgaXQgbGlrZXMsIGJ1dCBpdCB3b3VsZCBkbyBzbyBpbiBhIHZhY3V1 bSBiZWNhdXNlIGluZ3Jlc3MNCmZpbHRlcmluZyB3aWxsIHByZXZlbnQgYSBwYWNrZXQgd2l0aCBh IHNvdXJjZSBhZGRyZXNzIGZyb20gYSBwcmVmaXgNCmJlbG9uZ2luZyB0byBob3N0IEIgZnJvbSBi ZWluZyBhY2NlcHRlZC4gU28sIG5vZGUgQiBoYXMgbm8gcmVhc29uDQp0byBmZWFyIGFkZHJlc3Mg ZHVwbGljYXRpb24gYnkgbm9kZSBBLg0KDQpBbHNvLCB3aGF0IGlmIG5vZGUgQiBpbiBmYWN0IGRp ZCBkbyBEQUQgYW5kIEEgaGVhcmQgaXQ/IFdoYXQgaXMgdG8gc3RvcA0KQSBmcm9tIGNvbmZpZ3Vy aW5nIGEgZHVwbGljYXRlIGFkZHJlc3MgYW5kIHRyeWluZyB0byB1c2UgaXQganVzdCB0byBtZXNz DQp1cCB0aGUgbGVnaXRpbWF0ZSBvcGVyYXRpb24gb2Ygbm9kZSBCPw0KDQpXaGF0IHlvdSBhcmUg ZGVzY3JpYmluZyBpcyBhIGJyb2tlbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGNvdWxkIG9ubHkNCmJl IGVtcGxveWVkIGJ5IGEgbWFsaWNpb3VzIGhvc3QsIGFuZCBub3Qgc29tZXRoaW5nIHRoYXQgaG9u b3JzDQp0aGUgc3RhbmRhcmRzLiBEb2luZyBEQUQgaXMgbm90IGdvaW5nIHRvIGd1YXJkIGFnYWlu c3QgbWFsaWNpb3VzDQpob3N0cy4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYmVv aW5nLmNvbSANCg0KPiA+PiBDb21lIHRvIHRoYXQsIGEgbWFudWFsIGFkZHJlc3MgbWlnaHQgY29s bGlkZS4NCj4gPg0KPiA+IFRoZSBjbGllbnQgaXRzZWxmIGlzIHRoZSBvbmx5IG5vZGUgdGhhdCBp cyBwZXJtaXR0ZWQgdG8gYXNzaWduIGFkZHJlc3Nlcw0KPiA+IGZyb20gdGhlIGRlbGVnYXRlZCBw cmVmaXggdG8gYW4gaW50ZXJmYWNlLCBzbyB0aGVyZSBpcyBubyByaXNrIG9mDQo+ID4gY29sbGlz aW9uIHVubGVzcyB0aGUgY2xpZW50IGl0c2VsZiBpcyBzb21laG93IGNvcnJ1cHQuDQo+IA0KPiBP ciBhbm90aGVyIGNsaWVudCBvbiB0aGUgc2FtZSBMQU4gZ2V0cyB0b28gY2xldmVyLg0KPiANCj4g ICAgQnJpYW4NCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5A Ym9laW5nLmNvbQ0KPiA+DQo+ID4+ICAgICBCcmlhbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5r cyAtIEZyZWQNCj4gPj4+DQo+ID4+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNCj4gPj4+IFNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMDIsIDIwMTUgNToyNCBQTQ0KPiA+Pj4gVG86IExvcmVuem8gQ29saXR0aQ0K PiA+Pj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFm dC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KPiA+Pj4NCj4g Pj4+IEhpIExvcmVuem8sDQo+ID4+Pg0KPiA+Pj4gUmVzcG9uc2VzIGJlbG93IGluIOKAnGdyZWVu 4oCdOg0KPiA+Pj4NCj4gPj4+IEZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbV0NCj4gPj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTowNCBQ TQ0KPiA+Pj4gVG86IFRlbXBsaW4sIEZyZWQgTA0KPiA+Pj4gQ2M6IEZyZWQgQmFrZXIgKGZyZWQp OyB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+ID4+PiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vz c2lvbg0KPiA+Pj4NCj4gPj4+IE9uIFR1ZSwgTm92IDMsIDIwMTUgYXQgODo1OSBBTSwgVGVtcGxp biwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPj4gd3JvdGU6DQo+ID4+PiBJIGhhdmUgb25lIHRleHQgYWRkaXRpb24gc3Vn Z2VzdGlvbiBhbmQgb25lIHF1ZXN0aW9uLiBPbiBQLiA3LCBpbiBUYWJsZSAxLA0KPiA+Pj4gc3Vn Z2VzdCBhZGRpbmcgYSBuZXcgZmluYWwgcm93IGFzIGZvbGxvd3M6DQo+ID4+Pg0KPiA+Pj4gICBy ZXF1aXJlcyBEQUQgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgICAgICBZZXMgICAgICAg ICAgICAgICAgICAgTm8gICAgICAgICAgICAgICAgIE4vQQ0KPiA+Pj4NCj4gPj4+IE1lYW5pbmcg dGhhdCBtdWx0aS1hZGRyZXNzZXMgY29uZmlndXJlZCBieSBTTEFBQyBvciBESENQdjYgSUFfTkEv SUFfVEENCj4gPj4+IG11c3QgdXNlIERBRCB0byBjaGVjayBmb3IgZHVwbGljYXRlcyBvbiB0aGUg bGluayB0aGV5IHdlcmUgb2J0YWluZWQuIEluIGENCj4gPj4+IG11bHRpLWFkZHJlc3NpbmcgZW52 aXJvbm1lbnQgd2hlcmUgbWlsbGlvbnMgb2YgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCwNCj4gPj4+ IHRoaXMgY291bGQgYW1vdW50IHRvIGEgc3Vic3RhbnRpYWwgYW1vdW50IG9mIERBRCBtdWx0aWNh c3QgdHJhZmZpYy4gT24gdGhlDQo+ID4+PiBvdGhlciBoYW5kLCBEQUQgaXMgbm90IG5lZWRlZCBm b3IgREhDUHY2IFBEIGJlY2F1c2UgdGhlIG5ldHdvcmsgaGFzDQo+ID4+PiB1bmFtYmlndW91c2x5 IGRlbGVnYXRlZCB0aGUgcHJlZml4IGZvciB0aGUgbm9kZSdzIGV4Y2x1c2l2ZSB1c2UuDQo+ID4+ Pg0KPiA+Pj4gSSBkb24ndCB0aGluayAiUmVxdWlyZXMgREFEOiBObyIgaXMgY29ycmVjdC4gRXZl biBpZiB0aGUgZGV2aWNlIGdldHMgYSAvNjQgcHJlZml4IGVudGlyZWx5IGZvciBpdHMgb3duIHVz ZSwgaXQgc3RpbGwgbmVlZHMgdG8gZG8gREFEIHdpdGgNCj4gPj4gYW55IG90aGVyIGRldmljZXMg b24gdGhhdCAvNjQgKGUuZy4sIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLikuDQo+ID4+Pg0K PiA+Pj4gSSdtIG5vdCBvcHBvc2VkIHRvIGFkZGluZyBhIGxpbmUgdG8gdGhlIHRhYmxlLCB0aG91 Z2ggSSBkb24ndCB0aGluayBpdCBwcm92aWRlcyBtdWNoIHZhbHVlIC0gaWYgd2UgcHV0IG91ciBt aW5kIHRvIGl0LCBJJ20gc3VyZSB3ZQ0KPiBjb3VsZA0KPiA+PiBjb21lIHVwIHdpdGggbG90cyBv ZiB0aGluZ3Mgd2UgY291bGQgYWRkIHRvIHRoZSB0YWJsZSB0aGF0IGFyZW4ndCB0aGVyZSBhdCB0 aGUgbW9tZW50LiBNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBpZiB3ZSBhZGQNCj4gc29tZXRoaW5n IHRvDQo+ID4+IHRoZSB0YWJsZSBpdCBuZWVkcyB0byBiZSBjb3JyZWN0Lg0KPiA+Pj4NCj4gPj4+ IFdoYXQgSSBtZWFuIGlzIOKAnFJlcXVpcmVzIERBRCBvbiB0aGUgaW50ZXJmYWNlIG92ZXIgd2hp Y2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWTigJ0sDQo+ID4+PiBidXQgdGhhdCB3YXMgdG9vIGxv bmcgdG8gZml0IGluIHRoZSB0YWJsZS4gTGV04oCZcyBjYWxsIHRoZSBpbnRlcmZhY2Ug4oCcQeKA nS4gSWYgdGhlIG5vZGUgZ2V0cw0KPiA+Pj4gU0xBQUMgYWRkcmVzc2VzIG9yIERIQ1AgSUFfTkEv SUFfVEEgYWRkcmVzc2VzIG92ZXIgaW50ZXJmYWNlIOKAnEHigJ0sIHRoZW4gaXQgbmVlZHMNCj4g Pj4+IHRvIGRvIERBRCBvbiBpbnRlcmZhY2Ug4oCcQeKAnSBmb3IgZWFjaCBzdWNoIGFkZHJlc3Mu IElmIHRoZSBub2RlIGdldHMgYSBESENQdjYgUEQNCj4gPj4+IG92ZXIgaW50ZXJmYWNlIOKAnEHi gJ0sIGhvd2V2ZXIsIGl0IGRvZXMgbm90IG5lZWQgdG8gZG8gREFEIG92ZXIgaW50ZXJmYWNlIOKA nEHigJ0gYXQgYWxsLg0KPiA+Pj4NCj4gPj4+IElmIHRoZSBub2RlIGFzc2lnbnMgdGhlIGRlbGVn YXRlZCBwcmVmaXggdG8gaW50ZXJmYWNlIOKAnELigJ0sIHRoZW4geW91IGFyZSByaWdodCB0aGF0 DQo+ID4+PiB0aGF0IERBRCB3aWxsIGJlIHJlcXVpcmVkIGFtb25nIGFsbCB0ZXRoZXJlZCBkZXZp Y2VzLCBWTXMsIGV0Yy4gb24gaW50ZXJmYWNlIOKAnELigJ0uDQo+ID4+PiBCdXQsIHRoZXJlIHdp bGwgc3RpbGwgYmUgbm8gbmVlZCBmb3IgREFEIG9uIGludGVyZmFjZSDigJxB4oCdLiBEb2VzIHRo YXQgY2xhcmlmeT8NCj4gPj4+DQo+ID4+PiBJIGhhdmUgYSBxdWVzdGlvbiBhbHNvIG9uIHRhYmxl IDEuIFVuZGVyICIiVW5saW1pdGVkIiBlbmRwb2ludHMiLCB3aHkgZG9lcw0KPiA+Pj4gaXQgc2F5 ICJubyIgZm9yIERIQ1B2NiBQRD8gSSB0aGluayBpdCBzaG91bGQgc2F5ICJ5ZXMiIGluc3RlYWQs IHNpbmNlIGEgcHJlZml4DQo+ID4+PiBvYnRhaW5lZCBieSBESENQdjYgUEQgY2FuIGJlIHVzZWQg dG8gY29uZmlndXJlIGFuIHVubGltaXRlZCBudW1iZXIgb2YNCj4gPj4+IGFkZHJlc3NlcyBvbiB0 aGUgbGluayBvdmVyIHdoaWNoIHRoZSBwcmVmaXggd2FzIHJlY2VpdmVkLg0KPiA+Pj4NCj4gPj4+ IFRoZSB0YWJsZSBpcyB3cml0dGVuIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBuZXR3b3Jr IGFzc2lnbmluZyBhZGRyZXNzZXMgdG8gZGV2aWNlcyB0aGF0IGNvbm5lY3QgdG8gaXQuIFRoZXJl Zm9yZSwgaXQgc2F5cyAibm8iDQo+ID4+IGJlY2F1c2UgaWYgeW91IHVzZSBESENQdjYgUEQgeW91 IGNhbid0IGFzc2lnbiBhZGRyZXNzIHNwYWNlIHRvIGFuIHVubGltaXRlZCBudW1iZXIgb2YgZW5k cG9pbnRzIC0geW91IGFyZSBsaW1pdGVkIHRvIGhvd2V2ZXINCj4gbWFueQ0KPiA+PiAvNjRzIHlv dSBoYXZlIGF2YWlsYWJsZS4NCj4gPj4+DQo+ID4+PiBJZiB5b3UgdXNlIElBX05BIG9yIFNMQUFD LCBhbnkgbmV0d29yayB3aXRoIGEgLzY0IHN1Ym5ldCBoYXMsIGF0IGxlYXN0IGluIHRoZW9yeSwg YW4gInVubGltaXRlZCIgbnVtYmVyIG9mIGFkZHJlc3NlcyB0byBhc3NpZ24gdG8NCj4gPj4gY2xp ZW50cy4gT2YgY291cnNlLCB0aGF0J3Mgb25seSB0cnVlIGluIHRoZW9yeS4gSW4gcHJhY3RpY2Us IHRoZXJlJ3MgZ29pbmcgdG8gYmUgYSBsaW1pdCBkdWUgdG8gc2NhbGluZyByZWFzb25zLg0KPiA+ Pj4NCj4gPj4+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMuIFRydWUgdGhhdCBTTEFBQyBhbmQg REhDUHY2IElBX05BL0lBX1RBIGNhbiBiZSB1c2VkDQo+ID4+PiB0byBhc3NpZ24gYW4gdW5saW1p dGVkIG51bWJlciBvZiBhZGRyZXNzZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEJ1dCwgc28gY2Fu IERIQ1B2Ng0KPiA+Pj4gUEQuIFdoZW4gdGhlIG5vZGUgcmVjZWl2ZXMgdGhlIGRlbGVnYXRlZCBw cmVmaXggKGUuZy4sIGEgLzY0KSwgaXQgY2FuIGFzc2lnbiBhcw0KPiA+Pj4gbWFueSB1bmlxdWUg SVB2NiBhZGRyZXNzZXMgYXMgaXQgbGlrZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEFuZCBhZ2Fp biwgaXQgbmVlZCBub3QNCj4gPj4+IGRvIERBRCBmb3IgYW55IG9mIHRoZW0uDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+PiB2Nm9wc0BpZXRmLm9yZw0K PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4N Cj4gPg0KDQo= From nobody Mon Nov 2 23:13: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 C20461B2F20 for ; Mon, 2 Nov 2015 23:13:52 -0800 (PST) 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 o2-uyWIYdPv2 for ; Mon, 2 Nov 2015 23:13:50 -0800 (PST) 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 AA43D1B2F1E for ; Mon, 2 Nov 2015 23:13:50 -0800 (PST) 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 tA37Dnmb000580; Tue, 3 Nov 2015 01:13:49 -0600 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA37DeNF000567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 01:13:41 -0600 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; Mon, 2 Nov 2015 23:13:40 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD Thread-Index: AQHRFgcqdk6EvbJyb0KpuVefeTAGTg== Date: Tue, 3 Nov 2015 07:13:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> In-Reply-To: <5638223E.5090404@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] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 07:13:52 -0000 Hi Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Monday, November 02, 2015 6:56 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion -= address out of the delegated prefix, on the egress - no DAD >=20 >=20 >=20 > Le 03/11/2015 10:31, Templin, Fred L a =E9crit : > > Bumping up one level - is it clear to everyone that it is OK to > > assign addresses taken from a DHCPv6 delegated prefix to the interface = over which the > > prefix was received? And, that DAD is not required for those addresses? >=20 > This indeed new enough at least to me. >=20 > I agree that if the prefix is delegated for Host with DHCP-PD then it > has a tighter bind to that Host, tighter than a prefix _advertised_ to > it with an RA. >=20 > In that sense, certainly yes the Host may self-form and assign an > address on its interface over which the application DHCP-PD received it > earlier. >=20 > And, since the prefix is administratively unique, it would make little > sense for the Host to DAD that address on that interface. >=20 > Moreover, it would bring some advantages for privacy. Privacy addresses > as we know them make only the IID variable, while still keeping a > trackable prefix (the advertised prefix). With this way of prefix > delegation, the Host may decide more ways to obfuscate its identity: use > sometimes the allocated prefix, other times the advertised prefix, in > some hard-to-detect sequence. >=20 > But, if a Host forms an address out of the delegated prefix and wants to > talk to its Gateway on that interface, maybe it wants to send an RA to > that Gateway so the Gateway forms an address out of the delegated prefix > too. At that point DAD would be needed. "Host sends an RA to the Gateway" doesn't make any sense that I am aware of. Thanks - Fred >=20 > Alex >=20 > > > > Thanks - Fred > > > > *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Templin, > > Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:* Lorenzo > > Colitti *Cc:* v6ops@ietf.org *Subject:* Re: [v6ops] > > draft-ietf-v6ops-host-addr-availability discussion > > > > Hi Lorenzo, > > > > Responses below in "green": > > > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* Monday, > > November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:* Fred Baker > > (fred); v6ops@ietf.org *Subject:* Re: [v6ops] > > draft-ietf-v6ops-host-addr-availability discussion > > > > On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > > > > > wrote: > > > > I have one text addition suggestion and one question. On P. 7, in > > Table 1, suggest adding a new final row as follows: > > > > requires DAD Yes Yes No > > N/A > > > > Meaning that multi-addresses configured by SLAAC or DHCPv6 > > IA_NA/IA_TA must use DAD to check for duplicates on the link they > > were obtained. In a multi-addressing environment where millions of > > addresses are required, this could amount to a substantial amount of > > DAD multicast traffic. On the other hand, DAD is not needed for > > DHCPv6 PD because the network has unambiguously delegated the prefix > > for the node's exclusive use. > > > > I don't think "Requires DAD: No" is correct. Even if the device gets > > a /64 prefix entirely for its own use, it still needs to do DAD with > > any other devices on that /64 (e.g., tethered devices, VMs, etc.). > > > > I'm not opposed to adding a line to the table, though I don't think > > it provides much value - if we put our mind to it, I'm sure we could > > come up with lots of things we could add to the table that aren't > > there at the moment. My main concern is that if we add something to > > the table it needs to be correct. > > > > What I mean is "Requires DAD on the interface over which the prefix > > was received", > > > > but that was too long to fit in the table. Let's call the interface > > "A". If the node gets > > > > SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface "A", > > then it needs > > > > to do DAD on interface "A" for each such address. If the node gets a > > DHCPv6 PD > > > > over interface "A", however, it does not need to do DAD over > > interface "A" at all. > > > > If the node assigns the delegated prefix to interface "B", then you > > are right that > > > > that DAD will be required among all tethered devices, VMs, etc. on > > interface "B". > > > > But, there will still be no need for DAD on interface "A". Does that > > clarify? > > > > I have a question also on table 1. Under ""Unlimited" endpoints", why > > does it say "no" for DHCPv6 PD? I think it should say "yes" instead, > > since a prefix obtained by DHCPv6 PD can be used to configure an > > unlimited number of addresses on the link over which the prefix was > > received. > > > > The table is written from the perspective of the network assigning > > addresses to devices that connect to it. Therefore, it says "no" > > because if you use DHCPv6 PD you can't assign address space to an > > unlimited number of endpoints - you are limited to however many /64s > > you have available. > > > > If you use IA_NA or SLAAC, any network with a /64 subnet has, at > > least in theory, an "unlimited" number of addresses to assign to > > clients. Of course, that's only true in theory. In practice, there's > > going to be a limit due to scaling reasons. > > > > I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can > > be used > > > > to assign an unlimited number of addresses to interface "A". But, so > > can DHCPv6 > > > > PD. When the node receives the delegated prefix (e.g., a /64), it can > > assign as > > > > many unique IPv6 addresses as it likes to interface "A". And again, > > it need not > > > > do DAD for any of them. > > > > > > > > _______________________________________________ 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 Nov 2 23:16: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 5B14B1A8927 for ; Mon, 2 Nov 2015 23:15:59 -0800 (PST) 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 Ly_lEkPF6gfG for ; Mon, 2 Nov 2015 23:15:57 -0800 (PST) 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 F3A791B2C2C for ; Mon, 2 Nov 2015 23:15:41 -0800 (PST) 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 tA37Ff1N056308; Tue, 3 Nov 2015 00:15:41 -0700 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA37Fct3056142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 00:15:39 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.155]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 23:15:38 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , Alexandre Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD Thread-Index: AQHRFgdwer7XUB2060uOBZVAXvxlBw== Date: Tue, 3 Nov 2015 07:15:38 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F39A3F@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@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_2134F8430051B64F815C691A62D9831832F39A3FXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 07:15:59 -0000 --_000_2134F8430051B64F815C691A62D9831832F39A3FXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDAy LCAyMDE1IDc6MDQgUE0NClRvOiBBbGV4YW5kcmUgUGV0cmVzY3UNCkNjOiB2Nm9wc0BpZXRmLm9y ZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZh aWxhYmlsaXR5IGRpc2N1c3Npb24gLSBhZGRyZXNzIG91dCBvZiB0aGUgZGVsZWdhdGVkIHByZWZp eCwgb24gdGhlIGVncmVzcyAtIG5vIERBRA0KDQpPbiBUdWUsIE5vdiAzLCAyMDE1IGF0IDExOjU1 IEFNLCBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208bWFp bHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToNCkxlIDAzLzExLzIwMTUg MTA6MzEsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQpCdW1waW5nIHVwIG9uZSBsZXZlbCDi gJMgaXMgaXQgY2xlYXIgdG8gZXZlcnlvbmUgdGhhdCBpdCBpcyBPSyB0bw0KYXNzaWduIGFkZHJl c3NlcyB0YWtlbiBmcm9tIGEgREhDUHY2IGRlbGVnYXRlZCBwcmVmaXggdG8gdGhlIGludGVyZmFj ZSBvdmVyIHdoaWNoIHRoZQ0KcHJlZml4IHdhcyByZWNlaXZlZD8gQW5kLCB0aGF0IERBRCBpcyBu b3QgcmVxdWlyZWQgZm9yIHRob3NlIGFkZHJlc3Nlcz8NCg0KSXMgdGhpcyBhIHN0YXRlbWVudCB3 ZSBuZWVkIHRvIG1ha2UgaW4gdGhpcyBkcmFmdCwgdGhvdWdoPw0KDQpGTFQ+Pj4gSSB0aGluayBz by4gQW4gb3Bwb3J0dW5pdHkgZm9yIERBRCBhdm9pZGFuY2Ugd2hlbiB3ZSBhcmUgdGFsa2luZyBh Ym91dA0KRkxUPj4+IGNvbmZpZ3VyaW5nIGh1Z2UgbnVtYmVycyBvZiBhZGRyZXNzZXMgc2VlbXMg bGlrZSBhIHNpZ25pZmljYW50IGFkdmFudGFnZS4NCg== --_000_2134F8430051B64F815C691A62D9831832F39A3FXCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5M b3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAx NSA3OjA0IFBNPGJyPg0KPGI+VG86PC9iPiBBbGV4YW5kcmUgUGV0cmVzY3U8YnI+DQo8Yj5DYzo8 L2I+IHY2b3BzQGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uIC0gYWRkcmVz cyBvdXQgb2YgdGhlIGRlbGVnYXRlZCBwcmVmaXgsIG9uIHRoZSBlZ3Jlc3MgLSBubyBEQUQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIE5vdiAzLCAyMDE1IGF0IDExOjU1IEFNLCBBbGV4YW5kcmUgUGV0cmVz Y3UgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDAzLzEx LzIwMTUgMTA6MzEsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnVtcGluZyB1cCBvbmUgbGV2ZWwg4oCT IGlzIGl0IGNsZWFyIHRvIGV2ZXJ5b25lIHRoYXQgaXQgaXMgT0sgdG88YnI+DQphc3NpZ24gYWRk cmVzc2VzIHRha2VuIGZyb20gYSBESENQdjYgZGVsZWdhdGVkIHByZWZpeCB0byB0aGUgaW50ZXJm YWNlIG92ZXIgd2hpY2ggdGhlPGJyPg0KcHJlZml4IHdhcyByZWNlaXZlZD8gQW5kLCB0aGF0IERB RCBpcyBub3QgcmVxdWlyZWQgZm9yIHRob3NlIGFkZHJlc3Nlcz88bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklzIHRoaXMgYSBzdGF0ZW1lbnQgd2UgbmVlZCB0byBtYWtlIGluIHRoaXMgZHJhZnQsIHRob3Vn aD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RkxUJmd0OyZndDsmZ3Q7IEkg dGhpbmsgc28uIEFuIG9wcG9ydHVuaXR5IGZvciBEQUQgYXZvaWRhbmNlIHdoZW4gd2UgYXJlIHRh bGtpbmcgYWJvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RkxUJmd0OyZndDsmZ3Q7IGNvbmZpZ3VyaW5n IGh1Z2UgbnVtYmVycyBvZiBhZGRyZXNzZXMgc2VlbXMgbGlrZSBhIHNpZ25pZmljYW50IGFkdmFu dGFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832F39A3FXCHBLV504nwnosb_-- From nobody Mon Nov 2 23:40: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 A86D71A7017 for ; Mon, 2 Nov 2015 23:40:22 -0800 (PST) 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, 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 6MU3oELAb05N for ; Mon, 2 Nov 2015 23:40:19 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id A50301A6EDC for ; Mon, 2 Nov 2015 23:40:19 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 3 Nov 2015 01:40:18 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f170.google.com [209.85.213.170] #+LO+TS+TR X-Umn-Classification: local Received: by igdg1 with SMTP id g1so74387529igd.1 for ; Mon, 02 Nov 2015 23:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=/dgbPHL6rUDZrab1azf+B13JHTaS5kwb5O7e5R9N2MU=; b=m/wRRTz7oSNM8K0rmeHVQAlqXs/XMcmK/vy6htagz1RMhGc3bsVrPW9IjPMcre9GxR V6IR6c1fdzhAzC5v6Vil5zJ+XYCVPHfWn6mZ938rS+XVFs2E0zNVOpvH88o/WjytjTla ONNz9tRDIbNHPK7i/yzZec8UPpBN14rhMl9aA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=/dgbPHL6rUDZrab1azf+B13JHTaS5kwb5O7e5R9N2MU=; b=lpvXoZhlpMD3ZqFA8Cb+AFPoyd0khE+LDGdn9NNdK/+xa3g+4Bv+dKIeyq+eD87rHd cOG1t/hKTUhZ8cmo0rhLtyTgawdJuZTVKg8j5KCi4DH3Ylrwtd050vhrWID7RydQwGr1 si80b1V0YHchuTuHbtaLrBWMxWpGCkYsHrk5/+bu8TMn8IzYVo32AnH3udEjGDAZDafQ mGUIzTu0rqnR+weE8Y3nDpaLg1MuN7cgwAEdlHffN63t0j0KilOlo5yy3xyoTUJeUTdC BIDzy0lyeJIfIWZrstgTq9JRPiVbnUfTL/Gw1uqtEglRHbqjWV2pO1NXjH3Fhni3U0KV mGyg== X-Gm-Message-State: ALoCoQkCphkTdcu502/MCyRoE2VmVDuSo2OODvKje7aBaALCmbviPA8ORBFB8em98Y1dqOWo3c5qIZqiET5sl9RjNm1qSMO7+9DCeMy35nS2sN3bJkg2qI8MNx21OfRGYZ6fwQOE7gjf X-Received: by 10.50.122.106 with SMTP id lr10mr14139153igb.86.1446536418062; Mon, 02 Nov 2015 23:40:18 -0800 (PST) X-Received: by 10.50.122.106 with SMTP id lr10mr14139148igb.86.1446536417877; Mon, 02 Nov 2015 23:40:17 -0800 (PST) Received: from x-134-84-0-209.vpn.umn.edu (x-134-84-0-209.vpn.umn.edu. [134.84.0.209]) by smtp.gmail.com with ESMTPSA id g10sm7214736igy.22.2015.11.02.23.40.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 23:40:16 -0800 (PST) References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <563817CB.6080506@umn.edu> To: Lorenzo Colitti From: David Farmer Organization: University of Minnesota Message-ID: <563864DD.2010309@umn.edu> Date: Tue, 3 Nov 2015 01:40:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 07:40:22 -0000 On 11/2/15 22:38 , Lorenzo Colitti wrote: > David, > > that statement makes sense, but I'm worried about scope creep. The > document is focused on recommendations to network operators; if we start > adding recommendations to hosts as well, that might well change the > scope of the draft substantially, and might be the start of a process > that results in a large amount of text being added and takes substantial > time to complete. I'm sensitive to the scope creep issue. However, you are asking network operators to take all the risk and to change they way they do things. Yes, it's old IPv4 thinking and we have to find the new normal for IPv6. But, a little balance asking hosts and applications to not break the networks if the network operates open things up would be some good-faith. I'm asking for a little bit of a social contract here, basically the deal is I won't nail down all the 2x4s if you promise not to pick them up and beat me over the head with them. But, if your not even willing to tell me you won't beat me over the head with the 2x4s, why would I ever not nail them all down. > Example: adding that recommendation to the recommendations section might > result in criticism that that recommendation is not adequately > justified/motivated by the rest of the draft's text. The response to > that criticism might be to add text to the draft to motivate it, but > that text would obviously need to go through the WG, we'd have to gain > consensus on it, etc. > > Also, on the text itself: if a host is given an IPv6 prefix via DHCPv6 > PD, I don't know if it's "excessive and unjustified" for it to decide, > for example, to use a different IPv6 address for each server it talks > to. The extra load on the network might well be nil. I'm not stuck on those words, I'm just looking for something that acknowledges if networks impose no hard limit on the number of IPv6 addresses, that is not a excuse for hosts and applications to go crazy. Furthermore, I'm a little worried if I set a threshold of lets say 1000 IPv6 addresses and then quarantine a host as a network abuser, am I violating the spirit of this draft? Is 500 too low? 250? Maybe you can think of a different way to cover this. Thanks > Cheers, > Lorenzo > > On Tue, Nov 3, 2015 at 11:11 AM, David Farmer > wrote: > > I thought I brought up this issue previously, but I'd like to see > something addressing excessive use of addresses, maybe adding this > as an additional paragraph in section 8, recommendations. > > Conversely, it is RECOMMENDED that hosts and applications not > excessively consume IPv6 addresses, such as generating a new address > for every connection or with excessive frequency, for instance every > few minutes or seconds. A general-purpose host utilizing several > hundreds or thousands of IPv6 addresses seems excessive and > unjustified in most situations. This could evoke network operators > to deploy DHCPv6 simply to apply sanity limits on the number of > IPv6 addresses available per host. > > > > On 11/1/15 23:15 , Fred Baker (fred) wrote: > > In the discussion this morning, we wound up in a position that I > could not call "consensus", even "rough consensus", but per a > hum of those in the room, within shouting distance of achieving > that. Several people spoke at the mike asking for a sentence or > brief discussion to be added, or a section clarified. > > In the interest of expediency, let me ask those who spoke (and > anyone else that has an issue) to respond to this note (copying > the list) with suggested text. It might be best if this is stated as > > OLD TEXT > the text that should be replaced goes here > NEW TEXT > the text that should replace it goes here > > or > > LOCATION > identify the section the text should go into > PROPOSED TEXT > the text that should be added goes here > > I'll permit the authors to declare suggested text out of scope; > some of the discussion this morning left them commenting on > scope and scope creep. However, I do ask them to justify the > exclusion to the list, rather than just ignore the email. > > This comment period ends 15 November. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Nov 3 00:02: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 3FCEB1B2F40 for ; Tue, 3 Nov 2015 00:02:24 -0800 (PST) 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 iY5oechmyfzI for ; Tue, 3 Nov 2015 00:02:22 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 990621B2F44 for ; Tue, 3 Nov 2015 00:02:22 -0800 (PST) Received: by ykft191 with SMTP id t191so8216814ykf.0 for ; Tue, 03 Nov 2015 00:02:22 -0800 (PST) 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=EktLLjpRxQvRajT01ymLBLmEycrXZ15OmjTHbtaYpwk=; b=IX6pcxr+/1DaUZYQKlMnHFYLqvsON/BB9hAMvAl/JC39N9pep3ZKCGxLdvJvThewcl 8x/QK/z3ts4Ham3rQwOwjA+EWhDUAt5JkEtysoOLzWwdyKt+gltLfPFJrAM6aA10IXcj Za1iTVeQ++LgJ1R7Kox8V6m89SBQzcqQvLOZOH2DhaBkWiIzY5KG8kFgCX+F+ULc0NY1 KmP2Fk0Kdx0CAihBbJ7ACxB+NrxzOZhZNPTea+zGDy6O18VRgRXd06sn1qfDL7c9zZF/ hiLcV0T+U63xOsHiDi3veEHVDUb2hz4IyPB8Tz49kR23iFtP4aV+RPd4qNKI4+LjR2in COWg== 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=EktLLjpRxQvRajT01ymLBLmEycrXZ15OmjTHbtaYpwk=; b=YKIbgEKZHtc1eASTFi59dXnrZzSutOL14kmpc2/aNbcE407oUdMmJMEo2TvyB3+VDV 8ah5c8z5M5ohYDHfeO8L05tZu2Y6wJbkoEW8C0kLNYmr3zv+nQ6SEMzO3V9OFsZUYiQr UQvJubOxgtV6HA9XxLUUP0fsqkc5E6x59LfonXSsox2Vs+TENdyUgH2/YXWRUG/TZB8j qDE35NP4WOIXmZ+d+DjQ5gO5v5aePnw+ZfhguR6FSe4IXyZiRsef0hBwFgDUZSmu8e7u 2p1ypuHQ18C23Uu65Y7RolnhmoXlAIfkC7FtKWfsEbmmBIyrA9UKrAe4C+fs+j2dQbgb 7u9w== X-Gm-Message-State: ALoCoQneRCCfsVVvqPkbOZa7iI85spM1FnXF+J+CpcXbsho6tRSEJdPARl4dRiQ0TWY53yTbTapU X-Received: by 10.13.246.70 with SMTP id g67mr21591386ywf.116.1446537741812; Tue, 03 Nov 2015 00:02:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Tue, 3 Nov 2015 00:02:02 -0800 (PST) In-Reply-To: <563864DD.2010309@umn.edu> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <563817CB.6080506@umn.edu> <563864DD.2010309@umn.edu> From: Lorenzo Colitti Date: Tue, 3 Nov 2015 17:02:02 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=94eb2c0338d441c08f05239e50e3 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 03 Nov 2015 08:02:24 -0000 --94eb2c0338d441c08f05239e50e3 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 4:40 PM, David Farmer wrote: > I'm not stuck on those words, I'm just looking for something that > acknowledges if networks impose no hard limit on the number of IPv6 > addresses, that is not a excuse for hosts and applications to go crazy. > > Furthermore, I'm a little worried if I set a threshold of lets say 1000 > IPv6 addresses and then quarantine a host as a network abuser, am I > violating the spirit of this draft? Is 500 too low? 250? > I think this concern can be addressed without placing requirements on the host and thus host creep. For example, would it address your concerns if the draft said that a network can pose limits on IPv6 addresses if the device uses an unreasonable number of addresses (e.g., hundreds)? --94eb2c0338d441c08f05239e50e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 4:40 PM, David Farmer <farmer@umn.edu> wrote= :
I'm not stuck on those words, I'= ;m just looking for something that acknowledges if networks impose no hard = limit on the number of IPv6 addresses, that is not a excuse for hosts and a= pplications to go crazy.

Furthermore, I'm a little worried if I set a threshold of lets say 1000= IPv6 addresses and then quarantine a host as a network abuser, am I violat= ing the spirit of this draft? Is 500 too low? 250?
I think this concern can be addressed without placing requireme= nts on the host and thus host creep. For example, would it address your con= cerns if the draft said that a network can pose limits on IPv6 addresses if= the device uses an unreasonable number of addresses (e.g., hundreds)?
--94eb2c0338d441c08f05239e50e3-- From nobody Tue Nov 3 01:16: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 DD43B1B3096 for ; Tue, 3 Nov 2015 01:16:07 -0800 (PST) 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, 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 AMK9HVcAmY_u for ; Tue, 3 Nov 2015 01:16:06 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 157661B3098 for ; Tue, 3 Nov 2015 01:15:58 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 3 Nov 2015 03:15:55 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by iofz202 with SMTP id z202so12418087iof.2 for ; Tue, 03 Nov 2015 01:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=MoE+bN9V2OhLSE9ESrcqOFTHnqCxdO3iB4dQaLW3o/4=; b=W6BtTFYYI+8xxh2VBVykqn0yoL+gCxCYueGeL433nU2i64WM1YtokeUt5+BRqqMlnh dCQEuRR5M5a6ZfMqITgRwtoXdvqleThWoHZJQKeiEfo4lwxGOwAIjHndkuPfYuI1/PjZ acjXddHVheOZvmxKnDfLjdAywMkIK3rFT3vAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=MoE+bN9V2OhLSE9ESrcqOFTHnqCxdO3iB4dQaLW3o/4=; b=S7Ieb+NuC718CuyhXCgTNCBx+KX9xFBwG18OLHbLhI13WKZTZ+loOPlqGJy5LH9fLd HuvaTg7ULnOy1Ou48ycEejsWZoSD60+qM75aZUbNb9xY5cMCuHEvL/o9f2pFz1n2biik KHM23w1HcoLje8XsVVESMrPvILRNzkJ841JhUncQcTOtD1XEnocgVvzzS0zfJCUeGsm3 t+AY/gYYq3ulh7mTPO/Ehg2mH8U25jWxP77S5x44qrq31AyIOhy9I2QoCR2x1R5dscLj uHmJSJ4AudpFLN15r5G2DnRxkqx2LrYBC2Wr21FkT4Lcuvi/A26vHyXkQtKEOBaCqlED zoig== X-Gm-Message-State: ALoCoQnDOWd7u9FwHtP7OvcEA9G/V7eTZp+5ivqIv16dlVXWdb1zl/ChJos6S2EWghYr2ksCKTLT8jfihVOsqycfZ+YUhnswcqMSnEsK63R57uzL1tPSjfnJ46uayUrodyIvZ0m9ZKEF X-Received: by 10.107.18.163 with SMTP id 35mr27235677ios.93.1446542155481; Tue, 03 Nov 2015 01:15:55 -0800 (PST) X-Received: by 10.107.18.163 with SMTP id 35mr27235668ios.93.1446542155305; Tue, 03 Nov 2015 01:15:55 -0800 (PST) Received: from x-134-84-0-209.vpn.umn.edu (x-134-84-0-209.vpn.umn.edu. [134.84.0.209]) by smtp.gmail.com with ESMTPSA id j10sm7272838igx.13.2015.11.03.01.15.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 01:15:53 -0800 (PST) References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <563817CB.6080506@umn.edu> <563864DD.2010309@umn.edu> To: Lorenzo Colitti From: David Farmer Organization: University of Minnesota Message-ID: <56387AFB.9030308@umn.edu> Date: Tue, 3 Nov 2015 03:14:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:16:08 -0000 On 11/3/15 02:02 , Lorenzo Colitti wrote: > On Tue, Nov 3, 2015 at 4:40 PM, David Farmer > wrote: > > I'm not stuck on those words, I'm just looking for something that > acknowledges if networks impose no hard limit on the number of IPv6 > addresses, that is not a excuse for hosts and applications to go crazy. > > Furthermore, I'm a little worried if I set a threshold of lets say > 1000 IPv6 addresses and then quarantine a host as a network abuser, > am I violating the spirit of this draft? Is 500 too low? 250? > > > I think this concern can be addressed without placing requirements on > the host and thus host creep. For example, would it address your > concerns if the draft said that a network can pose limits on IPv6 > addresses if the device uses an unreasonable number of addresses (e.g., > hundreds)? Something like that will probably work. Where are you thinking of putting it? -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Nov 3 01:24: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 7D9081B30C9 for ; Tue, 3 Nov 2015 01:24:46 -0800 (PST) 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 slecAE6Ha9Ps for ; Tue, 3 Nov 2015 01:24:44 -0800 (PST) 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 A63341B30C8 for ; Tue, 3 Nov 2015 01:24:43 -0800 (PST) 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 tA39OaK1031489; Tue, 3 Nov 2015 10:24:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0030A20B1B5; Tue, 3 Nov 2015 10:30:36 +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 E8533202B85; Tue, 3 Nov 2015 10:30:35 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.225]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA39OXgW008825; Tue, 3 Nov 2015 10:24:36 +0100 To: "Templin, Fred L" , "v6ops@ietf.org" References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <56387D50.9060305@gmail.com> Date: Tue, 3 Nov 2015 18:24:32 +0900 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: <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 09:24:46 -0000 Le 03/11/2015 16:13, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Monday, November 02, 2015 6:56 PM To: v6ops@ietf.org Subject: >> Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - >> address out of the delegated prefix, on the egress - no DAD >> >> >> >> Le 03/11/2015 10:31, Templin, Fred L a écrit : >>> Bumping up one level - is it clear to everyone that it is OK to >>> assign addresses taken from a DHCPv6 delegated prefix to the >>> interface over which the prefix was received? And, that DAD is >>> not required for those addresses? >> >> This indeed new enough at least to me. >> >> I agree that if the prefix is delegated for Host with DHCP-PD then >> it has a tighter bind to that Host, tighter than a prefix >> _advertised_ to it with an RA. >> >> In that sense, certainly yes the Host may self-form and assign an >> address on its interface over which the application DHCP-PD >> received it earlier. >> >> And, since the prefix is administratively unique, it would make >> little sense for the Host to DAD that address on that interface. >> >> Moreover, it would bring some advantages for privacy. Privacy >> addresses as we know them make only the IID variable, while still >> keeping a trackable prefix (the advertised prefix). With this way >> of prefix delegation, the Host may decide more ways to obfuscate >> its identity: use sometimes the allocated prefix, other times the >> advertised prefix, in some hard-to-detect sequence. >> >> But, if a Host forms an address out of the delegated prefix and >> wants to talk to its Gateway on that interface, maybe it wants to >> send an RA to that Gateway so the Gateway forms an address out of >> the delegated prefix too. At that point DAD would be needed. > > "Host sends an RA to the Gateway" doesn't make any sense that I am > aware of. I should have said "to the link on which the Gateway is present". On a shared link, where each such Host is delegated a prefix (no prefix advertised by the RA from the gateway), these Hosts will want to reach each other directly w/o being ICMP Redirected by the Gateway. Which address should such a Host use to reach its neighbor. Alex > > Thanks - Fred > >> >> Alex >> >>> >>> Thanks - Fred >>> >>> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of >>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:* >>> Lorenzo Colitti *Cc:* v6ops@ietf.org *Subject:* Re: [v6ops] >>> draft-ietf-v6ops-host-addr-availability discussion >>> >>> Hi Lorenzo, >>> >>> Responses below in "green": >>> >>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* >>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:* >>> Fred Baker (fred); v6ops@ietf.org >>> *Subject:* Re: [v6ops] draft-ietf-v6ops-host-addr-availability >>> discussion >>> >>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L >>> > >>> wrote: >>> >>> I have one text addition suggestion and one question. On P. 7, >>> in Table 1, suggest adding a new final row as follows: >>> >>> requires DAD Yes Yes No N/A >>> >>> Meaning that multi-addresses configured by SLAAC or DHCPv6 >>> IA_NA/IA_TA must use DAD to check for duplicates on the link >>> they were obtained. In a multi-addressing environment where >>> millions of addresses are required, this could amount to a >>> substantial amount of DAD multicast traffic. On the other hand, >>> DAD is not needed for DHCPv6 PD because the network has >>> unambiguously delegated the prefix for the node's exclusive use. >>> >>> I don't think "Requires DAD: No" is correct. Even if the device >>> gets a /64 prefix entirely for its own use, it still needs to do >>> DAD with any other devices on that /64 (e.g., tethered devices, >>> VMs, etc.). >>> >>> I'm not opposed to adding a line to the table, though I don't >>> think it provides much value - if we put our mind to it, I'm sure >>> we could come up with lots of things we could add to the table >>> that aren't there at the moment. My main concern is that if we >>> add something to the table it needs to be correct. >>> >>> What I mean is "Requires DAD on the interface over which the >>> prefix was received", >>> >>> but that was too long to fit in the table. Let's call the >>> interface "A". If the node gets >>> >>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface >>> "A", then it needs >>> >>> to do DAD on interface "A" for each such address. If the node >>> gets a DHCPv6 PD >>> >>> over interface "A", however, it does not need to do DAD over >>> interface "A" at all. >>> >>> If the node assigns the delegated prefix to interface "B", then >>> you are right that >>> >>> that DAD will be required among all tethered devices, VMs, etc. >>> on interface "B". >>> >>> But, there will still be no need for DAD on interface "A". Does >>> that clarify? >>> >>> I have a question also on table 1. Under ""Unlimited" endpoints", >>> why does it say "no" for DHCPv6 PD? I think it should say "yes" >>> instead, since a prefix obtained by DHCPv6 PD can be used to >>> configure an unlimited number of addresses on the link over which >>> the prefix was received. >>> >>> The table is written from the perspective of the network >>> assigning addresses to devices that connect to it. Therefore, it >>> says "no" because if you use DHCPv6 PD you can't assign address >>> space to an unlimited number of endpoints - you are limited to >>> however many /64s you have available. >>> >>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at >>> least in theory, an "unlimited" number of addresses to assign to >>> clients. Of course, that's only true in theory. In practice, >>> there's going to be a limit due to scaling reasons. >>> >>> I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA >>> can be used >>> >>> to assign an unlimited number of addresses to interface "A". But, >>> so can DHCPv6 >>> >>> PD. When the node receives the delegated prefix (e.g., a /64), it >>> can assign as >>> >>> many unique IPv6 addresses as it likes to interface "A". And >>> again, it need not >>> >>> do DAD for any of them. >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 3 02: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 BF0401B2EA6 for ; Tue, 3 Nov 2015 02:05:27 -0800 (PST) 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 oyN0Yk6CCRH0 for ; Tue, 3 Nov 2015 02:05:25 -0800 (PST) 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 7C19A1B3146 for ; Tue, 3 Nov 2015 02:05:25 -0800 (PST) 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 tA3A5Qgq025145; Tue, 3 Nov 2015 02:05:27 -0800 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3A5PT1025131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 02:05:25 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.155]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 02:05:23 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD Thread-Index: AQHRFgcqdk6EvbJyb0KpuVefeTAGTp6KjPIA//+DtcA= Date: Tue, 3 Nov 2015 10:05:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F39C80@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> <56387D50.9060305@gmail.com> In-Reply-To: <56387D50.9060305@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] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 10:05:27 -0000 Hi Alex, > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Tuesday, November 03, 2015 1:25 AM > To: Templin, Fred L; v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion -= address out of the delegated prefix, on the egress - no DAD >=20 >=20 >=20 > Le 03/11/2015 16:13, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- From: v6ops > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu > >> Sent: Monday, November 02, 2015 6:56 PM To: v6ops@ietf.org Subject: > >> Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - > >> address out of the delegated prefix, on the egress - no DAD > >> > >> > >> > >> Le 03/11/2015 10:31, Templin, Fred L a =E9crit : > >>> Bumping up one level - is it clear to everyone that it is OK to > >>> assign addresses taken from a DHCPv6 delegated prefix to the > >>> interface over which the prefix was received? And, that DAD is > >>> not required for those addresses? > >> > >> This indeed new enough at least to me. > >> > >> I agree that if the prefix is delegated for Host with DHCP-PD then > >> it has a tighter bind to that Host, tighter than a prefix > >> _advertised_ to it with an RA. > >> > >> In that sense, certainly yes the Host may self-form and assign an > >> address on its interface over which the application DHCP-PD > >> received it earlier. > >> > >> And, since the prefix is administratively unique, it would make > >> little sense for the Host to DAD that address on that interface. > >> > >> Moreover, it would bring some advantages for privacy. Privacy > >> addresses as we know them make only the IID variable, while still > >> keeping a trackable prefix (the advertised prefix). With this way > >> of prefix delegation, the Host may decide more ways to obfuscate > >> its identity: use sometimes the allocated prefix, other times the > >> advertised prefix, in some hard-to-detect sequence. > >> > >> But, if a Host forms an address out of the delegated prefix and > >> wants to talk to its Gateway on that interface, maybe it wants to > >> send an RA to that Gateway so the Gateway forms an address out of > >> the delegated prefix too. At that point DAD would be needed. > > > > "Host sends an RA to the Gateway" doesn't make any sense that I am > > aware of. >=20 > I should have said "to the link on which the Gateway is present". >=20 > On a shared link, where each such Host is delegated a prefix (no prefix > advertised by the RA from the gateway), these Hosts will want to reach > each other directly w/o being ICMP Redirected by the Gateway. Which > address should such a Host use to reach its neighbor. Each host will initially have only a default route pointing to a router on the shared link and no on-link prefix. For host-to-host communications on the link, there would need to be a redirect. Is that bad? Thanks - Fred >=20 > Alex >=20 > > > > Thanks - Fred > > > >> > >> Alex > >> > >>> > >>> Thanks - Fred > >>> > >>> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of > >>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:* > >>> Lorenzo Colitti *Cc:* v6ops@ietf.org *Subject:* Re: [v6ops] > >>> draft-ietf-v6ops-host-addr-availability discussion > >>> > >>> Hi Lorenzo, > >>> > >>> Responses below in "green": > >>> > >>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* > >>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:* > >>> Fred Baker (fred); v6ops@ietf.org > >>> *Subject:* Re: [v6ops] draft-ietf-v6ops-host-addr-availability > >>> discussion > >>> > >>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > >>> > > >>> wrote: > >>> > >>> I have one text addition suggestion and one question. On P. 7, > >>> in Table 1, suggest adding a new final row as follows: > >>> > >>> requires DAD Yes Yes No N/A > >>> > >>> Meaning that multi-addresses configured by SLAAC or DHCPv6 > >>> IA_NA/IA_TA must use DAD to check for duplicates on the link > >>> they were obtained. In a multi-addressing environment where > >>> millions of addresses are required, this could amount to a > >>> substantial amount of DAD multicast traffic. On the other hand, > >>> DAD is not needed for DHCPv6 PD because the network has > >>> unambiguously delegated the prefix for the node's exclusive use. > >>> > >>> I don't think "Requires DAD: No" is correct. Even if the device > >>> gets a /64 prefix entirely for its own use, it still needs to do > >>> DAD with any other devices on that /64 (e.g., tethered devices, > >>> VMs, etc.). > >>> > >>> I'm not opposed to adding a line to the table, though I don't > >>> think it provides much value - if we put our mind to it, I'm sure > >>> we could come up with lots of things we could add to the table > >>> that aren't there at the moment. My main concern is that if we > >>> add something to the table it needs to be correct. > >>> > >>> What I mean is "Requires DAD on the interface over which the > >>> prefix was received", > >>> > >>> but that was too long to fit in the table. Let's call the > >>> interface "A". If the node gets > >>> > >>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface > >>> "A", then it needs > >>> > >>> to do DAD on interface "A" for each such address. If the node > >>> gets a DHCPv6 PD > >>> > >>> over interface "A", however, it does not need to do DAD over > >>> interface "A" at all. > >>> > >>> If the node assigns the delegated prefix to interface "B", then > >>> you are right that > >>> > >>> that DAD will be required among all tethered devices, VMs, etc. > >>> on interface "B". > >>> > >>> But, there will still be no need for DAD on interface "A". Does > >>> that clarify? > >>> > >>> I have a question also on table 1. Under ""Unlimited" endpoints", > >>> why does it say "no" for DHCPv6 PD? I think it should say "yes" > >>> instead, since a prefix obtained by DHCPv6 PD can be used to > >>> configure an unlimited number of addresses on the link over which > >>> the prefix was received. > >>> > >>> The table is written from the perspective of the network > >>> assigning addresses to devices that connect to it. Therefore, it > >>> says "no" because if you use DHCPv6 PD you can't assign address > >>> space to an unlimited number of endpoints - you are limited to > >>> however many /64s you have available. > >>> > >>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at > >>> least in theory, an "unlimited" number of addresses to assign to > >>> clients. Of course, that's only true in theory. In practice, > >>> there's going to be a limit due to scaling reasons. > >>> > >>> I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA > >>> can be used > >>> > >>> to assign an unlimited number of addresses to interface "A". But, > >>> so can DHCPv6 > >>> > >>> PD. When the node receives the delegated prefix (e.g., a /64), it > >>> can assign as > >>> > >>> many unique IPv6 addresses as it likes to interface "A". And > >>> again, it need not > >>> > >>> do DAD for any of them. > >>> > >>> > >>> > >>> _______________________________________________ v6ops mailing > >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Tue Nov 3 03:46: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 64AF31B3018 for ; Tue, 3 Nov 2015 03:46:19 -0800 (PST) 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 6-Y_38ytnsH5 for ; Tue, 3 Nov 2015 03:46:16 -0800 (PST) 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 728DC1B3272 for ; Tue, 3 Nov 2015 03:46:16 -0800 (PST) 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 tA3BkB1s018346; Tue, 3 Nov 2015 12:46:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40C8D20B271; Tue, 3 Nov 2015 12:52:09 +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 32A52200F25; Tue, 3 Nov 2015 12:52:09 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.81]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA3Bk6jP025401; Tue, 3 Nov 2015 12:46:09 +0100 To: "Templin, Fred L" References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> <56387D50.9060305@gmail.com> <2134F8430051B64F815C691A62D9831832F39C80@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <56389E7E.5080700@gmail.com> Date: Tue, 3 Nov 2015 20:46:06 +0900 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: <2134F8430051B64F815C691A62D9831832F39C80@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 11:46:19 -0000 Hi Fred, Le 03/11/2015 19:05, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, November 03, >> 2015 1:25 AM To: Templin, Fred L; v6ops@ietf.org Subject: Re: >> [v6ops] draft-ietf-v6ops-host-addr-availability discussion - >> address out of the delegated prefix, on the egress - no DAD >> >> >> >> Le 03/11/2015 16:13, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre >>>> Petrescu Sent: Monday, November 02, 2015 6:56 PM To: >>>> v6ops@ietf.org Subject: Re: [v6ops] >>>> draft-ietf-v6ops-host-addr-availability discussion - address >>>> out of the delegated prefix, on the egress - no DAD >>>> >>>> >>>> >>>> Le 03/11/2015 10:31, Templin, Fred L a écrit : >>>>> Bumping up one level - is it clear to everyone that it is OK >>>>> to assign addresses taken from a DHCPv6 delegated prefix to >>>>> the interface over which the prefix was received? And, that >>>>> DAD is not required for those addresses? >>>> >>>> This indeed new enough at least to me. >>>> >>>> I agree that if the prefix is delegated for Host with DHCP-PD >>>> then it has a tighter bind to that Host, tighter than a prefix >>>> _advertised_ to it with an RA. >>>> >>>> In that sense, certainly yes the Host may self-form and assign >>>> an address on its interface over which the application DHCP-PD >>>> received it earlier. >>>> >>>> And, since the prefix is administratively unique, it would >>>> make little sense for the Host to DAD that address on that >>>> interface. >>>> >>>> Moreover, it would bring some advantages for privacy. Privacy >>>> addresses as we know them make only the IID variable, while >>>> still keeping a trackable prefix (the advertised prefix). With >>>> this way of prefix delegation, the Host may decide more ways to >>>> obfuscate its identity: use sometimes the allocated prefix, >>>> other times the advertised prefix, in some hard-to-detect >>>> sequence. >>>> >>>> But, if a Host forms an address out of the delegated prefix >>>> and wants to talk to its Gateway on that interface, maybe it >>>> wants to send an RA to that Gateway so the Gateway forms an >>>> address out of the delegated prefix too. At that point DAD >>>> would be needed. >>> >>> "Host sends an RA to the Gateway" doesn't make any sense that I >>> am aware of. >> >> I should have said "to the link on which the Gateway is present". >> >> On a shared link, where each such Host is delegated a prefix (no >> prefix advertised by the RA from the gateway), these Hosts will >> want to reach each other directly w/o being ICMP Redirected by the >> Gateway. Which address should such a Host use to reach its >> neighbor. > > Each host will initially have only a default route pointing to a > router on the shared link and no on-link prefix. For host-to-host > communications on the link, there would need to be a redirect. Is > that bad? I think it can work with defroute and no onlink prefix. Whether or not is bad can be a matter of number of such redirects. Intuitively, it can be very few Redirects if a few Hosts, and it can be many Redirects if the Hosts are tethering devices; because each active address behind device would need to be be re-directed. But yes the DAD-less aspect of addresses self-formed out of DHCP-PD'ed prefixes looks good. Alex > > Thanks - Fred > >> >> Alex >> >>> >>> Thanks - Fred >>> >>>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred >>>>> >>>>> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of >>>>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM >>>>> *To:* Lorenzo Colitti *Cc:* v6ops@ietf.org *Subject:* Re: >>>>> [v6ops] draft-ietf-v6ops-host-addr-availability discussion >>>>> >>>>> Hi Lorenzo, >>>>> >>>>> Responses below in "green": >>>>> >>>>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* >>>>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L >>>>> *Cc:* Fred Baker (fred); v6ops@ietf.org >>>>> *Subject:* Re: [v6ops] >>>>> draft-ietf-v6ops-host-addr-availability discussion >>>>> >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L >>>>> >>>> > wrote: >>>>> >>>>> I have one text addition suggestion and one question. On P. >>>>> 7, in Table 1, suggest adding a new final row as follows: >>>>> >>>>> requires DAD Yes Yes No N/A >>>>> >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 >>>>> IA_NA/IA_TA must use DAD to check for duplicates on the link >>>>> they were obtained. In a multi-addressing environment where >>>>> millions of addresses are required, this could amount to a >>>>> substantial amount of DAD multicast traffic. On the other >>>>> hand, DAD is not needed for DHCPv6 PD because the network >>>>> has unambiguously delegated the prefix for the node's >>>>> exclusive use. >>>>> >>>>> I don't think "Requires DAD: No" is correct. Even if the >>>>> device gets a /64 prefix entirely for its own use, it still >>>>> needs to do DAD with any other devices on that /64 (e.g., >>>>> tethered devices, VMs, etc.). >>>>> >>>>> I'm not opposed to adding a line to the table, though I >>>>> don't think it provides much value - if we put our mind to >>>>> it, I'm sure we could come up with lots of things we could >>>>> add to the table that aren't there at the moment. My main >>>>> concern is that if we add something to the table it needs to >>>>> be correct. >>>>> >>>>> What I mean is "Requires DAD on the interface over which the >>>>> prefix was received", >>>>> >>>>> but that was too long to fit in the table. Let's call the >>>>> interface "A". If the node gets >>>>> >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface >>>>> "A", then it needs >>>>> >>>>> to do DAD on interface "A" for each such address. If the >>>>> node gets a DHCPv6 PD >>>>> >>>>> over interface "A", however, it does not need to do DAD over >>>>> interface "A" at all. >>>>> >>>>> If the node assigns the delegated prefix to interface "B", >>>>> then you are right that >>>>> >>>>> that DAD will be required among all tethered devices, VMs, >>>>> etc. on interface "B". >>>>> >>>>> But, there will still be no need for DAD on interface "A". >>>>> Does that clarify? >>>>> >>>>> I have a question also on table 1. Under ""Unlimited" >>>>> endpoints", why does it say "no" for DHCPv6 PD? I think it >>>>> should say "yes" instead, since a prefix obtained by DHCPv6 >>>>> PD can be used to configure an unlimited number of addresses >>>>> on the link over which the prefix was received. >>>>> >>>>> The table is written from the perspective of the network >>>>> assigning addresses to devices that connect to it. Therefore, >>>>> it says "no" because if you use DHCPv6 PD you can't assign >>>>> address space to an unlimited number of endpoints - you are >>>>> limited to however many /64s you have available. >>>>> >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, >>>>> at least in theory, an "unlimited" number of addresses to >>>>> assign to clients. Of course, that's only true in theory. In >>>>> practice, there's going to be a limit due to scaling >>>>> reasons. >>>>> >>>>> I don't understand this. True that SLAAC and DHCPv6 >>>>> IA_NA/IA_TA can be used >>>>> >>>>> to assign an unlimited number of addresses to interface "A". >>>>> But, so can DHCPv6 >>>>> >>>>> PD. When the node receives the delegated prefix (e.g., a >>>>> /64), it can assign as >>>>> >>>>> many unique IPv6 addresses as it likes to interface "A". And >>>>> again, it need not >>>>> >>>>> do DAD for any of them. >>>>> >>>>> >>>>> >>>>> _______________________________________________ v6ops >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > From nobody Tue Nov 3 04:09: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 022831B32AF for ; Tue, 3 Nov 2015 04:09:06 -0800 (PST) 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 R2yF0K2fFsBA for ; Tue, 3 Nov 2015 04:09:03 -0800 (PST) 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 8D6E11B32AD for ; Tue, 3 Nov 2015 04:09:03 -0800 (PST) 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 tA3C92r5024971; Tue, 3 Nov 2015 05:09:02 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3C8r8G024566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 05:08:53 -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; Tue, 3 Nov 2015 04:08:52 -0800 From: "Templin, Fred L" To: Alexandre Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD Thread-Index: AQHRFgcqdk6EvbJyb0KpuVefeTAGTp6KjPIA//+DtcCAAKPZAP//ftmw Date: Tue, 3 Nov 2015 12:08:52 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F39E9E@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@gmail.com> <2134F8430051B64F815C691A62D9831832F39A27@XCH-BLV-504.nw.nos.boeing.com> <56387D50.9060305@gmail.com> <2134F8430051B64F815C691A62D9831832F39C80@XCH-BLV-504.nw.nos.boeing.com> <56389E7E.5080700@gmail.com> In-Reply-To: <56389E7E.5080700@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: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 03 Nov 2015 12:09:06 -0000 Hi Alex, > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Tuesday, November 03, 2015 3:46 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion -= address out of the delegated prefix, on the egress - no DAD >=20 > Hi Fred, >=20 > Le 03/11/2015 19:05, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- From: Alexandre Petrescu > >> [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, November 03, > >> 2015 1:25 AM To: Templin, Fred L; v6ops@ietf.org Subject: Re: > >> [v6ops] draft-ietf-v6ops-host-addr-availability discussion - > >> address out of the delegated prefix, on the egress - no DAD > >> > >> > >> > >> Le 03/11/2015 16:13, Templin, Fred L a =E9crit : > >>> Hi Alex, > >>> > >>>> -----Original Message----- From: v6ops > >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre > >>>> Petrescu Sent: Monday, November 02, 2015 6:56 PM To: > >>>> v6ops@ietf.org Subject: Re: [v6ops] > >>>> draft-ietf-v6ops-host-addr-availability discussion - address > >>>> out of the delegated prefix, on the egress - no DAD > >>>> > >>>> > >>>> > >>>> Le 03/11/2015 10:31, Templin, Fred L a =E9crit : > >>>>> Bumping up one level - is it clear to everyone that it is OK > >>>>> to assign addresses taken from a DHCPv6 delegated prefix to > >>>>> the interface over which the prefix was received? And, that > >>>>> DAD is not required for those addresses? > >>>> > >>>> This indeed new enough at least to me. > >>>> > >>>> I agree that if the prefix is delegated for Host with DHCP-PD > >>>> then it has a tighter bind to that Host, tighter than a prefix > >>>> _advertised_ to it with an RA. > >>>> > >>>> In that sense, certainly yes the Host may self-form and assign > >>>> an address on its interface over which the application DHCP-PD > >>>> received it earlier. > >>>> > >>>> And, since the prefix is administratively unique, it would > >>>> make little sense for the Host to DAD that address on that > >>>> interface. > >>>> > >>>> Moreover, it would bring some advantages for privacy. Privacy > >>>> addresses as we know them make only the IID variable, while > >>>> still keeping a trackable prefix (the advertised prefix). With > >>>> this way of prefix delegation, the Host may decide more ways to > >>>> obfuscate its identity: use sometimes the allocated prefix, > >>>> other times the advertised prefix, in some hard-to-detect > >>>> sequence. > >>>> > >>>> But, if a Host forms an address out of the delegated prefix > >>>> and wants to talk to its Gateway on that interface, maybe it > >>>> wants to send an RA to that Gateway so the Gateway forms an > >>>> address out of the delegated prefix too. At that point DAD > >>>> would be needed. > >>> > >>> "Host sends an RA to the Gateway" doesn't make any sense that I > >>> am aware of. > >> > >> I should have said "to the link on which the Gateway is present". > >> > >> On a shared link, where each such Host is delegated a prefix (no > >> prefix advertised by the RA from the gateway), these Hosts will > >> want to reach each other directly w/o being ICMP Redirected by the > >> Gateway. Which address should such a Host use to reach its > >> neighbor. > > > > Each host will initially have only a default route pointing to a > > router on the shared link and no on-link prefix. For host-to-host > > communications on the link, there would need to be a redirect. Is > > that bad? >=20 > I think it can work with defroute and no onlink prefix. OK. > Whether or not is bad can be a matter of number of such redirects. > Intuitively, it can be very few Redirects if a few Hosts, and it can be > many Redirects if the Hosts are tethering devices; because each active > address behind device would need to be be re-directed. This is why AERO specifies a "prefix redirect" capability where the redirec= t covers not just a singleton address but the entire delegated prefix. It is currently specified for tunnels, but can also be adapted for ordinary links= . RFC6706 is where the prefix redirect was originally specified, and carries over into AERO(bis). > But yes the DAD-less aspect of addresses self-formed out of DHCP-PD'ed > prefixes looks good. OK. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred > > > >> > >> Alex > >> > >>> > >>> Thanks - Fred > >>> > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> Thanks - Fred > >>>>> > >>>>> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of > >>>>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM > >>>>> *To:* Lorenzo Colitti *Cc:* v6ops@ietf.org *Subject:* Re: > >>>>> [v6ops] draft-ietf-v6ops-host-addr-availability discussion > >>>>> > >>>>> Hi Lorenzo, > >>>>> > >>>>> Responses below in "green": > >>>>> > >>>>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* > >>>>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L > >>>>> *Cc:* Fred Baker (fred); v6ops@ietf.org > >>>>> *Subject:* Re: [v6ops] > >>>>> draft-ietf-v6ops-host-addr-availability discussion > >>>>> > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > >>>>> >>>>> > wrote: > >>>>> > >>>>> I have one text addition suggestion and one question. On P. > >>>>> 7, in Table 1, suggest adding a new final row as follows: > >>>>> > >>>>> requires DAD Yes Yes No N/A > >>>>> > >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 > >>>>> IA_NA/IA_TA must use DAD to check for duplicates on the link > >>>>> they were obtained. In a multi-addressing environment where > >>>>> millions of addresses are required, this could amount to a > >>>>> substantial amount of DAD multicast traffic. On the other > >>>>> hand, DAD is not needed for DHCPv6 PD because the network > >>>>> has unambiguously delegated the prefix for the node's > >>>>> exclusive use. > >>>>> > >>>>> I don't think "Requires DAD: No" is correct. Even if the > >>>>> device gets a /64 prefix entirely for its own use, it still > >>>>> needs to do DAD with any other devices on that /64 (e.g., > >>>>> tethered devices, VMs, etc.). > >>>>> > >>>>> I'm not opposed to adding a line to the table, though I > >>>>> don't think it provides much value - if we put our mind to > >>>>> it, I'm sure we could come up with lots of things we could > >>>>> add to the table that aren't there at the moment. My main > >>>>> concern is that if we add something to the table it needs to > >>>>> be correct. > >>>>> > >>>>> What I mean is "Requires DAD on the interface over which the > >>>>> prefix was received", > >>>>> > >>>>> but that was too long to fit in the table. Let's call the > >>>>> interface "A". If the node gets > >>>>> > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface > >>>>> "A", then it needs > >>>>> > >>>>> to do DAD on interface "A" for each such address. If the > >>>>> node gets a DHCPv6 PD > >>>>> > >>>>> over interface "A", however, it does not need to do DAD over > >>>>> interface "A" at all. > >>>>> > >>>>> If the node assigns the delegated prefix to interface "B", > >>>>> then you are right that > >>>>> > >>>>> that DAD will be required among all tethered devices, VMs, > >>>>> etc. on interface "B". > >>>>> > >>>>> But, there will still be no need for DAD on interface "A". > >>>>> Does that clarify? > >>>>> > >>>>> I have a question also on table 1. Under ""Unlimited" > >>>>> endpoints", why does it say "no" for DHCPv6 PD? I think it > >>>>> should say "yes" instead, since a prefix obtained by DHCPv6 > >>>>> PD can be used to configure an unlimited number of addresses > >>>>> on the link over which the prefix was received. > >>>>> > >>>>> The table is written from the perspective of the network > >>>>> assigning addresses to devices that connect to it. Therefore, > >>>>> it says "no" because if you use DHCPv6 PD you can't assign > >>>>> address space to an unlimited number of endpoints - you are > >>>>> limited to however many /64s you have available. > >>>>> > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, > >>>>> at least in theory, an "unlimited" number of addresses to > >>>>> assign to clients. Of course, that's only true in theory. In > >>>>> practice, there's going to be a limit due to scaling > >>>>> reasons. > >>>>> > >>>>> I don't understand this. True that SLAAC and DHCPv6 > >>>>> IA_NA/IA_TA can be used > >>>>> > >>>>> to assign an unlimited number of addresses to interface "A". > >>>>> But, so can DHCPv6 > >>>>> > >>>>> PD. When the node receives the delegated prefix (e.g., a > >>>>> /64), it can assign as > >>>>> > >>>>> many unique IPv6 addresses as it likes to interface "A". And > >>>>> again, it need not > >>>>> > >>>>> do DAD for any of them. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ v6ops > >>>>> mailing list v6ops@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>>> > >>>> > >>>> _______________________________________________ v6ops mailing > >>>> list v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > > > > From nobody Tue Nov 3 05:34: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 C909C1B3360 for ; Tue, 3 Nov 2015 05:34:38 -0800 (PST) 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 wKqELuOBiekR for ; Tue, 3 Nov 2015 05:34:37 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5E51B3381 for ; Tue, 3 Nov 2015 05:34:36 -0800 (PST) Received: from [192.168.88.235] (host226-63.122-190.riotel.com.ar [190.122.63.226] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA3DXjjO002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2015 05:33:50 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <5637EB69.1080608@umn.edu> Date: Tue, 3 Nov 2015 08:33:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03358859-8078-489E-835D-3B4D324381BE@delong.com> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 13:34:38 -0000 > On Nov 2, 2015, at 6:02 PM, David Farmer wrote: >=20 > On 11/2/15 16:48 , Brian E Carpenter wrote: >> On 03/11/2015 10:40, joel jaeggli wrote: >>> On 11/3/15 1:02 AM, Liubing (Leo) wrote: >>>> And pardon for my iteration again: this draft is NOT making any >>>> formal recommendations, but some considerations to refer if you're >>>> going to use ULAs. >>>=20 >>> Were it completely neutral with respect to advice there would be = little >>> reason for it to exist. >>=20 >>=20 >> We have this feature in IPv6. It seems a bit odd that there's nothing >> beyond the bare bones in RFC 4193 that talks about it. "Here are the >> things you need to think about" seems like useful content to me. >=20 > +1 We need a document that discussed the pluses and minuses of ULA, = there are many misconceptions about them and a lot of the world is = starting to actually deploy IPv6. ULA needs to be acknowledged as part = of the IPv6 tool box, and tell people how to use the tool. Or, we need = to find the consensus to make it go ULA a way. I strongly support making ULA go away. Owen >=20 >>> The sense that I got from the last time this was discussed, and = perhaps >>> this call is there may not be stomach to take this forward as the >>> product of the working group. >>=20 >> Well, there was when the WG adopted it. What I don't think has = anything >> like consensus is any statement that it's a good or bad choice to use >> ULAs. >>=20 >> So I'd like to see this continue, purely as an FYI document. >=20 >=20 > Yes, Please >=20 >=20 > --=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=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 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=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 3 05:37: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 092C11B3398 for ; Tue, 3 Nov 2015 05:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 LEoXe-6VlMzC for ; Tue, 3 Nov 2015 05:37:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 67B751B338E for ; Tue, 3 Nov 2015 05:37:23 -0800 (PST) Received: from [192.168.88.235] (host226-63.122-190.riotel.com.ar [190.122.63.226] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA3DbG2P002596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2015 05:37:20 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_FF6C8066-2DA6-4B5B-8882-8C26F9703BC0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Tue, 3 Nov 2015 08:37:15 -0500 Message-Id: <6A7DF8AE-4307-43E4-B9F1-282BB63F2271@delong.com> References: <5637FDD0.70300@jvknet.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 13:37:26 -0000 --Apple-Mail=_FF6C8066-2DA6-4B5B-8882-8C26F9703BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to everything Lorenzo says below. > On Nov 2, 2015, at 11:55 PM, Lorenzo Colitti = wrote: >=20 > My recollection is that we never got around to publishing this = document because we never managed to agree on what to say in the = recommendations. I think that because the working group does not = actually have consensus on what ULAs should be used for.=20 >=20 > Generalizing and handwaving a bit, I think that the major disagreement = is between: > Some proponents of ULAs are suggesting that ULAs (are being | can be | = should be) used in similar ways to RFC 1918, including using them behind = NPT66 or in the absence of global addresses, and say that the document = should list those as use cases. > A fair number of WG members are vehemently opposed to such uses, and = say that WG documents should explicitly call out such practices as = harmful. We heard a few of those members at the mike yesterday during = the discussion of the design choices draft. > For as long as that disagreement exists, it will be hard to make a = recommendation, which is likely to make it hard to get consensus on this = draft. We can go through that disagreement again, but I don't personally = think the outcome will be any different from the one we had last time = around. >=20 > I happen to be in camp #2 and would be happy to support this draft if = it said that ULA-only deployments, NPT66 and NAT66 are harmful and = should be avoided. But I'm sure a fair number of people disagree with = me. >=20 > On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee > wrote: > I see interest from Victor Kuarsingh, David Farmer, Alexandre = Petrescu, and > Brian Carpenter. Can I ask each of you to do a review of the current > document, and send comments to the mailing list? That will give the > authors > and the WG something to work from. >=20 > Following that, we can discuss whether we need additional discussion = at a > meeting, or WGLC. >=20 > Thanks, >=20 > Lee >=20 >=20 > On 11/3/15, 9:20 AM, "Victor Kuarsingh" > wrote: >=20 > >WG, > > > >My input is that we should continue this work. Given ULAs are = already > >in use, having a document which outlines those use cases is, in my = mind, > >operationally beneficial. > > > >Perhaps we should be more clear that we would not be recommending the > >use of ULAs, but keep to a unbiased document which outlines how they > >have been used (just a use case discussion). We can also include > >objective technical points as to the pros/cons related to each use = case. > > > >It was also noted in another email (based on WG v6ops discussion > >yesterday), that one such valid example was Cable Modem management = IPs > >assigned ULA based addressing. This is a valid technical use case. > > > >I am willing to help if required on this document. > > > >regards, > > > >Victor K > > > >On 2015-11-02 6:17 PM, Howard, Lee wrote: > >> This document hasn=C2=B9t had any revisions or discussion in a = while. > >> Is there anyone interested in working on it? > >> > >> If we do not hear any interest, we will abandon this draft. > >> > >> Thanks, > >> Lee > >> > >> > >> ________________________________ > >> > >> This E-mail and any of its attachments may contain Time Warner = Cable > >>proprietary information, which is privileged, confidential, or = subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is = addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action = taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and = permanently > >>delete the original and any copy of this E-mail and any printout. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops = > > >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > 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=_FF6C8066-2DA6-4B5B-8882-8C26F9703BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to everything Lorenzo says below.

On = Nov 2, 2015, at 11:55 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:

My recollection is that we never got around to = publishing this document because we never managed to agree on what to = say in the recommendations. I think that because the working group = does not actually have consensus on what ULAs should be used = for. 

Generalizing and handwaving a bit, I think that the major = disagreement is between:
  1. Some proponents of ULAs are suggesting that ULAs (are being | = can be | should be) used in similar ways to RFC 1918, including using = them behind NPT66 or in the absence of global addresses, and say that = the document should list those as use cases.
  2. A fair number of WG members are vehemently opposed to such = uses, and say that WG documents should explicitly call out such = practices as harmful. We heard a few of those members at the mike = yesterday during the discussion of the design choices draft.
For as long as that disagreement = exists, it will be hard to make a recommendation, which is likely to = make it hard to get consensus on this draft. We can go through that = disagreement again, but I don't personally think the outcome will be any = different from the one we had last time around.

I happen to be in camp = #2 and would be happy to support this draft if it said that ULA-only = deployments, NPT66 and NAT66 are harmful and should be avoided. But I'm = sure a fair number of people disagree with me.

On Tue, = Nov 3, 2015 at 9:49 AM, Howard, Lee <lee.howard@twcable.com> wrote:
I see interest from = Victor Kuarsingh, David Farmer, Alexandre Petrescu, and
Brian Carpenter. Can I ask each of you to do a review of the current
document, and send comments to the mailing list?  That will give = the
authors
and the WG something to work from.

Following that, we can discuss whether we need additional discussion at = a
meeting, or WGLC.

Thanks,

Lee


On 11/3/15, 9:20 AM, "Victor Kuarsingh" <victor@jvknet.com> = wrote:

>WG,
>
>My input is that we should continue this work.  Given ULAs are = already
>in use, having a document which outlines those use cases is, in my = mind,
>operationally beneficial.
>
>Perhaps we should be more clear that we would not be recommending = the
>use of ULAs, but keep to a unbiased document which outlines how = they
>have been used (just a use case discussion).  We can also = include
>objective technical points as to the pros/cons related to each use = case.
>
>It was also noted in another email (based on WG v6ops discussion
>yesterday), that one such valid example was Cable Modem management = IPs
>assigned ULA based addressing.  This is a valid technical use = case.
>
>I am willing to help if required on this document.
>
>regards,
>
>Victor K
>
>On 2015-11-02 6:17 PM, Howard, Lee wrote:
>> This document hasn=C2=B9t had any revisions or discussion in a = while.
>> Is there anyone interested in working on it?
>>
>> If we do not hear any interest, we will abandon this draft.
>>
>> Thanks,
>> Lee
>>
>>
>> ________________________________
>>
>> This E-mail and any of its attachments may contain Time Warner = Cable
>>proprietary information, which is privileged, confidential, or = subject
>>to copyright belonging to Time Warner Cable. This E-mail is = intended
>>solely for the use of the individual or entity to which it is = addressed.
>>If you are not the intended recipient of this E-mail, you are = hereby
>>notified that any dissemination, distribution, copying, or = action taken
>>in relation to the contents of and attachments to this E-mail = is
>>strictly prohibited and may be unlawful. If you have received = this
>>E-mail in error, please notify the sender immediately and = permanently
>>delete the original and any copy of this E-mail and any = printout.
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>


________________________________

This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout.
_______________________________________________
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

= --Apple-Mail=_FF6C8066-2DA6-4B5B-8882-8C26F9703BC0-- From nobody Tue Nov 3 05:41: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 087A41B33A6 for ; Tue, 3 Nov 2015 05:41:44 -0800 (PST) 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 VkZkF8x_Pavi for ; Tue, 3 Nov 2015 05:41:42 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450: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 0D77A1B2E93 for ; Tue, 3 Nov 2015 05:41:42 -0800 (PST) Received: by wikq8 with SMTP id q8so71838708wik.1 for ; Tue, 03 Nov 2015 05:41:40 -0800 (PST) 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=Qe9NwuqQpYoDg1MAHhqwJtxYIw2zyY1DiJZoz8PY8uk=; b=1GjYqdGgt9AZe8sSaJBQ/zcKBSXmWmapHSKemKxs2RdyN6PIK+MR3M5jkCO2R47l9U NIll/boFaaugZPbPheY0EVJJ+1Kw/m3HpjnZJMKtXsICmNeexK2EORNhZUrgcrD9O8eK SqM9yTrtv/a3iHHoqzddKrY6PlAqBCG4bCfrWx+dUn8ERw7abUPrjG2H5Cm+d6/DzzCU U22ZBkew+07bvEws7PMjspRLhkb9A0ORlUfGwMPw/fYnaxEAGTQM2LAxUQbnSNXPHop3 QDJZrY4FDGn7xXrMkg8uirmijpeXpxxZ7aeeRHVPRvuXFB11q7SHtsF9l+KhLt9PAFZH noQQ== MIME-Version: 1.0 X-Received: by 10.194.109.99 with SMTP id hr3mr32948614wjb.25.1446558100521; Tue, 03 Nov 2015 05:41:40 -0800 (PST) Received: by 10.194.174.130 with HTTP; Tue, 3 Nov 2015 05:41:40 -0800 (PST) In-Reply-To: <03358859-8078-489E-835D-3B4D324381BE@delong.com> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> Date: Tue, 3 Nov 2015 05:41:40 -0800 Message-ID: From: Ca By To: Owen DeLong Content-Type: multipart/alternative; boundary=089e010d8a6eba8da00523a30d69 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 13:41:44 -0000 --089e010d8a6eba8da00523a30d69 Content-Type: text/plain; charset=UTF-8 On Tuesday, November 3, 2015, Owen DeLong wrote: > > > On Nov 2, 2015, at 6:02 PM, David Farmer > > wrote: > > > > On 11/2/15 16:48 , Brian E Carpenter wrote: > >> On 03/11/2015 10:40, joel jaeggli wrote: > >>> On 11/3/15 1:02 AM, Liubing (Leo) wrote: > >>>> And pardon for my iteration again: this draft is NOT making any > >>>> formal recommendations, but some considerations to refer if you're > >>>> going to use ULAs. > >>> > >>> Were it completely neutral with respect to advice there would be little > >>> reason for it to exist. > >> > >> > >> We have this feature in IPv6. It seems a bit odd that there's nothing > >> beyond the bare bones in RFC 4193 that talks about it. "Here are the > >> things you need to think about" seems like useful content to me. > > > > +1 We need a document that discussed the pluses and minuses of ULA, > there are many misconceptions about them and a lot of the world is starting > to actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6 > tool box, and tell people how to use the tool. Or, we need to find the > consensus to make it go ULA a way. > > I strongly support making ULA go away. > > Owen > > > > >>> The sense that I got from the last time this was discussed, and perhaps > >>> this call is there may not be stomach to take this forward as the > >>> product of the working group. > >> > >> Well, there was when the WG adopted it. What I don't think has anything > >> like consensus is any statement that it's a good or bad choice to use > >> ULAs. > >> > >> So I'd like to see this continue, purely as an FYI document. > > > > > > Yes, Please > > > > Disagree. I doubt consensus can be reached and it is a waste to try our hand at this again. I happily use ULAs and will continue doing so. You don't like ULA? Don't use them. CB > -- > > ================================================ > > David Farmer Email: farmer@umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > > > _______________________________________________ > > 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 > --089e010d8a6eba8da00523a30d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, November 3, 2015, Owen DeLong <owen@delong.com> wrote:

> On Nov 2, 2015, at 6:02 PM, David Farmer <farmer@umn.= edu> wrote:
>
> On 11/2/15 16:48 , Brian E Carpenter wrote:
>> On 03/11/2015 10:40, joel jaeggli wrote:
>>> On 11/3/15 1:02 AM, Liubing (Leo) wrote:
>>>> And pardon for my iteration again: this draft is NOT makin= g any
>>>> formal recommendations, but some considerations to refer i= f you're
>>>> going to use ULAs.
>>>
>>> Were it completely neutral with respect to advice there would = be little
>>> reason for it to exist.
>>
>>
>> We have this feature in IPv6. It seems a bit odd that there's = nothing
>> beyond the bare bones in RFC 4193 that talks about it. "Here = are the
>> things you need to think about" seems like useful content to = me.
>
> +1 We need a document that discussed the pluses and minuses of ULA, th= ere are many misconceptions about them and a lot of the world is starting t= o actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6 to= ol box, and tell people how to use the tool.=C2=A0 Or, we need to find the = consensus to make it go ULA a way.

I strongly support making ULA go away.

Owen

>
>>> The sense that I got from the last time this was discussed, an= d perhaps
>>> this call is there may not be stomach to take this forward as = the
>>> product of the working group.
>>
>> Well, there was when the WG adopted it. What I don't think has= anything
>> like consensus is any statement that it's a good or bad choice= to use
>> ULAs.
>>
>> So I'd like to see this continue, purely as an FYI document. >
>
> Yes, Please
>
>

Disagree. =C2=A0

I doubt= consensus can be reached and it is a waste to try our hand at this again.= =C2=A0

I happily use ULAs and will continue doing = so. You don't like ULA?=C2=A0 Don't use them.=C2=A0

<= /div>
CB


> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ema= il: farmer@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029=C2=A0 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=3D=
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--089e010d8a6eba8da00523a30d69-- From nobody Tue Nov 3 05:43: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 439FD1B33B5 for ; Tue, 3 Nov 2015 05:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 MF063mddRVim for ; Tue, 3 Nov 2015 05:42:59 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 074E01B2E93 for ; Tue, 3 Nov 2015 05:42:57 -0800 (PST) Received: from [192.168.88.235] (host226-63.122-190.riotel.com.ar [190.122.63.226] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA3DgcFS003224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2015 05:42:42 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_5BB3CC43-885F-40A7-ABA4-B1726A3EF998" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Tue, 3 Nov 2015 08:42:36 -0500 Message-Id: <90689FE9-0668-45E0-859D-813F6009D8FB@delong.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> To: "Howard, Lee" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 13:43:01 -0000 --Apple-Mail=_5BB3CC43-885F-40A7-ABA4-B1726A3EF998 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Nov 3, 2015, at 1:18 AM, Howard, Lee = wrote: >=20 >=20 >=20 > From: Lorenzo Colitti > > Date: Tuesday, November 3, 2015 at 2:00 AM > To: "Liubing (Leo)" > > Cc: Lee Howard >, 'IPv6 Operations' > > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work = or abandon? >=20 >> On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) > wrote: >>> [Bing] I basically agree with this claim. But that is actually why = we changed the document=92s purpose from recommendations to = considerations, that it only discusses pros and cons of those possible = scenarios, and NOT make any formal recommendation. >>=20 >> =46rom the discussion of the deployment considerations draft in the = v6ops session yesterday, several WG members (I remember at least James = Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is = not enough to list these deployment models with their pros and cons. = Instead, these deployment models should be listed separately as = "deployment models that are considered harmful". >=20 >=20 > Trying to find a way forward with the document. . . >=20 > You specifically want to recommend against ULA plus NPT66 or NAT66, = right? > The relevant sections in the current document say (in part): >=20 > Although NPTv6 works differently from > traditional stateful NAT/NAPT (which is discouraged in > [RFC5902 ]), it = introduces similar additional complexity to > applications, which may cause applications to break. >=20 > Thus this document does not recommend the use of ULA+NPTv6. > =85 > Although NPTv6 is a mechanism that has fewer architectural > problems than a traditional stateful Network Address Translator = in > an IPv6 environment [RFC6296 = ], it still breaks end-to-end > transparency and hence in general is not recommended by the = IETF. > =85 >=20 > There=92s also a full section called, " Do Not Treat ULA Equal to = RFC1918 . =94 >=20 > And so on. It seems pretty clear. Is this language insufficiently = strong for you? What words would you use instead? >=20 > Thanks, >=20 > Lee I won=92t presume to speek for Lorenzo, but from my perspective, yes, = the language is too weak. Specifically, =93Does not recommend=94 and =93Is not recommended=94 are = too passive. We should be recommending against them rather than merely standing on the sidelines = watching the harm occur. Such as =93Thus, use of ULA+NPTv6 and/or other address translation = mechanisms is generally considered harmful and should be avoided.=94 Owen --Apple-Mail=_5BB3CC43-885F-40A7-ABA4-B1726A3EF998 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 3, 2015, at 1:18 AM, Howard, Lee <lee.howard@twcable.com> wrote:



From: Lorenzo Colitti = <lorenzo@google.com>
Date: Tuesday, = November 3, 2015 at 2:00 AM
To: "Liubing (Leo)" = <leo.liubing@huawei.com>
Cc: Lee Howard <lee.howard@twcable.com>, 'IPv6 Operations' <v6ops@ietf.org>
Subject: Re: [v6ops] = draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) = <leo.liubing@huawei.com> wrote:
[Bing] I basically agree with this claim. But that is = actually why we changed the document=92s purpose from recommendations to = considerations, that it only discusses pros and cons of those possible scenarios, and NOT = make any formal recommendation.

=46rom the discussion of the deployment considerations = draft in the v6ops session yesterday, several WG members (I remember at = least James Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed = that it is not enough to list these deployment models with their pros and cons. Instead, these deployment models should be listed = separately as "deployment models that are considered harmful".

Trying to find a way forward with the document. . .

You specifically want to recommend against ULA plus NPT66 or NAT66, = right?
The relevant sections in the current document say (in part):

	Although NPTv6 works differently =
from

         traditional stateful NAT/NAPT (which is =
discouraged in
         [RFC5902]), it introduces similar additional complexity to
         applications, which may cause applications to break.

         Thus this document does not recommend the use of =
ULA+NPTv6.
=85
	Although NPTv6 is a mechanism =
that has fewer architectural
      problems than a traditional stateful Network Address Translator in
      an IPv6 environment [RFC6296], it still breaks end-to-end
      transparency and hence in general is not recommended by the IETF.
=85

There=92s = also a full section called, "

Do Not Treat ULA Equal to RFC1918.

=94


And so on. = It seems pretty clear. Is this language insufficiently strong for you? = What words would you use instead?

Thanks,

Lee

I = won=92t presume to speek for Lorenzo, but from my perspective, yes, the = language is too weak.

Specifically, = =93Does not recommend=94 and =93Is not recommended=94 are too passive. = We should be
recommending against them rather than merely = standing on the sidelines watching the = harm
occur.

Such as =93Thus,= use of ULA+NPTv6 and/or other address translation mechanisms is = generally considered harmful and should be avoided.=94

Owen


= --Apple-Mail=_5BB3CC43-885F-40A7-ABA4-B1726A3EF998-- From nobody Tue Nov 3 07:11: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 BBCC91A0370 for ; Tue, 3 Nov 2015 07:11:53 -0800 (PST) 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, 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 MVgzV0Yh7jQc for ; Tue, 3 Nov 2015 07:11:52 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 585811A0178 for ; Tue, 3 Nov 2015 07:11:52 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 3 Nov 2015 09:11:51 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f182.google.com [209.85.213.182] #+LO+TS+TR X-Umn-Classification: local Received: by igpw7 with SMTP id w7so81857394igp.0 for ; Tue, 03 Nov 2015 07:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=L4xJ/QFS1iW0jFCTrOqrKDeSbpwdZngP7Fx4c+Wws0s=; b=ZlVZBLkZfbryVkPAcinchrBADfAm/fNvKKM0tPB1QiHabquEqO1sued4IEtNCN5cKV HL2XTyLiq9gA/TloNI9IMZA3YLWaT5uj1S0AM+mHMd5gYSfamZ+hv93GL/zzBr1YaIfA tzJrBe+Pja9lv97YPvET0fl41sMAZvPM2gykY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=L4xJ/QFS1iW0jFCTrOqrKDeSbpwdZngP7Fx4c+Wws0s=; b=FYCKfvOWlkjwNrk23drNOsx7+GAb+t19lgN7HahVK2pYMx3ItCWPdMVDYI7dy55yGM BMk4a21eW+GeDro3L7OW5WSu7hSCmbA+rv9HVSw3hOjeIS75brk3ywFpZXfXVS55l/9V 21NJAxKchQz8E5910Q7CLFUyPbEByYhi0UpbVi09flV+ZdKABimF0LaHYNob7rv4cLST x3pSjJ+zHuOG016dUHrOriHfYtsELeBQdGRvBRgQvfd2zXkbUECCP+RSSfuFV6fBycQx 06u7c+YlsDKnyFCIuoMtMNyvjQj2NhWffF/T4r3EIVOJ/YiN5Aa7GcXcJZJ5jIYt8odc QrOg== X-Gm-Message-State: ALoCoQnMhkmAib4vMXHu1xngbxcktxJWI5oWak3AhFs8XQJ1sDci4WyDXQh/J9DfpmxixysonFiFps3/yO2y7/+WL6Oj0DMy4VAPfcQKbYE1Z9QWjfo/mLgWD5pIDlIOrAQ2vhbjn4Xf X-Received: by 10.50.160.37 with SMTP id xh5mr17448208igb.6.1446563510571; Tue, 03 Nov 2015 07:11:50 -0800 (PST) X-Received: by 10.50.160.37 with SMTP id xh5mr17448187igb.6.1446563510411; Tue, 03 Nov 2015 07:11:50 -0800 (PST) Received: from x-134-84-0-104.vpn.umn.edu ([2607:ea00:103:4801::42]) by smtp.gmail.com with ESMTPSA id ie20sm7616364igb.10.2015.11.03.07.11.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 07:11:48 -0800 (PST) References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> To: Owen DeLong From: David Farmer Organization: University of Minnesota Message-ID: <5638CEB1.3060204@umn.edu> Date: Tue, 3 Nov 2015 09:11:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <03358859-8078-489E-835D-3B4D324381BE@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 15:11:53 -0000 On 11/3/15 07:33 , Owen DeLong wrote: > >> On Nov 2, 2015, at 6:02 PM, David Farmer wrote: >> >> On 11/2/15 16:48 , Brian E Carpenter wrote: >>> On 03/11/2015 10:40, joel jaeggli wrote: >>>> On 11/3/15 1:02 AM, Liubing (Leo) wrote: >>>>> And pardon for my iteration again: this draft is NOT making any >>>>> formal recommendations, but some considerations to refer if you're >>>>> going to use ULAs. >>>> >>>> Were it completely neutral with respect to advice there would be little >>>> reason for it to exist. >>> >>> >>> We have this feature in IPv6. It seems a bit odd that there's nothing >>> beyond the bare bones in RFC 4193 that talks about it. "Here are the >>> things you need to think about" seems like useful content to me. >> >> +1 We need a document that discussed the pluses and minuses of ULA, there are many misconceptions about them and a lot of the world is starting to actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6 tool box, and tell people how to use the tool. Or, we need to find the consensus to make it go ULA a way. > > I strongly support making ULA go away. Owen, If you are serious about wanting ULA to go away please help develop a consensus for that by providing real arguments supporting such a conclusion. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Nov 3 11:24: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 DBA4B1A6FA7 for ; Tue, 3 Nov 2015 11:24:47 -0800 (PST) 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 16pas_XTc2e4 for ; Tue, 3 Nov 2015 11:24:46 -0800 (PST) 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 8C0271A6F9F for ; Tue, 3 Nov 2015 11:24:46 -0800 (PST) Received: by pasz6 with SMTP id z6so26929176pas.2 for ; Tue, 03 Nov 2015 11:24:46 -0800 (PST) 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=jP7gxhVoloDjAHG38a19oo2mNCm/jdcOdCBuBAvhjfk=; b=bWjreTO1G7CareJzbEskYhyEwsdcax4WMBd2Uy1V3p3YmmYqbapkKhPCPIIkh1bKJ5 fr8olP4Sq8dIt7oUJMezyhW7MHUqFdLE85nT+n9gMV070/06tgBqn9lPpd9Y4H6HLOpR 4YaRUUN/3KyKw6TJh2zZX/oiyaW8Z9nptRchgZQjsvoPDf27OAf7mGesyQKFLODhDTwp hLytg05Wt+POvm5CPK5dw79wT91DuSVxTsv1CS95ssvuvw54qIP1loebgMVICMwYqLHD XU1Mh9e63Cdf43RlpZ/aSzV6HbgY4bBhaUbTA0oKMGUBiJGGycWJ/W56Vvd1npwdiDYD OVVg== X-Received: by 10.66.235.71 with SMTP id uk7mr34907183pac.3.1446578686131; Tue, 03 Nov 2015 11:24:46 -0800 (PST) Received: from ?IPv6:2406:e007:4a67:1:28cc:dc4c:9703:6781? ([2406:e007:4a67:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id iy1sm30844450pbb.85.2015.11.03.11.24.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 11:24:44 -0800 (PST) To: Lorenzo Colitti , "Liubing (Leo)" References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563909FE.9080404@gmail.com> Date: Wed, 4 Nov 2015 08:24:46 +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: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 19:24:48 -0000 On 03/11/2015 19:00, Lorenzo Colitti wrote: > On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) > wrote: >=20 >> [Bing] I basically agree with this claim. But that is actually why we >> changed the document=E2=80=99s purpose from recommendations to conside= rations, that >> it only discusses pros and cons of those possible scenarios, and NOT m= ake >> any formal recommendation. >> >=20 >>From the discussion of the deployment considerations draft in the v6ops= > session yesterday, several WG members (I remember at least James Woodya= tt, > Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough= to > list these deployment models with their pros and cons. Instead, these > deployment models should be listed separately as "deployment models tha= t > are considered harmful". The problem is that we had this argument before NPTv6 was published, and the distinctly rough consensus was to publish it as Experimental. There's= not much the current draft can do to push that toothpaste back in the tub= e. Equally, there's not much it can do to abolish the existing implementatio= ns of NAT66 and NPTv6. In terms of the art of the possible, it can describe in more detail the failure modes caused by ULA+NPTv6, and even perhaps explain why those failure modes are less serious that the failure modes of GUA+NAT66. I think a careful explanation of the failure modes is more useful than a bunch of SHOULD NOTs. Brian From nobody Tue Nov 3 12:42: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 BA9EB1B352E for ; Tue, 3 Nov 2015 12:42:42 -0800 (PST) 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 2qtuMGSDopda for ; Tue, 3 Nov 2015 12:42:41 -0800 (PST) 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 077CE1B3529 for ; Tue, 3 Nov 2015 12:42:40 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D352B62D2C for ; Tue, 3 Nov 2015 21:42:37 +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 9C5846081E for ; Tue, 3 Nov 2015 21:42:37 +0100 (CET) Received: (qmail 37258 invoked by uid 1007); 3 Nov 2015 21:42:37 +0100 Date: Tue, 3 Nov 2015 21:42:37 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151103204237.GJ70452@Space.Net> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03358859-8078-489E-835D-3B4D324381BE@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 20:42:42 -0000 Hi, On Tue, Nov 03, 2015 at 08:33:43AM -0500, Owen DeLong wrote: > I strongly support making ULA go away. There is no consensus for that. As prior speakers said, ULAs are useful. Gert Doering -- Operator -- 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 Tue Nov 3 13:07: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 A15BA1A8750 for ; Tue, 3 Nov 2015 13:07:34 -0800 (PST) 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 3p8NVDFUrHg9 for ; Tue, 3 Nov 2015 13:07:32 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 E06AA1A8747 for ; Tue, 3 Nov 2015 13:07:31 -0800 (PST) Received: by ykek133 with SMTP id k133so38352421yke.2 for ; Tue, 03 Nov 2015 13:07:31 -0800 (PST) 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=MbAN7ez8FnFs2sbRryQY3Ni3bXbB3HTLKAuEov16iaM=; b=ilDvNf27n8W9ZbmWnZLFte1IloPW1Dbfz1o4TaYmlqZG+gXGhSCwqfNjwmFxlZgwo3 vk/iS07zoyrxIe6J75hbRMM4UzhdKk8bF6MdPXEw3PGoG8JYkHKRN73d5EfDsBqRVSet H409li3Y6uIAMZXZOoyO/VB5IooyQc6VIgCMccUcVgnwid+ai3HmCz5/HS7OvcDTdqpI HcNtGgwOKk/PBDbJwRDqTqLcqXBR0zMqYtIOQxElYeHoa2r/yNEHmiGJjkyRIiT58V9H 9PL7PrZdoXdAvnwtoYRkDF80TGhnU9Uhbq10RD+v6bKAf84Ag2u2Xh0YIq3hRIhHNml4 TT3A== MIME-Version: 1.0 X-Received: by 10.31.56.72 with SMTP id f69mr18596230vka.27.1446584850924; Tue, 03 Nov 2015 13:07:30 -0800 (PST) Received: by 10.103.67.194 with HTTP; Tue, 3 Nov 2015 13:07:30 -0800 (PST) Received: by 10.103.67.194 with HTTP; Tue, 3 Nov 2015 13:07:30 -0800 (PST) In-Reply-To: <20151103204237.GJ70452@Space.Net> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> Date: Wed, 4 Nov 2015 08:07:30 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a11434a3a2d49ff0523a948d5 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 03 Nov 2015 21:07:34 -0000 --001a11434a3a2d49ff0523a948d5 Content-Type: text/plain; charset=UTF-8 On 4 Nov 2015 7:42 AM, "Gert Doering" wrote: > > Hi, > > On Tue, Nov 03, 2015 at 08:33:43AM -0500, Owen DeLong wrote: > > I strongly support making ULA go away. > > There is no consensus for that. As prior speakers said, ULAs are useful. > It'll also discourage IPv6 adoption if they go away. If people have to pay for IPv6 address space just to use IPv6 they'll either steal public IPv6 space to use instead, or stick with IPv4 and RFC1918s. > Gert Doering > -- Operator > -- > 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 --001a11434a3a2d49ff0523a948d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 Nov 2015 7:42 AM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Tue, Nov 03, 2015 at 08:33:43AM -0500, Owen DeLong wrote:
> > I strongly support making ULA go away.
>
> There is no consensus for that.=C2=A0 As prior speakers said, ULAs are= useful.
>

It'll also discourage IPv6 adoption if they go away.

If people have to pay for IPv6 address space just to use IPv= 6 they'll either steal public IPv6 space to use instead, or stick with = IPv4 and RFC1918s.

> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Operator
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11434a3a2d49ff0523a948d5-- From nobody Tue Nov 3 13:47: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 1D5B31B2A1F for ; Tue, 3 Nov 2015 13:47:29 -0800 (PST) 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 GcY258FxIq1V for ; Tue, 3 Nov 2015 13:47:26 -0800 (PST) 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 790031B2A22 for ; Tue, 3 Nov 2015 13:47:26 -0800 (PST) Received: by pacdm15 with SMTP id dm15so5423171pac.3 for ; Tue, 03 Nov 2015 13:47:26 -0800 (PST) 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=vf04O4XRhnp2M/w+zkeawoqXo+t2IDxryRYYAhUV3zk=; b=ncpVCXPIPtoRy3mtqqwTGv/lDy4RkkFTKE93f+/pNbupNoo9bRcgoHelQXPs2Z7AdQ PdnfFbKgCoYAfILKvdamG7HBuBQRhYmuJlwUe3ImD+idCLEeyc3qP3qHY0KQoySZL/oS IpNpcIVwhuGMmnTC5SvjYNWT/mzJn3K1CM2cutpP/08dMI0dcU+IMRCDZBGygjObqUAu uLzj8okxA53COL/M7GNrb574v4Zwz5e4tujRWC2OwzvBwtEVmRVEOt2a+2M3RgpFQihx 0R8OtAB3M7dyJQc6ZvfVnd77Nx8OxsP1zHG0XmjspIZsa4GIGehgn1RbZ5rwlf+WoUw+ l1xw== X-Received: by 10.66.190.104 with SMTP id gp8mr37226485pac.154.1446587246129; Tue, 03 Nov 2015 13:47:26 -0800 (PST) Received: from ?IPv6:2406:e007:4a67:1:28cc:dc4c:9703:6781? ([2406:e007:4a67:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rm10sm31191993pbc.96.2015.11.03.13.47.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 13:47:24 -0800 (PST) To: "Templin, Fred L" , Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56392B6D.8030703@gmail.com> Date: Wed, 4 Nov 2015 10:47:25 +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: <2134F8430051B64F815C691A62D9831832F39A09@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" Subject: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 03 Nov 2015 21:47:29 -0000 Hello Fred, On 03/11/2015 20:10, Templin, Fred L wrote: > Hi Brian, >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, November 02, 2015 6:55 PM >> To: Templin, Fred L; Lorenzo Colitti >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussio= n >> >> Hi Fred, >> On 03/11/2015 14:59, Templin, Fred L wrote: >>> Hi Brian, >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Monday, November 02, 2015 5:46 PM >>>> To: Templin, Fred L; Lorenzo Colitti >>>> Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discuss= ion >>>> >>>> On 03/11/2015 14:31, Templin, Fred L wrote: >>>>> Bumping up one level =E2=80=93 is it clear to everyone that it is O= K to assign addresses >>>>> taken from a DHCPv6 delegated prefix to the interface over which th= e prefix >>>>> was received? >>>> >>>> If it was legitimately received, I can't see why it wouldn't be OK. >>> >>> OK. When the DHCPv6 server grants a prefix delegation to the client, >>> the server is asserting that that prefix is unique and is now the sol= e >>> property of the client. So, when you say legitimately received I >>> agree and that is actually a core requirement of DHCPv6 PD. >>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the >>> routing system would become hopelessly corrupted and address >>> duplication would be the least of our worries. >>> >>>>> And, that DAD is not required for those addresses? >>>> >>>> How is that safe? What is to stop a host running SLAAC once it >>>> sees that prefix in an RA, and hitting the same IID by chance? >>>> At least you need to specify that the A bit must not be set. >>> >>> I am talking about DAD on interface "A" being the interface over >>> which the client receives the prefix delegation. No other node on >>> interface "A" may use the delegated prefix, and no router on >>> interface "A" may advertise the prefix in an RA. The prefix is the >>> sole property of the client that received the PD, so the client is >>> free to assign addresses without needing DAD. >> >> That usage of "may" might confuse some people, so let's pretend >> you used a "MUST NOT" construct instead. I could still construct >> a host stack that would ignore the issue: its logic would be >> "I sent an RS and got no RA/PIO with A=3D1; but I see traffic from >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix." >=20 > The malicious (or otherwise broken) host 'A' could configure any number= > of addresses it likes, but it would do so in a vacuum because ingress > filtering will prevent a packet with a source address from a prefix > belonging to host B from being accepted. So, node B has no reason > to fear address duplication by node A. I'm not sure how an ingress filter somewhere upstream would know that the packet came from the "wrong" host. But I don't think that's enough; a duplicate address on the LAN is already a problem in itself. > Also, what if node B in fact did do DAD and A heard it? What is to stop= > A from configuring a duplicate address and trying to use it just to mes= s > up the legitimate operation of node B? Nothing. That, I think, is why the RFCs make DAD mandatory. >=20 > What you are describing is a broken implementation that could only > be employed by a malicious host, and not something that honors > the standards.=20 I don't think it's malicious; it's just trying to get IPv6 connectivity in the face of what it sees as a broken router that isn't responding to RS. But that isn't really my point - my point is that whatever we do, it's impossible to assert that a duplicate address will never arise. > Doing DAD is not going to guard against malicious > hosts. No, but it might allow you to detect the resulting anomaly. Brian >=20 > Thanks - Fred > fred.l.templin@beoing.com=20 >=20 >>>> Come to that, a manual address might collide. >>> >>> The client itself is the only node that is permitted to assign addres= ses >>> from the delegated prefix to an interface, so there is no risk of >>> collision unless the client itself is somehow corrupt. >> >> Or another client on the same LAN gets too clever. >> >> Brian >> >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> Brian >>>> >>>>> >>>>> Thanks - Fred >>>>> >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, F= red L >>>>> Sent: Monday, November 02, 2015 5:24 PM >>>>> To: Lorenzo Colitti >>>>> Cc: v6ops@ietf.org >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discus= sion >>>>> >>>>> Hi Lorenzo, >>>>> >>>>> Responses below in =E2=80=9Cgreen=E2=80=9D: >>>>> >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com] >>>>> Sent: Monday, November 02, 2015 5:04 PM >>>>> To: Templin, Fred L >>>>> Cc: Fred Baker (fred); v6ops@ietf.org >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discus= sion >>>>> >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L > wrote: >>>>> I have one text addition suggestion and one question. On P. 7, in T= able 1, >>>>> suggest adding a new final row as follows: >>>>> >>>>> requires DAD Yes Yes = No N/A >>>>> >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA= _TA >>>>> must use DAD to check for duplicates on the link they were obtained= =2E In a >>>>> multi-addressing environment where millions of addresses are requir= ed, >>>>> this could amount to a substantial amount of DAD multicast traffic.= On the >>>>> other hand, DAD is not needed for DHCPv6 PD because the network has= >>>>> unambiguously delegated the prefix for the node's exclusive use. >>>>> >>>>> I don't think "Requires DAD: No" is correct. Even if the device get= s a /64 prefix entirely for its own use, it still needs to do DAD with >>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.). >>>>> >>>>> I'm not opposed to adding a line to the table, though I don't think= it provides much value - if we put our mind to it, I'm sure we >> could >>>> come up with lots of things we could add to the table that aren't th= ere at the moment. My main concern is that if we add >> something to >>>> the table it needs to be correct. >>>>> >>>>> What I mean is =E2=80=9CRequires DAD on the interface over which th= e prefix was received=E2=80=9D, >>>>> but that was too long to fit in the table. Let=E2=80=99s call the i= nterface =E2=80=9CA=E2=80=9D. If the node gets >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface =E2=80= =9CA=E2=80=9D, then it needs >>>>> to do DAD on interface =E2=80=9CA=E2=80=9D for each such address. I= f the node gets a DHCPv6 PD >>>>> over interface =E2=80=9CA=E2=80=9D, however, it does not need to do= DAD over interface =E2=80=9CA=E2=80=9D at all. >>>>> >>>>> If the node assigns the delegated prefix to interface =E2=80=9CB=E2= =80=9D, then you are right that >>>>> that DAD will be required among all tethered devices, VMs, etc. on = interface =E2=80=9CB=E2=80=9D. >>>>> But, there will still be no need for DAD on interface =E2=80=9CA=E2= =80=9D. Does that clarify? >>>>> >>>>> I have a question also on table 1. Under ""Unlimited" endpoints", w= hy does >>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, sin= ce a prefix >>>>> obtained by DHCPv6 PD can be used to configure an unlimited number = of >>>>> addresses on the link over which the prefix was received. >>>>> >>>>> The table is written from the perspective of the network assigning = addresses to devices that connect to it. Therefore, it says "no" >>>> because if you use DHCPv6 PD you can't assign address space to an un= limited number of endpoints - you are limited to however >> many >>>> /64s you have available. >>>>> >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at le= ast in theory, an "unlimited" number of addresses to assign to >>>> clients. Of course, that's only true in theory. In practice, there's= going to be a limit due to scaling reasons. >>>>> >>>>> I don=E2=80=99t understand this. True that SLAAC and DHCPv6 IA_NA/I= A_TA can be used >>>>> to assign an unlimited number of addresses to interface =E2=80=9CA=E2= =80=9D. But, so can DHCPv6 >>>>> PD. When the node receives the delegated prefix (e.g., a /64), it c= an assign as >>>>> many unique IPv6 addresses as it likes to interface =E2=80=9CA=E2=80= =9D. And again, it need not >>>>> do DAD for any of them. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>> >=20 From nobody Tue Nov 3 14:37: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 8F78D1B2CDD for ; Tue, 3 Nov 2015 14:37:14 -0800 (PST) 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 whw3SbBfVivr for ; Tue, 3 Nov 2015 14:37:12 -0800 (PST) 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 E910B1B2CCF for ; Tue, 3 Nov 2015 14:37:11 -0800 (PST) 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 tA3MbAHg009872; Tue, 3 Nov 2015 16:37:10 -0600 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3Mb3G2009825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 16:37:03 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.73]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 14:37:03 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSA== Date: Tue, 3 Nov 2015 22:37:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> In-Reply-To: <56392B6D.8030703@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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 03 Nov 2015 22:37:14 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDE6NDcgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQg TDsgTG9yZW56byBDb2xpdHRpDQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBEQUQg YWdhaW4gW3dhczogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5IGRpc2N1 c3Npb25dDQo+IA0KPiBIZWxsbyBGcmVkLA0KPiANCj4gT24gMDMvMTEvMjAxNSAyMDoxMCwgVGVt cGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IEhpIEJyaWFuLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDAy LCAyMDE1IDY6NTUgUE0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgTG9yZW56byBDb2xpdHRp DQo+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFm dC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KPiA+Pg0KPiA+ PiBIaSBGcmVkLA0KPiA+PiBPbiAwMy8xMS8yMDE1IDE0OjU5LCBUZW1wbGluLCBGcmVkIEwgd3Jv dGU6DQo+ID4+PiBIaSBCcmlhbiwNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbV0NCj4gPj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDAyLCAyMDE1 IDU6NDYgUE0NCj4gPj4+PiBUbzogVGVtcGxpbiwgRnJlZCBMOyBMb3JlbnpvIENvbGl0dGkNCj4g Pj4+PiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFm dC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KPiA+Pj4+DQo+ ID4+Pj4gT24gMDMvMTEvMjAxNSAxNDozMSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+Pj4+ PiBCdW1waW5nIHVwIG9uZSBsZXZlbCDigJMgaXMgaXQgY2xlYXIgdG8gZXZlcnlvbmUgdGhhdCBp dCBpcyBPSyB0byBhc3NpZ24gYWRkcmVzc2VzDQo+ID4+Pj4+IHRha2VuIGZyb20gYSBESENQdjYg ZGVsZWdhdGVkIHByZWZpeCB0byB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeA0K PiA+Pj4+PiB3YXMgcmVjZWl2ZWQ/DQo+ID4+Pj4NCj4gPj4+PiBJZiBpdCB3YXMgbGVnaXRpbWF0 ZWx5IHJlY2VpdmVkLCBJIGNhbid0IHNlZSB3aHkgaXQgd291bGRuJ3QgYmUgT0suDQo+ID4+Pg0K PiA+Pj4gT0suIFdoZW4gdGhlIERIQ1B2NiBzZXJ2ZXIgZ3JhbnRzIGEgcHJlZml4IGRlbGVnYXRp b24gdG8gdGhlIGNsaWVudCwNCj4gPj4+IHRoZSBzZXJ2ZXIgaXMgYXNzZXJ0aW5nIHRoYXQgdGhh dCBwcmVmaXggaXMgdW5pcXVlIGFuZCBpcyBub3cgdGhlIHNvbGUNCj4gPj4+IHByb3BlcnR5IG9m IHRoZSBjbGllbnQuIFNvLCB3aGVuIHlvdSBzYXkgbGVnaXRpbWF0ZWx5IHJlY2VpdmVkIEkNCj4g Pj4+IGFncmVlIGFuZCB0aGF0IGlzIGFjdHVhbGx5IGEgY29yZSByZXF1aXJlbWVudCBvZiBESENQ djYgUEQuDQo+ID4+PiBPdGhlcndpc2UsIGlmIHRoZSBESENQdjYgc2VydmVyIGdhdmUgb3V0IGR1 cGxpY2F0ZSBwcmVmaXhlcywgdGhlDQo+ID4+PiByb3V0aW5nIHN5c3RlbSB3b3VsZCBiZWNvbWUg aG9wZWxlc3NseSBjb3JydXB0ZWQgYW5kIGFkZHJlc3MNCj4gPj4+IGR1cGxpY2F0aW9uIHdvdWxk IGJlIHRoZSBsZWFzdCBvZiBvdXIgd29ycmllcy4NCj4gPj4+DQo+ID4+Pj4+IEFuZCwgdGhhdCBE QUQgaXMgbm90IHJlcXVpcmVkIGZvciB0aG9zZSBhZGRyZXNzZXM/DQo+ID4+Pj4NCj4gPj4+PiBI b3cgaXMgdGhhdCBzYWZlPyBXaGF0IGlzIHRvIHN0b3AgYSBob3N0IHJ1bm5pbmcgU0xBQUMgb25j ZSBpdA0KPiA+Pj4+IHNlZXMgdGhhdCBwcmVmaXggaW4gYW4gUkEsIGFuZCBoaXR0aW5nIHRoZSBz YW1lIElJRCBieSBjaGFuY2U/DQo+ID4+Pj4gQXQgbGVhc3QgeW91IG5lZWQgdG8gc3BlY2lmeSB0 aGF0IHRoZSBBIGJpdCBtdXN0IG5vdCBiZSBzZXQuDQo+ID4+Pg0KPiA+Pj4gSSBhbSB0YWxraW5n IGFib3V0IERBRCBvbiBpbnRlcmZhY2UgIkEiIGJlaW5nIHRoZSBpbnRlcmZhY2Ugb3Zlcg0KPiA+ Pj4gd2hpY2ggdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgcHJlZml4IGRlbGVnYXRpb24uIE5vIG90 aGVyIG5vZGUgb24NCj4gPj4+IGludGVyZmFjZSAiQSIgbWF5IHVzZSB0aGUgZGVsZWdhdGVkIHBy ZWZpeCwgYW5kIG5vIHJvdXRlciBvbg0KPiA+Pj4gaW50ZXJmYWNlICJBIiBtYXkgYWR2ZXJ0aXNl IHRoZSBwcmVmaXggaW4gYW4gUkEuIFRoZSBwcmVmaXggaXMgdGhlDQo+ID4+PiBzb2xlIHByb3Bl cnR5IG9mIHRoZSBjbGllbnQgdGhhdCByZWNlaXZlZCB0aGUgUEQsIHNvIHRoZSBjbGllbnQgaXMN Cj4gPj4+IGZyZWUgdG8gYXNzaWduIGFkZHJlc3NlcyB3aXRob3V0IG5lZWRpbmcgREFELg0KPiA+ Pg0KPiA+PiBUaGF0IHVzYWdlIG9mICJtYXkiIG1pZ2h0IGNvbmZ1c2Ugc29tZSBwZW9wbGUsIHNv IGxldCdzIHByZXRlbmQNCj4gPj4geW91IHVzZWQgYSAiTVVTVCBOT1QiIGNvbnN0cnVjdCBpbnN0 ZWFkLiBJIGNvdWxkIHN0aWxsIGNvbnN0cnVjdA0KPiA+PiBhIGhvc3Qgc3RhY2sgdGhhdCB3b3Vs ZCBpZ25vcmUgdGhlIGlzc3VlOiBpdHMgbG9naWMgd291bGQgYmUNCj4gPj4gIkkgc2VudCBhbiBS UyBhbmQgZ290IG5vIFJBL1BJTyB3aXRoIEE9MTsgYnV0IEkgc2VlIHRyYWZmaWMgZnJvbQ0KPiA+ PiBwcmVmaXggMmJhZDpkZWFkOmJlZWY6Oi82NCwgc28gSSdsbCBkbyBTTEFBQyBhbmQgREFEIGlu IHRoYXQgcHJlZml4LiINCj4gPg0KPiA+IFRoZSBtYWxpY2lvdXMgKG9yIG90aGVyd2lzZSBicm9r ZW4pIGhvc3QgJ0EnIGNvdWxkIGNvbmZpZ3VyZSBhbnkgbnVtYmVyDQo+ID4gb2YgYWRkcmVzc2Vz IGl0IGxpa2VzLCBidXQgaXQgd291bGQgZG8gc28gaW4gYSB2YWN1dW0gYmVjYXVzZSBpbmdyZXNz DQo+ID4gZmlsdGVyaW5nIHdpbGwgcHJldmVudCBhIHBhY2tldCB3aXRoIGEgc291cmNlIGFkZHJl c3MgZnJvbSBhIHByZWZpeA0KPiA+IGJlbG9uZ2luZyB0byBob3N0IEIgZnJvbSBiZWluZyBhY2Nl cHRlZC4gU28sIG5vZGUgQiBoYXMgbm8gcmVhc29uDQo+ID4gdG8gZmVhciBhZGRyZXNzIGR1cGxp Y2F0aW9uIGJ5IG5vZGUgQS4NCj4gDQo+IEknbSBub3Qgc3VyZSBob3cgYW4gaW5ncmVzcyBmaWx0 ZXIgc29tZXdoZXJlIHVwc3RyZWFtIHdvdWxkIGtub3cgdGhhdA0KPiB0aGUgcGFja2V0IGNhbWUg ZnJvbSB0aGUgIndyb25nIiBob3N0LiBCdXQgSSBkb24ndCB0aGluayB0aGF0J3MgZW5vdWdoOw0K PiBhIGR1cGxpY2F0ZSBhZGRyZXNzIG9uIHRoZSBMQU4gaXMgYWxyZWFkeSBhIHByb2JsZW0gaW4g aXRzZWxmLg0KPiANCj4gPiBBbHNvLCB3aGF0IGlmIG5vZGUgQiBpbiBmYWN0IGRpZCBkbyBEQUQg YW5kIEEgaGVhcmQgaXQ/IFdoYXQgaXMgdG8gc3RvcA0KPiA+IEEgZnJvbSBjb25maWd1cmluZyBh IGR1cGxpY2F0ZSBhZGRyZXNzIGFuZCB0cnlpbmcgdG8gdXNlIGl0IGp1c3QgdG8gbWVzcw0KPiA+ IHVwIHRoZSBsZWdpdGltYXRlIG9wZXJhdGlvbiBvZiBub2RlIEI/DQo+IA0KPiBOb3RoaW5nLiBU aGF0LCBJIHRoaW5rLCBpcyB3aHkgdGhlIFJGQ3MgbWFrZSBEQUQgbWFuZGF0b3J5Lg0KPiANCj4g Pg0KPiA+IFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIGEgYnJva2VuIGltcGxlbWVudGF0aW9u IHRoYXQgY291bGQgb25seQ0KPiA+IGJlIGVtcGxveWVkIGJ5IGEgbWFsaWNpb3VzIGhvc3QsIGFu ZCBub3Qgc29tZXRoaW5nIHRoYXQgaG9ub3JzDQo+ID4gdGhlIHN0YW5kYXJkcy4NCj4gDQo+IEkg ZG9uJ3QgdGhpbmsgaXQncyBtYWxpY2lvdXM7IGl0J3MganVzdCB0cnlpbmcgdG8gZ2V0IElQdjYg Y29ubmVjdGl2aXR5DQo+IGluIHRoZSBmYWNlIG9mIHdoYXQgaXQgc2VlcyBhcyBhIGJyb2tlbiBy b3V0ZXIgdGhhdCBpc24ndCByZXNwb25kaW5nDQo+IHRvIFJTLiBCdXQgdGhhdCBpc24ndCByZWFs bHkgbXkgcG9pbnQgLSBteSBwb2ludCBpcyB0aGF0IHdoYXRldmVyIHdlDQo+IGRvLCBpdCdzIGlt cG9zc2libGUgdG8gYXNzZXJ0IHRoYXQgYSBkdXBsaWNhdGUgYWRkcmVzcyB3aWxsIG5ldmVyIGFy aXNlLg0KPiANCj4gPiBEb2luZyBEQUQgaXMgbm90IGdvaW5nIHRvIGd1YXJkIGFnYWluc3QgbWFs aWNpb3VzDQo+ID4gaG9zdHMuDQo+IA0KPiBObywgYnV0IGl0IG1pZ2h0IGFsbG93IHlvdSB0byBk ZXRlY3QgdGhlIHJlc3VsdGluZyBhbm9tYWx5Lg0KDQoNCkFjdHVhbGx5LCB0aGUgc2ltcGxlciBh bnN3ZXIgdG8geW91ciBxdWVzdGlvbiBpcyB0aGF0IHRoZSBub2RlIHdvdWxkDQphY3QgYXMgYSBo b3N0IGludGVybmFsbHksIGJ1dCBhcHBlYXIgdG8gYmUgYSByb3V0ZXIgb24gdGhlIGxpbmsgZnJv bSBhbg0Kb3V0c2lkZSBvYnNlcnZlcidzIHBlcnNwZWN0aXZlLiBBbmQsIHJvdXRlcnMgZG8gbm90 IGRvIERBRCBmb3IgdGhlDQpzb3VyY2UgYWRkcmVzc2VzIG9mIHBhY2tldHMgdGhhdCBwYXNzIHRo cm91Z2ggdGhlbS4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K DQo+ICAgIEJyaWFuDQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1w bGluQGJlb2luZy5jb20NCj4gPg0KPiA+Pj4+IENvbWUgdG8gdGhhdCwgYSBtYW51YWwgYWRkcmVz cyBtaWdodCBjb2xsaWRlLg0KPiA+Pj4NCj4gPj4+IFRoZSBjbGllbnQgaXRzZWxmIGlzIHRoZSBv bmx5IG5vZGUgdGhhdCBpcyBwZXJtaXR0ZWQgdG8gYXNzaWduIGFkZHJlc3Nlcw0KPiA+Pj4gZnJv bSB0aGUgZGVsZWdhdGVkIHByZWZpeCB0byBhbiBpbnRlcmZhY2UsIHNvIHRoZXJlIGlzIG5vIHJp c2sgb2YNCj4gPj4+IGNvbGxpc2lvbiB1bmxlc3MgdGhlIGNsaWVudCBpdHNlbGYgaXMgc29tZWhv dyBjb3JydXB0Lg0KPiA+Pg0KPiA+PiBPciBhbm90aGVyIGNsaWVudCBvbiB0aGUgc2FtZSBMQU4g Z2V0cyB0b28gY2xldmVyLg0KPiA+Pg0KPiA+PiAgICBCcmlhbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+ IFRoYW5rcyAtIEZyZWQNCj4gPj4+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPj4+DQo+ ID4+Pj4gICAgIEJyaWFuDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzIC0gRnJlZA0K PiA+Pj4+Pg0KPiA+Pj4+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNCj4gPj4+Pj4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAwMiwgMjAxNSA1OjI0IFBNDQo+ID4+Pj4+IFRvOiBMb3JlbnpvIENvbGl0dGkNCj4g Pj4+Pj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4+Pj4+ DQo+ID4+Pj4+IEhpIExvcmVuem8sDQo+ID4+Pj4+DQo+ID4+Pj4+IFJlc3BvbnNlcyBiZWxvdyBp biDigJxncmVlbuKAnToNCj4gPj4+Pj4NCj4gPj4+Pj4gRnJvbTogTG9yZW56byBDb2xpdHRpIFtt YWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPiA+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVy IDAyLCAyMDE1IDU6MDQgUE0NCj4gPj4+Pj4gVG86IFRlbXBsaW4sIEZyZWQgTA0KPiA+Pj4+PiBD YzogRnJlZCBCYWtlciAoZnJlZCk7IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4NCj4gPj4+Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFk ZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb24NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gVHVlLCBOb3Yg MywgMjAxNSBhdCA4OjU5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCj4gPj4+Pj4g SSBoYXZlIG9uZSB0ZXh0IGFkZGl0aW9uIHN1Z2dlc3Rpb24gYW5kIG9uZSBxdWVzdGlvbi4gT24g UC4gNywgaW4gVGFibGUgMSwNCj4gPj4+Pj4gc3VnZ2VzdCBhZGRpbmcgYSBuZXcgZmluYWwgcm93 IGFzIGZvbGxvd3M6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgcmVxdWlyZXMgREFEICAgICAgICAgICAg ICAgWWVzICAgICAgICAgICAgICAgICAgWWVzICAgICAgICAgICAgICAgICAgIE5vICAgICAgICAg ICAgICAgICBOL0ENCj4gPj4+Pj4NCj4gPj4+Pj4gTWVhbmluZyB0aGF0IG11bHRpLWFkZHJlc3Nl cyBjb25maWd1cmVkIGJ5IFNMQUFDIG9yIERIQ1B2NiBJQV9OQS9JQV9UQQ0KPiA+Pj4+PiBtdXN0 IHVzZSBEQUQgdG8gY2hlY2sgZm9yIGR1cGxpY2F0ZXMgb24gdGhlIGxpbmsgdGhleSB3ZXJlIG9i dGFpbmVkLiBJbiBhDQo+ID4+Pj4+IG11bHRpLWFkZHJlc3NpbmcgZW52aXJvbm1lbnQgd2hlcmUg bWlsbGlvbnMgb2YgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCwNCj4gPj4+Pj4gdGhpcyBjb3VsZCBh bW91bnQgdG8gYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgREFEIG11bHRpY2FzdCB0cmFmZmljLiBP biB0aGUNCj4gPj4+Pj4gb3RoZXIgaGFuZCwgREFEIGlzIG5vdCBuZWVkZWQgZm9yIERIQ1B2NiBQ RCBiZWNhdXNlIHRoZSBuZXR3b3JrIGhhcw0KPiA+Pj4+PiB1bmFtYmlndW91c2x5IGRlbGVnYXRl ZCB0aGUgcHJlZml4IGZvciB0aGUgbm9kZSdzIGV4Y2x1c2l2ZSB1c2UuDQo+ID4+Pj4+DQo+ID4+ Pj4+IEkgZG9uJ3QgdGhpbmsgIlJlcXVpcmVzIERBRDogTm8iIGlzIGNvcnJlY3QuIEV2ZW4gaWYg dGhlIGRldmljZSBnZXRzIGEgLzY0IHByZWZpeCBlbnRpcmVseSBmb3IgaXRzIG93biB1c2UsIGl0 IHN0aWxsIG5lZWRzIHRvIGRvIERBRA0KPiB3aXRoDQo+ID4+Pj4gYW55IG90aGVyIGRldmljZXMg b24gdGhhdCAvNjQgKGUuZy4sIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLikuDQo+ID4+Pj4+ DQo+ID4+Pj4+IEknbSBub3Qgb3Bwb3NlZCB0byBhZGRpbmcgYSBsaW5lIHRvIHRoZSB0YWJsZSwg dGhvdWdoIEkgZG9uJ3QgdGhpbmsgaXQgcHJvdmlkZXMgbXVjaCB2YWx1ZSAtIGlmIHdlIHB1dCBv dXIgbWluZCB0byBpdCwgSSdtIHN1cmUgd2UNCj4gPj4gY291bGQNCj4gPj4+PiBjb21lIHVwIHdp dGggbG90cyBvZiB0aGluZ3Mgd2UgY291bGQgYWRkIHRvIHRoZSB0YWJsZSB0aGF0IGFyZW4ndCB0 aGVyZSBhdCB0aGUgbW9tZW50LiBNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBpZiB3ZSBhZGQNCj4g Pj4gc29tZXRoaW5nIHRvDQo+ID4+Pj4gdGhlIHRhYmxlIGl0IG5lZWRzIHRvIGJlIGNvcnJlY3Qu DQo+ID4+Pj4+DQo+ID4+Pj4+IFdoYXQgSSBtZWFuIGlzIOKAnFJlcXVpcmVzIERBRCBvbiB0aGUg aW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWTigJ0sDQo+ID4+Pj4+ IGJ1dCB0aGF0IHdhcyB0b28gbG9uZyB0byBmaXQgaW4gdGhlIHRhYmxlLiBMZXTigJlzIGNhbGwg dGhlIGludGVyZmFjZSDigJxB4oCdLiBJZiB0aGUgbm9kZSBnZXRzDQo+ID4+Pj4+IFNMQUFDIGFk ZHJlc3NlcyBvciBESENQIElBX05BL0lBX1RBIGFkZHJlc3NlcyBvdmVyIGludGVyZmFjZSDigJxB 4oCdLCB0aGVuIGl0IG5lZWRzDQo+ID4+Pj4+IHRvIGRvIERBRCBvbiBpbnRlcmZhY2Ug4oCcQeKA nSBmb3IgZWFjaCBzdWNoIGFkZHJlc3MuIElmIHRoZSBub2RlIGdldHMgYSBESENQdjYgUEQNCj4g Pj4+Pj4gb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSwgaG93ZXZlciwgaXQgZG9lcyBub3QgbmVlZCB0 byBkbyBEQUQgb3ZlciBpbnRlcmZhY2Ug4oCcQeKAnSBhdCBhbGwuDQo+ID4+Pj4+DQo+ID4+Pj4+ IElmIHRoZSBub2RlIGFzc2lnbnMgdGhlIGRlbGVnYXRlZCBwcmVmaXggdG8gaW50ZXJmYWNlIOKA nELigJ0sIHRoZW4geW91IGFyZSByaWdodCB0aGF0DQo+ID4+Pj4+IHRoYXQgREFEIHdpbGwgYmUg cmVxdWlyZWQgYW1vbmcgYWxsIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLiBvbiBpbnRlcmZh Y2Ug4oCcQuKAnS4NCj4gPj4+Pj4gQnV0LCB0aGVyZSB3aWxsIHN0aWxsIGJlIG5vIG5lZWQgZm9y IERBRCBvbiBpbnRlcmZhY2Ug4oCcQeKAnS4gRG9lcyB0aGF0IGNsYXJpZnk/DQo+ID4+Pj4+DQo+ ID4+Pj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFsc28gb24gdGFibGUgMS4gVW5kZXIgIiJVbmxpbWl0 ZWQiIGVuZHBvaW50cyIsIHdoeSBkb2VzDQo+ID4+Pj4+IGl0IHNheSAibm8iIGZvciBESENQdjYg UEQ/IEkgdGhpbmsgaXQgc2hvdWxkIHNheSAieWVzIiBpbnN0ZWFkLCBzaW5jZSBhIHByZWZpeA0K PiA+Pj4+PiBvYnRhaW5lZCBieSBESENQdjYgUEQgY2FuIGJlIHVzZWQgdG8gY29uZmlndXJlIGFu IHVubGltaXRlZCBudW1iZXIgb2YNCj4gPj4+Pj4gYWRkcmVzc2VzIG9uIHRoZSBsaW5rIG92ZXIg d2hpY2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSB0YWJs ZSBpcyB3cml0dGVuIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBuZXR3b3JrIGFzc2lnbmlu ZyBhZGRyZXNzZXMgdG8gZGV2aWNlcyB0aGF0IGNvbm5lY3QgdG8gaXQuIFRoZXJlZm9yZSwgaXQg c2F5cw0KPiAibm8iDQo+ID4+Pj4gYmVjYXVzZSBpZiB5b3UgdXNlIERIQ1B2NiBQRCB5b3UgY2Fu J3QgYXNzaWduIGFkZHJlc3Mgc3BhY2UgdG8gYW4gdW5saW1pdGVkIG51bWJlciBvZiBlbmRwb2lu dHMgLSB5b3UgYXJlIGxpbWl0ZWQgdG8gaG93ZXZlcg0KPiA+PiBtYW55DQo+ID4+Pj4gLzY0cyB5 b3UgaGF2ZSBhdmFpbGFibGUuDQo+ID4+Pj4+DQo+ID4+Pj4+IElmIHlvdSB1c2UgSUFfTkEgb3Ig U0xBQUMsIGFueSBuZXR3b3JrIHdpdGggYSAvNjQgc3VibmV0IGhhcywgYXQgbGVhc3QgaW4gdGhl b3J5LCBhbiAidW5saW1pdGVkIiBudW1iZXIgb2YgYWRkcmVzc2VzIHRvIGFzc2lnbg0KPiB0bw0K PiA+Pj4+IGNsaWVudHMuIE9mIGNvdXJzZSwgdGhhdCdzIG9ubHkgdHJ1ZSBpbiB0aGVvcnkuIElu IHByYWN0aWNlLCB0aGVyZSdzIGdvaW5nIHRvIGJlIGEgbGltaXQgZHVlIHRvIHNjYWxpbmcgcmVh c29ucy4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcy4gVHJ1ZSB0 aGF0IFNMQUFDIGFuZCBESENQdjYgSUFfTkEvSUFfVEEgY2FuIGJlIHVzZWQNCj4gPj4+Pj4gdG8g YXNzaWduIGFuIHVubGltaXRlZCBudW1iZXIgb2YgYWRkcmVzc2VzIHRvIGludGVyZmFjZSDigJxB 4oCdLiBCdXQsIHNvIGNhbiBESENQdjYNCj4gPj4+Pj4gUEQuIFdoZW4gdGhlIG5vZGUgcmVjZWl2 ZXMgdGhlIGRlbGVnYXRlZCBwcmVmaXggKGUuZy4sIGEgLzY0KSwgaXQgY2FuIGFzc2lnbiBhcw0K PiA+Pj4+PiBtYW55IHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBhcyBpdCBsaWtlcyB0byBpbnRlcmZh Y2Ug4oCcQeKAnS4gQW5kIGFnYWluLCBpdCBuZWVkIG5vdA0KPiA+Pj4+PiBkbyBEQUQgZm9yIGFu eSBvZiB0aGVtLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4gPj4+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pg0KPiA+Pj4NCj4gPg0KDQo= From nobody Tue Nov 3 15:07: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 E45EA1A883E for ; Tue, 3 Nov 2015 15:07:10 -0800 (PST) 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 4jEzYgC2Wdso for ; Tue, 3 Nov 2015 15:07:09 -0800 (PST) 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 6BA831B3587 for ; Tue, 3 Nov 2015 15:07:08 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZtkfP-0000FVC; Wed, 4 Nov 2015 00:07:03 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> In-reply-to: Your message of "Wed, 4 Nov 2015 10:47:25 +1300 ." <56392B6D.8030703@gmail.com> Date: Wed, 04 Nov 2015 00:06:53 +0100 Archived-At: Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 03 Nov 2015 23:07:11 -0000 > > Also, what if node B in fact did do DAD and A heard it? What is to stop > > A from configuring a duplicate address and trying to use it just to mess > > up the legitimate operation of node B? > > Nothing. That, I think, is why the RFCs make DAD mandatory. There are a few things something I don't understand in this discussion. Suppose we have a router with one upstream ethernet interface and a couple of downstream interfaces. The upstream interface does not have any addresses assigned other than link local. The router receives a prefix through DHCPv6 and assigns a number of /64 prefixes to the downstream interfaces. Two things should be obvious: - the router is not going to perform DAD on addresses used by hosts on its downstream interfaces - other routers on the upstream interface are not going to use ND on addresses covered by the prefix, they will use the link local address of the router instead. No we replace the router by a host. The host receives a prefix using DHCPv6 PD and starts using it. Why would the host perform DAD on addresses covered by the delegated prefix when a router would not do this? Why would routers try to perform ND on addresses covered by the prefix instead sending traffic to the link local address? There might be a problem though. Routers take part in a routing protocol. So it should be obvious to all routers how to forward traffic to a delegated prefix. When prefix delegation happens over a point-to-point link then, 'the other side' is also clearly defined. So a host could receive a prefix and it would work. In the case of ethernet, if a host receives a prefix over DHCPv6 PD, then a router connected to the host has to create a routing entry that forwards the prefix to link local address of the host (as found in the DHCPv6 requests). How is the delegating router supposed to know this? If we have special treatment for hosts, then another option would be to logically assign the addresses to the ethernet interface, perform DAD and have other nodes perform ND. But I have no idea how that should be signalled. Manual configuration on the delegating router? Consistency with CPE behavior suggests that hosts should never assign addresses to the (upstream) link and therefor not perform DAD on those addresses. From nobody Tue Nov 3 15:30: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 160D11B35F5 for ; Tue, 3 Nov 2015 15:30:49 -0800 (PST) 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 iaprWSwfzwwz for ; Tue, 3 Nov 2015 15:30:46 -0800 (PST) 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 3ABE91B35F0 for ; Tue, 3 Nov 2015 15:30:45 -0800 (PST) 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 tA3NUljP027550; Tue, 3 Nov 2015 15:30:47 -0800 Received: from XCH-BLV-202.nw.nos.boeing.com (xch-blv-202.nw.nos.boeing.com [10.57.37.69]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3NUhZN027508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 15:30:43 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.77]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 15:30:40 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6LeFYw Date: Tue, 3 Nov 2015 23:30:38 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F3A88F@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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 03 Nov 2015 23:30:49 -0000 SGkgLSBsZXQncyBsYXkgdGhpcyBvdXQgZnVsbHkgc28gd2UgY2FuIGNsZWFybHkgdW5kZXJzdGFu ZCB0aGUgREFEIGltcGxpY2F0aW9ucy4NCg0KTGV0J3Mgc2F5IGEgbm9kZSAnTicgaGFzIGEgV0FO IGludGVyZmFjZSAodGhlIG9uZSB0aGF0IGNvbm5lY3RzIHRvIHRoZSBwcm92aWRlcg0KbmV0d29y ayksIGEgbG9vcGJhY2sgaW50ZXJmYWNlLCBhbmQgYSBMQU4gaW50ZXJmYWNlICh0aGUgb25lIHRo YXQgY29ubmVjdHMgdG8NCnRldGhlcmVkIGhvc3RzL25ldHdvcmtzKS4gJ04nIHNlbmRzIGEgREhD UHY2IFBEIFNvbGljaXQgb3ZlciB0aGUgV0FOIGludGVyZmFjZQ0KYW5kIHJlY2VpdmVzIGEgcHJl Zml4IGRlbGVnYXRpb24gJ1AnLiAnTicgY2FuIG5vdyBhc3NpZ24gcHJlZml4ICdQJyB0byBlaXRo ZXIgdGhlDQpsb29wYmFjayBpbnRlcmZhY2Ugb3IgdGhlIExBTiBpbnRlcmZhY2UsIGJ1dCBNVVNU IE5PVCBhc3NpZ24gJ1AnIHRvIHRoZSBXQU4NCmludGVyZmFjZS4gTm93IGxldCdzIGxvb2sgYXQg dGhyZWUgY2FzZXM6DQoNCjEpICdOJyBhc3NpZ25zICdQJyB0byB0aGUgTEFOIGludGVyZmFjZSBh bmQgY29uZmlndXJlcyBhbiBhZGRyZXNzICdBJyBmcm9tICdQJyB0aGF0DQogICBpdCBhbHNvIGFz c2lnbnMgdG8gdGhlIExBTiBpbnRlcmZhY2UuICdOJyBNVVNUIGRvIERBRCBvbiB0aGUgTEFOIGlu dGVyZmFjZSBmb3INCiAgIGFkZHJlc3MgJ0EnLCBidXQgZG9lcyBub3QgZG8gREFEIG9uIHRoZSBX QU4gaW50ZXJmYWNlIGJlY2F1c2UgJ1AnIGlzIG5vdA0KICAgYXNzaWduZWQgdG8gdGhhdCBpbnRl cmZhY2UuDQoNCjIpICdOJyBhc3NpZ25zICdBJyBhbmQgJ1AnIHRvIHRoZSBsb29wYmFjayBpbnRl cmZhY2UuICdOJyBkb2VzIG5vdCBkbyBEQUQNCiAgICBvbiBlaXRoZXIgdGhlIExBTiBvciB0aGUg V0FOIGludGVyZmFjZS4NCg0KMykgJ04nIGFzc2lnbnMgJ1AnIHRvIHRoZSBsb29wYmFjayBpbnRl cmZhY2UgYW5kIGFzc2lnbnMgJ0EnIHRvIHRoZSBXQU4gaW50ZXJmYWNlLg0KICAgIEFnYWluLCAn TicgZG9lcyBub3QgZG8gREFEIG9uIHRoZSBXQU4gaW50ZXJmYWNlIGJlY2F1c2UgKGFnYWluKSAn UCcgaXMgbm90DQogICAgYXNzaWduZWQgdG8gdGhhdCBpbnRlcmZhY2UuDQoNCk5vdywgc3RlcHBp bmcgYmFjaywgb3V0c2lkZSBvYnNlcnZlcnMgKGUuZy4sIG5laWdoYm9ycyBvbiB0aGUgV0FOIGxp bmspDQphcmUgY29tcGxldGVseSBvYmxpdmlvdXMgdG8gdGhlIHdheSAnTicgcHJvdmlzaW9ucyAn UCcgYW5kICdBJyBpbnRlcm5hbGx5LiBBbGwgYW4NCm91dHNpZGUgb2JzZXJ2ZXIgY2FuIHRlbGwg aXMgdGhhdCAnTicgZW1hbmF0ZXMgcGFja2V0cyB3aXRoIHNvdXJjZSBhZGRyZXNzDQonQScsIGFu ZCB0aGF0ICdQJyBpcyBub3Qgb24gbGluay4gVGhlcmVmb3JlLCB0aGVyZSBpcyBubyBEQUQgcmVx dWlyZWQgb24gdGhlDQpXQU4gaW50ZXJmYWNlLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVt cGxpbkBib2VpbmcuY29tDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxp biwgRnJlZCBMDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDI6MzcgUE0NCj4g VG86IEJyaWFuIEUgQ2FycGVudGVyOyBMb3JlbnpvIENvbGl0dGkNCj4gQ2M6IHY2b3BzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIERBRCBhZ2FpbiBbd2FzOiBkcmFmdC1pZXRmLXY2 b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbl0NCj4gDQo+IEhpIEJyaWFuLA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJyaWFuIEUgQ2Fy cGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IFR1 ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDE6NDcgUE0NCj4gPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBMb3JlbnpvIENvbGl0dGkNCj4gPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBE QUQgYWdhaW4gW3dhczogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5IGRp c2N1c3Npb25dDQo+ID4NCj4gPiBIZWxsbyBGcmVkLA0KPiA+DQo+ID4gT24gMDMvMTEvMjAxNSAy MDoxMCwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+ID4gSGkgQnJpYW4sDQo+ID4gPg0KPiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogQnJpYW4gRSBDYXJw ZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+ID4gPj4gU2VudDog TW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAxNSA2OjU1IFBNDQo+ID4gPj4gVG86IFRlbXBsaW4sIEZy ZWQgTDsgTG9yZW56byBDb2xpdHRpDQo+ID4gPj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+ID4gPj4g U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmls aXR5IGRpc2N1c3Npb24NCj4gPiA+Pg0KPiA+ID4+IEhpIEZyZWQsDQo+ID4gPj4gT24gMDMvMTEv MjAxNSAxNDo1OSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+ID4+PiBIaSBCcmlhbiwNCj4g PiA+Pj4NCj4gPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4+PiBGcm9t OiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0N Cj4gPiA+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTo0NiBQTQ0KPiA+ID4+ Pj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgTG9yZW56byBDb2xpdHRpDQo+ID4gPj4+PiBDYzogdjZv cHNAaWV0Zi5vcmcNCj4gPiA+Pj4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uDQo+ID4gPj4+Pg0KPiA+ID4+Pj4g T24gMDMvMTEvMjAxNSAxNDozMSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+ID4+Pj4+IEJ1 bXBpbmcgdXAgb25lIGxldmVsIOKAkyBpcyBpdCBjbGVhciB0byBldmVyeW9uZSB0aGF0IGl0IGlz IE9LIHRvIGFzc2lnbiBhZGRyZXNzZXMNCj4gPiA+Pj4+PiB0YWtlbiBmcm9tIGEgREhDUHY2IGRl bGVnYXRlZCBwcmVmaXggdG8gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBwcmVmaXgNCj4g PiA+Pj4+PiB3YXMgcmVjZWl2ZWQ/DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSWYgaXQgd2FzIGxlZ2l0 aW1hdGVseSByZWNlaXZlZCwgSSBjYW4ndCBzZWUgd2h5IGl0IHdvdWxkbid0IGJlIE9LLg0KPiA+ ID4+Pg0KPiA+ID4+PiBPSy4gV2hlbiB0aGUgREhDUHY2IHNlcnZlciBncmFudHMgYSBwcmVmaXgg ZGVsZWdhdGlvbiB0byB0aGUgY2xpZW50LA0KPiA+ID4+PiB0aGUgc2VydmVyIGlzIGFzc2VydGlu ZyB0aGF0IHRoYXQgcHJlZml4IGlzIHVuaXF1ZSBhbmQgaXMgbm93IHRoZSBzb2xlDQo+ID4gPj4+ IHByb3BlcnR5IG9mIHRoZSBjbGllbnQuIFNvLCB3aGVuIHlvdSBzYXkgbGVnaXRpbWF0ZWx5IHJl Y2VpdmVkIEkNCj4gPiA+Pj4gYWdyZWUgYW5kIHRoYXQgaXMgYWN0dWFsbHkgYSBjb3JlIHJlcXVp cmVtZW50IG9mIERIQ1B2NiBQRC4NCj4gPiA+Pj4gT3RoZXJ3aXNlLCBpZiB0aGUgREhDUHY2IHNl cnZlciBnYXZlIG91dCBkdXBsaWNhdGUgcHJlZml4ZXMsIHRoZQ0KPiA+ID4+PiByb3V0aW5nIHN5 c3RlbSB3b3VsZCBiZWNvbWUgaG9wZWxlc3NseSBjb3JydXB0ZWQgYW5kIGFkZHJlc3MNCj4gPiA+ Pj4gZHVwbGljYXRpb24gd291bGQgYmUgdGhlIGxlYXN0IG9mIG91ciB3b3JyaWVzLg0KPiA+ID4+ Pg0KPiA+ID4+Pj4+IEFuZCwgdGhhdCBEQUQgaXMgbm90IHJlcXVpcmVkIGZvciB0aG9zZSBhZGRy ZXNzZXM/DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSG93IGlzIHRoYXQgc2FmZT8gV2hhdCBpcyB0byBz dG9wIGEgaG9zdCBydW5uaW5nIFNMQUFDIG9uY2UgaXQNCj4gPiA+Pj4+IHNlZXMgdGhhdCBwcmVm aXggaW4gYW4gUkEsIGFuZCBoaXR0aW5nIHRoZSBzYW1lIElJRCBieSBjaGFuY2U/DQo+ID4gPj4+ PiBBdCBsZWFzdCB5b3UgbmVlZCB0byBzcGVjaWZ5IHRoYXQgdGhlIEEgYml0IG11c3Qgbm90IGJl IHNldC4NCj4gPiA+Pj4NCj4gPiA+Pj4gSSBhbSB0YWxraW5nIGFib3V0IERBRCBvbiBpbnRlcmZh Y2UgIkEiIGJlaW5nIHRoZSBpbnRlcmZhY2Ugb3Zlcg0KPiA+ID4+PiB3aGljaCB0aGUgY2xpZW50 IHJlY2VpdmVzIHRoZSBwcmVmaXggZGVsZWdhdGlvbi4gTm8gb3RoZXIgbm9kZSBvbg0KPiA+ID4+ PiBpbnRlcmZhY2UgIkEiIG1heSB1c2UgdGhlIGRlbGVnYXRlZCBwcmVmaXgsIGFuZCBubyByb3V0 ZXIgb24NCj4gPiA+Pj4gaW50ZXJmYWNlICJBIiBtYXkgYWR2ZXJ0aXNlIHRoZSBwcmVmaXggaW4g YW4gUkEuIFRoZSBwcmVmaXggaXMgdGhlDQo+ID4gPj4+IHNvbGUgcHJvcGVydHkgb2YgdGhlIGNs aWVudCB0aGF0IHJlY2VpdmVkIHRoZSBQRCwgc28gdGhlIGNsaWVudCBpcw0KPiA+ID4+PiBmcmVl IHRvIGFzc2lnbiBhZGRyZXNzZXMgd2l0aG91dCBuZWVkaW5nIERBRC4NCj4gPiA+Pg0KPiA+ID4+ IFRoYXQgdXNhZ2Ugb2YgIm1heSIgbWlnaHQgY29uZnVzZSBzb21lIHBlb3BsZSwgc28gbGV0J3Mg cHJldGVuZA0KPiA+ID4+IHlvdSB1c2VkIGEgIk1VU1QgTk9UIiBjb25zdHJ1Y3QgaW5zdGVhZC4g SSBjb3VsZCBzdGlsbCBjb25zdHJ1Y3QNCj4gPiA+PiBhIGhvc3Qgc3RhY2sgdGhhdCB3b3VsZCBp Z25vcmUgdGhlIGlzc3VlOiBpdHMgbG9naWMgd291bGQgYmUNCj4gPiA+PiAiSSBzZW50IGFuIFJT IGFuZCBnb3Qgbm8gUkEvUElPIHdpdGggQT0xOyBidXQgSSBzZWUgdHJhZmZpYyBmcm9tDQo+ID4g Pj4gcHJlZml4IDJiYWQ6ZGVhZDpiZWVmOjovNjQsIHNvIEknbGwgZG8gU0xBQUMgYW5kIERBRCBp biB0aGF0IHByZWZpeC4iDQo+ID4gPg0KPiA+ID4gVGhlIG1hbGljaW91cyAob3Igb3RoZXJ3aXNl IGJyb2tlbikgaG9zdCAnQScgY291bGQgY29uZmlndXJlIGFueSBudW1iZXINCj4gPiA+IG9mIGFk ZHJlc3NlcyBpdCBsaWtlcywgYnV0IGl0IHdvdWxkIGRvIHNvIGluIGEgdmFjdXVtIGJlY2F1c2Ug aW5ncmVzcw0KPiA+ID4gZmlsdGVyaW5nIHdpbGwgcHJldmVudCBhIHBhY2tldCB3aXRoIGEgc291 cmNlIGFkZHJlc3MgZnJvbSBhIHByZWZpeA0KPiA+ID4gYmVsb25naW5nIHRvIGhvc3QgQiBmcm9t IGJlaW5nIGFjY2VwdGVkLiBTbywgbm9kZSBCIGhhcyBubyByZWFzb24NCj4gPiA+IHRvIGZlYXIg YWRkcmVzcyBkdXBsaWNhdGlvbiBieSBub2RlIEEuDQo+ID4NCj4gPiBJJ20gbm90IHN1cmUgaG93 IGFuIGluZ3Jlc3MgZmlsdGVyIHNvbWV3aGVyZSB1cHN0cmVhbSB3b3VsZCBrbm93IHRoYXQNCj4g PiB0aGUgcGFja2V0IGNhbWUgZnJvbSB0aGUgIndyb25nIiBob3N0LiBCdXQgSSBkb24ndCB0aGlu ayB0aGF0J3MgZW5vdWdoOw0KPiA+IGEgZHVwbGljYXRlIGFkZHJlc3Mgb24gdGhlIExBTiBpcyBh bHJlYWR5IGEgcHJvYmxlbSBpbiBpdHNlbGYuDQo+ID4NCj4gPiA+IEFsc28sIHdoYXQgaWYgbm9k ZSBCIGluIGZhY3QgZGlkIGRvIERBRCBhbmQgQSBoZWFyZCBpdD8gV2hhdCBpcyB0byBzdG9wDQo+ ID4gPiBBIGZyb20gY29uZmlndXJpbmcgYSBkdXBsaWNhdGUgYWRkcmVzcyBhbmQgdHJ5aW5nIHRv IHVzZSBpdCBqdXN0IHRvIG1lc3MNCj4gPiA+IHVwIHRoZSBsZWdpdGltYXRlIG9wZXJhdGlvbiBv ZiBub2RlIEI/DQo+ID4NCj4gPiBOb3RoaW5nLiBUaGF0LCBJIHRoaW5rLCBpcyB3aHkgdGhlIFJG Q3MgbWFrZSBEQUQgbWFuZGF0b3J5Lg0KPiA+DQo+ID4gPg0KPiA+ID4gV2hhdCB5b3UgYXJlIGRl c2NyaWJpbmcgaXMgYSBicm9rZW4gaW1wbGVtZW50YXRpb24gdGhhdCBjb3VsZCBvbmx5DQo+ID4g PiBiZSBlbXBsb3llZCBieSBhIG1hbGljaW91cyBob3N0LCBhbmQgbm90IHNvbWV0aGluZyB0aGF0 IGhvbm9ycw0KPiA+ID4gdGhlIHN0YW5kYXJkcy4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgaXQn cyBtYWxpY2lvdXM7IGl0J3MganVzdCB0cnlpbmcgdG8gZ2V0IElQdjYgY29ubmVjdGl2aXR5DQo+ ID4gaW4gdGhlIGZhY2Ugb2Ygd2hhdCBpdCBzZWVzIGFzIGEgYnJva2VuIHJvdXRlciB0aGF0IGlz bid0IHJlc3BvbmRpbmcNCj4gPiB0byBSUy4gQnV0IHRoYXQgaXNuJ3QgcmVhbGx5IG15IHBvaW50 IC0gbXkgcG9pbnQgaXMgdGhhdCB3aGF0ZXZlciB3ZQ0KPiA+IGRvLCBpdCdzIGltcG9zc2libGUg dG8gYXNzZXJ0IHRoYXQgYSBkdXBsaWNhdGUgYWRkcmVzcyB3aWxsIG5ldmVyIGFyaXNlLg0KPiA+ DQo+ID4gPiBEb2luZyBEQUQgaXMgbm90IGdvaW5nIHRvIGd1YXJkIGFnYWluc3QgbWFsaWNpb3Vz DQo+ID4gPiBob3N0cy4NCj4gPg0KPiA+IE5vLCBidXQgaXQgbWlnaHQgYWxsb3cgeW91IHRvIGRl dGVjdCB0aGUgcmVzdWx0aW5nIGFub21hbHkuDQo+IA0KPiANCj4gQWN0dWFsbHksIHRoZSBzaW1w bGVyIGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIGlzIHRoYXQgdGhlIG5vZGUgd291bGQNCj4gYWN0 IGFzIGEgaG9zdCBpbnRlcm5hbGx5LCBidXQgYXBwZWFyIHRvIGJlIGEgcm91dGVyIG9uIHRoZSBs aW5rIGZyb20gYW4NCj4gb3V0c2lkZSBvYnNlcnZlcidzIHBlcnNwZWN0aXZlLiBBbmQsIHJvdXRl cnMgZG8gbm90IGRvIERBRCBmb3IgdGhlDQo+IHNvdXJjZSBhZGRyZXNzZXMgb2YgcGFja2V0cyB0 aGF0IHBhc3MgdGhyb3VnaCB0aGVtLg0KPiANCj4gVGhhbmtzIC0gRnJlZA0KPiBmcmVkLmwudGVt cGxpbkBib2VpbmcuY29tDQo+IA0KPiA+ICAgIEJyaWFuDQo+ID4NCj4gPiA+DQo+ID4gPiBUaGFu a3MgLSBGcmVkDQo+ID4gPiBmcmVkLmwudGVtcGxpbkBiZW9pbmcuY29tDQo+ID4gPg0KPiA+ID4+ Pj4gQ29tZSB0byB0aGF0LCBhIG1hbnVhbCBhZGRyZXNzIG1pZ2h0IGNvbGxpZGUuDQo+ID4gPj4+ DQo+ID4gPj4+IFRoZSBjbGllbnQgaXRzZWxmIGlzIHRoZSBvbmx5IG5vZGUgdGhhdCBpcyBwZXJt aXR0ZWQgdG8gYXNzaWduIGFkZHJlc3Nlcw0KPiA+ID4+PiBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJl Zml4IHRvIGFuIGludGVyZmFjZSwgc28gdGhlcmUgaXMgbm8gcmlzayBvZg0KPiA+ID4+PiBjb2xs aXNpb24gdW5sZXNzIHRoZSBjbGllbnQgaXRzZWxmIGlzIHNvbWVob3cgY29ycnVwdC4NCj4gPiA+ Pg0KPiA+ID4+IE9yIGFub3RoZXIgY2xpZW50IG9uIHRoZSBzYW1lIExBTiBnZXRzIHRvbyBjbGV2 ZXIuDQo+ID4gPj4NCj4gPiA+PiAgICBCcmlhbg0KPiA+ID4+DQo+ID4gPj4+DQo+ID4gPj4+IFRo YW5rcyAtIEZyZWQNCj4gPiA+Pj4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+ID4+Pg0K PiA+ID4+Pj4gICAgIEJyaWFuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gVGhhbmtz IC0gRnJlZA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBMDQo+ID4gPj4+Pj4g U2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAxNSA1OjI0IFBNDQo+ID4gPj4+Pj4gVG86IExv cmVuem8gQ29saXR0aQ0KPiA+ID4+Pj4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+ID4+Pj4+IFN1 YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0 eSBkaXNjdXNzaW9uDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBIaSBMb3JlbnpvLA0KPiA+ID4+Pj4+ DQo+ID4gPj4+Pj4gUmVzcG9uc2VzIGJlbG93IGluIOKAnGdyZWVu4oCdOg0KPiA+ID4+Pj4+DQo+ ID4gPj4+Pj4gRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29t XQ0KPiA+ID4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMTUgNTowNCBQTQ0KPiA+ ID4+Pj4+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4gPiA+Pj4+PiBDYzogRnJlZCBCYWtlciAoZnJl ZCk7IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+Pj4+PiBTdWJq ZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkg ZGlzY3Vzc2lvbg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gT24gVHVlLCBOb3YgMywgMjAxNSBhdCA4 OjU5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRv OkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCj4gPiA+Pj4+PiBJIGhhdmUgb25l IHRleHQgYWRkaXRpb24gc3VnZ2VzdGlvbiBhbmQgb25lIHF1ZXN0aW9uLiBPbiBQLiA3LCBpbiBU YWJsZSAxLA0KPiA+ID4+Pj4+IHN1Z2dlc3QgYWRkaW5nIGEgbmV3IGZpbmFsIHJvdyBhcyBmb2xs b3dzOg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gICByZXF1aXJlcyBEQUQgICAgICAgICAgICAgICBZ ZXMgICAgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgICAgICAgTm8gICAgICAgICAgICAg ICAgIE4vQQ0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gTWVhbmluZyB0aGF0IG11bHRpLWFkZHJlc3Nl cyBjb25maWd1cmVkIGJ5IFNMQUFDIG9yIERIQ1B2NiBJQV9OQS9JQV9UQQ0KPiA+ID4+Pj4+IG11 c3QgdXNlIERBRCB0byBjaGVjayBmb3IgZHVwbGljYXRlcyBvbiB0aGUgbGluayB0aGV5IHdlcmUg b2J0YWluZWQuIEluIGENCj4gPiA+Pj4+PiBtdWx0aS1hZGRyZXNzaW5nIGVudmlyb25tZW50IHdo ZXJlIG1pbGxpb25zIG9mIGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQsDQo+ID4gPj4+Pj4gdGhpcyBj b3VsZCBhbW91bnQgdG8gYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgREFEIG11bHRpY2FzdCB0cmFm ZmljLiBPbiB0aGUNCj4gPiA+Pj4+PiBvdGhlciBoYW5kLCBEQUQgaXMgbm90IG5lZWRlZCBmb3Ig REhDUHY2IFBEIGJlY2F1c2UgdGhlIG5ldHdvcmsgaGFzDQo+ID4gPj4+Pj4gdW5hbWJpZ3VvdXNs eSBkZWxlZ2F0ZWQgdGhlIHByZWZpeCBmb3IgdGhlIG5vZGUncyBleGNsdXNpdmUgdXNlLg0KPiA+ ID4+Pj4+DQo+ID4gPj4+Pj4gSSBkb24ndCB0aGluayAiUmVxdWlyZXMgREFEOiBObyIgaXMgY29y cmVjdC4gRXZlbiBpZiB0aGUgZGV2aWNlIGdldHMgYSAvNjQgcHJlZml4IGVudGlyZWx5IGZvciBp dHMgb3duIHVzZSwgaXQgc3RpbGwgbmVlZHMgdG8gZG8gREFEDQo+ID4gd2l0aA0KPiA+ID4+Pj4g YW55IG90aGVyIGRldmljZXMgb24gdGhhdCAvNjQgKGUuZy4sIHRldGhlcmVkIGRldmljZXMsIFZN cywgZXRjLikuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJJ20gbm90IG9wcG9zZWQgdG8gYWRkaW5n IGEgbGluZSB0byB0aGUgdGFibGUsIHRob3VnaCBJIGRvbid0IHRoaW5rIGl0IHByb3ZpZGVzIG11 Y2ggdmFsdWUgLSBpZiB3ZSBwdXQgb3VyIG1pbmQgdG8gaXQsIEknbSBzdXJlDQo+IHdlDQo+ID4g Pj4gY291bGQNCj4gPiA+Pj4+IGNvbWUgdXAgd2l0aCBsb3RzIG9mIHRoaW5ncyB3ZSBjb3VsZCBh ZGQgdG8gdGhlIHRhYmxlIHRoYXQgYXJlbid0IHRoZXJlIGF0IHRoZSBtb21lbnQuIE15IG1haW4g Y29uY2VybiBpcyB0aGF0IGlmIHdlIGFkZA0KPiA+ID4+IHNvbWV0aGluZyB0bw0KPiA+ID4+Pj4g dGhlIHRhYmxlIGl0IG5lZWRzIHRvIGJlIGNvcnJlY3QuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBX aGF0IEkgbWVhbiBpcyDigJxSZXF1aXJlcyBEQUQgb24gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNo IHRoZSBwcmVmaXggd2FzIHJlY2VpdmVk4oCdLA0KPiA+ID4+Pj4+IGJ1dCB0aGF0IHdhcyB0b28g bG9uZyB0byBmaXQgaW4gdGhlIHRhYmxlLiBMZXTigJlzIGNhbGwgdGhlIGludGVyZmFjZSDigJxB 4oCdLiBJZiB0aGUgbm9kZSBnZXRzDQo+ID4gPj4+Pj4gU0xBQUMgYWRkcmVzc2VzIG9yIERIQ1Ag SUFfTkEvSUFfVEEgYWRkcmVzc2VzIG92ZXIgaW50ZXJmYWNlIOKAnEHigJ0sIHRoZW4gaXQgbmVl ZHMNCj4gPiA+Pj4+PiB0byBkbyBEQUQgb24gaW50ZXJmYWNlIOKAnEHigJ0gZm9yIGVhY2ggc3Vj aCBhZGRyZXNzLiBJZiB0aGUgbm9kZSBnZXRzIGEgREhDUHY2IFBEDQo+ID4gPj4+Pj4gb3ZlciBp bnRlcmZhY2Ug4oCcQeKAnSwgaG93ZXZlciwgaXQgZG9lcyBub3QgbmVlZCB0byBkbyBEQUQgb3Zl ciBpbnRlcmZhY2Ug4oCcQeKAnSBhdCBhbGwuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJZiB0aGUg bm9kZSBhc3NpZ25zIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHRvIGludGVyZmFjZSDigJxC4oCdLCB0 aGVuIHlvdSBhcmUgcmlnaHQgdGhhdA0KPiA+ID4+Pj4+IHRoYXQgREFEIHdpbGwgYmUgcmVxdWly ZWQgYW1vbmcgYWxsIHRldGhlcmVkIGRldmljZXMsIFZNcywgZXRjLiBvbiBpbnRlcmZhY2Ug4oCc QuKAnS4NCj4gPiA+Pj4+PiBCdXQsIHRoZXJlIHdpbGwgc3RpbGwgYmUgbm8gbmVlZCBmb3IgREFE IG9uIGludGVyZmFjZSDigJxB4oCdLiBEb2VzIHRoYXQgY2xhcmlmeT8NCj4gPiA+Pj4+Pg0KPiA+ ID4+Pj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFsc28gb24gdGFibGUgMS4gVW5kZXIgIiJVbmxpbWl0 ZWQiIGVuZHBvaW50cyIsIHdoeSBkb2VzDQo+ID4gPj4+Pj4gaXQgc2F5ICJubyIgZm9yIERIQ1B2 NiBQRD8gSSB0aGluayBpdCBzaG91bGQgc2F5ICJ5ZXMiIGluc3RlYWQsIHNpbmNlIGEgcHJlZml4 DQo+ID4gPj4+Pj4gb2J0YWluZWQgYnkgREhDUHY2IFBEIGNhbiBiZSB1c2VkIHRvIGNvbmZpZ3Vy ZSBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mDQo+ID4gPj4+Pj4gYWRkcmVzc2VzIG9uIHRoZSBsaW5r IG92ZXIgd2hpY2ggdGhlIHByZWZpeCB3YXMgcmVjZWl2ZWQuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+ PiBUaGUgdGFibGUgaXMgd3JpdHRlbiBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgbmV0d29y ayBhc3NpZ25pbmcgYWRkcmVzc2VzIHRvIGRldmljZXMgdGhhdCBjb25uZWN0IHRvIGl0LiBUaGVy ZWZvcmUsIGl0IHNheXMNCj4gPiAibm8iDQo+ID4gPj4+PiBiZWNhdXNlIGlmIHlvdSB1c2UgREhD UHY2IFBEIHlvdSBjYW4ndCBhc3NpZ24gYWRkcmVzcyBzcGFjZSB0byBhbiB1bmxpbWl0ZWQgbnVt YmVyIG9mIGVuZHBvaW50cyAtIHlvdSBhcmUgbGltaXRlZCB0bw0KPiBob3dldmVyDQo+ID4gPj4g bWFueQ0KPiA+ID4+Pj4gLzY0cyB5b3UgaGF2ZSBhdmFpbGFibGUuDQo+ID4gPj4+Pj4NCj4gPiA+ Pj4+PiBJZiB5b3UgdXNlIElBX05BIG9yIFNMQUFDLCBhbnkgbmV0d29yayB3aXRoIGEgLzY0IHN1 Ym5ldCBoYXMsIGF0IGxlYXN0IGluIHRoZW9yeSwgYW4gInVubGltaXRlZCIgbnVtYmVyIG9mIGFk ZHJlc3NlcyB0bw0KPiBhc3NpZ24NCj4gPiB0bw0KPiA+ID4+Pj4gY2xpZW50cy4gT2YgY291cnNl LCB0aGF0J3Mgb25seSB0cnVlIGluIHRoZW9yeS4gSW4gcHJhY3RpY2UsIHRoZXJlJ3MgZ29pbmcg dG8gYmUgYSBsaW1pdCBkdWUgdG8gc2NhbGluZyByZWFzb25zLg0KPiA+ID4+Pj4+DQo+ID4gPj4+ Pj4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcy4gVHJ1ZSB0aGF0IFNMQUFDIGFuZCBESENQdjYg SUFfTkEvSUFfVEEgY2FuIGJlIHVzZWQNCj4gPiA+Pj4+PiB0byBhc3NpZ24gYW4gdW5saW1pdGVk IG51bWJlciBvZiBhZGRyZXNzZXMgdG8gaW50ZXJmYWNlIOKAnEHigJ0uIEJ1dCwgc28gY2FuIERI Q1B2Ng0KPiA+ID4+Pj4+IFBELiBXaGVuIHRoZSBub2RlIHJlY2VpdmVzIHRoZSBkZWxlZ2F0ZWQg cHJlZml4IChlLmcuLCBhIC82NCksIGl0IGNhbiBhc3NpZ24gYXMNCj4gPiA+Pj4+PiBtYW55IHVu aXF1ZSBJUHY2IGFkZHJlc3NlcyBhcyBpdCBsaWtlcyB0byBpbnRlcmZhY2Ug4oCcQeKAnS4gQW5k IGFnYWluLCBpdCBuZWVkIG5vdA0KPiA+ID4+Pj4+IGRvIERBRCBmb3IgYW55IG9mIHRoZW0uDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+Pj4+PiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gPiA+Pj4+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+ID4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPiA+Pj4+Pg0KPiA+ID4+Pg0KPiA+ID4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Tue Nov 3 16:32: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 CD1BD1B349B for ; Tue, 3 Nov 2015 16:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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_SE=0.35, 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 dnMLakDhJg63 for ; Tue, 3 Nov 2015 16:32:37 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34891B318A for ; Tue, 3 Nov 2015 16:32:36 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 318A5A4; Wed, 4 Nov 2015 01:32:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1446597155; bh=/QjvfMT2wCiLNe/zZU3ToiOk+v5BHllOQrNj+rq/cyo=; h=Date:From:To:Subject:From; b=t8CWv5gbvY9ipcggtOGDEI3flboYBkvbMsW46XR1lidKiucPI3eOmMFvL7OE9zKim Jz1bzwBsiRiRHe5D5ZFVFNp8f0uW8y3AtwesYYaJU1P7pXwQ3R0n/qkZBJG17xuuZG 6dHuIY0fYC74P4ukcPQ6KWl/M33HcWt6IwEJZaz0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2785AA3 for ; Wed, 4 Nov 2015 01:32:35 +0100 (CET) Date: Wed, 4 Nov 2015 01:32:35 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: [v6ops] multicast over wifi and and IEEE-IETF coordination (fwd) 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, 04 Nov 2015 00:32:38 -0000 Hi, I have been involved with the coordination group between IEEE and IETF to discuss multicast over 802.11 issues that have been brought up in different forums, both regarding reliability and power usage on battery powered devices. There will be a presentation in INTAREA regarding this and initial discussion on the issue will be had there. In case there is enough interest in the issue, there might be a non-working group mailing list created for further discussion, or something else. There will also be presentation in the IEEE meeting next week on this issue, so there is awareness in both forums that the issue has been raised to try to gather all interested parties to work on this problem. The presentation tomorrow will be to present what IEEE already has done in this area (for instance GCR), and then there is a need to figure out what part of the problem to be solved where (IETF/IEEE). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 3 16: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 E42151A86EF for ; Tue, 3 Nov 2015 16:53:15 -0800 (PST) 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 EDmmljkMKNOl for ; Tue, 3 Nov 2015 16:53:14 -0800 (PST) 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 AC2531A710C for ; Tue, 3 Nov 2015 16:53:14 -0800 (PST) X-AuditID: 44571fa7-f79626d0000011ff-8c-563956f9c2a4 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 59.07.04607.9F659365; Tue, 3 Nov 2015 19:53:13 -0500 (EST) 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; Tue, 3 Nov 2015 19:53:12 -0500 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; Tue, 3 Nov 2015 19:53:12 -0500 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, 3 Nov 2015 19:53:11 -0500 From: "Brzozowski, John" To: Mikael Abrahamsson , "v6ops@ietf.org" Thread-Topic: [v6ops] multicast over wifi and and IEEE-IETF coordination Thread-Index: AQHRFpste3nJB9YXs0WvlbnF8J0t1A== Date: Wed, 4 Nov 2015 00:53:11 +0000 Message-ID: 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.253] Content-Type: text/plain; charset="utf-8" Content-ID: <4D6645067777CC49A10F02ED1CEB1705@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsXiEq4ko/szzDLM4NY6FYuXS7eyWZw+tpfZ gcljyZKfTB5/Jz1kCmCK4rJJSc3JLEst0rdL4Mp4t/AmY8EBgYp5rx+wNjB2CHQxcnBICJhI bHid3sXICWSKSVy4t56ti5GLQ0hgF5PEjv2roZw9jBLvFnWwQGUYJf7O3APlnGCUuHB8CyNI P5uAjcTrDz/BbBEBH4kHEy8ygdjCAu4Sb1q3sULEPSSWvX0NVaMncfnKHCaQM1gEVCT2z2YB CfMK2Ev8u/OKGcRmBDrp+6k1YGOYBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj/+BjRcFGtl+6j8b RNxAYuvSfSwQtqLEvg8rmEFWMQtoSqzfpQ8x0kHi3rYTbBC2osSU7ofsECcISpyc+YQFpFwI aOS8B9IQU8QlDh/ZwTqBUWoWkoNmIQydhWToLCRDZyEZuoCRdRWjXEFickpybkZ+aYmBoV5y YlJOql5yfm5yYnEJiN7ECI5i+eU7GO+9cDrEKMDBqMTDe9HNMkyINbGsuDL3EKMEB7OSCG+l H1CINyWxsiq1KD++qDQntfgQozQHi5I47+Z7v0KFBNITS1KzU1MLUotgskwcnFINjLmzOKQn beKbIHo1UkSc+Sf3brmw9/Xd/tbBfKt1FTZ85n+j9ivIyvTkr6Ph1Vtntp+5sK/j5L4FhosZ libKeTz4v/7r7H+tP9kXaXMGvFx92a/4+XunmuO8/AG5xUJ377r29V/yuNtSZXi2Om2Fwc/d jy+unRX6a/KR50VFDby3gyZ3fhJrmavEUpyRaKjFXFScCABhARR53gIAAA== Archived-At: Subject: Re: [v6ops] multicast over wifi and and IEEE-IETF coordination 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, 04 Nov 2015 00:53:16 -0000 VGhhbmtzIE1pa2FlbCwgdGhpcyBpcyB1c2VmdWwuDQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0K DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWthZWwgQWJyYWhhbXNzb24NCjxzd21pa2VA c3dtLnBwLnNlPg0KT3JnYW5pemF0aW9uOiBQZW9wbGUncyBGcm9udCBBZ2FpbnN0IFdXVw0KRGF0 ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciA0LCAyMDE1IGF0IDA5OjMyDQpUbzogdjZvcHMgPHY2b3Bz QGlldGYub3JnPg0KU3ViamVjdDogW3Y2b3BzXSBtdWx0aWNhc3Qgb3ZlciB3aWZpIGFuZCBhbmQg SUVFRS1JRVRGIGNvb3JkaW5hdGlvbiAoZndkKQ0KDQo+DQo+SGksDQo+DQo+SSBoYXZlIGJlZW4g aW52b2x2ZWQgd2l0aCB0aGUgY29vcmRpbmF0aW9uIGdyb3VwIGJldHdlZW4gSUVFRSBhbmQgSUVU RiB0bw0KPmRpc2N1c3MgbXVsdGljYXN0IG92ZXIgODAyLjExIGlzc3VlcyB0aGF0IGhhdmUgYmVl biBicm91Z2h0IHVwIGluDQo+ZGlmZmVyZW50IA0KPmZvcnVtcywgYm90aCByZWdhcmRpbmcgcmVs aWFiaWxpdHkgYW5kIHBvd2VyIHVzYWdlIG9uIGJhdHRlcnkgcG93ZXJlZA0KPmRldmljZXMuDQo+ DQo+VGhlcmUgd2lsbCBiZSBhIHByZXNlbnRhdGlvbiBpbiBJTlRBUkVBIHJlZ2FyZGluZyB0aGlz IGFuZCBpbml0aWFsDQo+ZGlzY3Vzc2lvbiANCj5vbiB0aGUgaXNzdWUgd2lsbCBiZSBoYWQgdGhl cmUuIEluIGNhc2UgdGhlcmUgaXMgZW5vdWdoIGludGVyZXN0IGluIHRoZQ0KPmlzc3VlLCANCj50 aGVyZSBtaWdodCBiZSBhIG5vbi13b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBjcmVhdGVkIGZv ciBmdXJ0aGVyDQo+ZGlzY3Vzc2lvbiwgDQo+b3Igc29tZXRoaW5nIGVsc2UuDQo+DQo+VGhlcmUg d2lsbCBhbHNvIGJlIHByZXNlbnRhdGlvbiBpbiB0aGUgSUVFRSBtZWV0aW5nIG5leHQgd2VlayBv biB0aGlzDQo+aXNzdWUsIHNvIA0KPnRoZXJlIGlzIGF3YXJlbmVzcyBpbiBib3RoIGZvcnVtcyB0 aGF0IHRoZSBpc3N1ZSBoYXMgYmVlbiByYWlzZWQgdG8gdHJ5DQo+dG8gDQo+Z2F0aGVyIGFsbCBp bnRlcmVzdGVkIHBhcnRpZXMgdG8gd29yayBvbiB0aGlzIHByb2JsZW0uDQo+DQo+VGhlIHByZXNl bnRhdGlvbiB0b21vcnJvdyB3aWxsIGJlIHRvIHByZXNlbnQgd2hhdCBJRUVFIGFscmVhZHkgaGFz IGRvbmUNCj5pbiB0aGlzIA0KPmFyZWEgKGZvciBpbnN0YW5jZSBHQ1IpLCBhbmQgdGhlbiB0aGVy ZSBpcyBhIG5lZWQgdG8gZmlndXJlIG91dCB3aGF0IHBhcnQNCj5vZiANCj50aGUgcHJvYmxlbSB0 byBiZSBzb2x2ZWQgd2hlcmUgKElFVEYvSUVFRSkuDQo+DQo+LS0gDQo+TWlrYWVsIEFicmFoYW1z c29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNlDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4N Cg0K From nobody Tue Nov 3 17:19: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 0E7BC1A8855 for ; Tue, 3 Nov 2015 17:19:20 -0800 (PST) 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 E-jf1B6QgIGY for ; Tue, 3 Nov 2015 17:19:19 -0800 (PST) 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 BB4341A884D for ; Tue, 3 Nov 2015 17:19:18 -0800 (PST) Received: by ykek133 with SMTP id k133so47630453yke.2 for ; Tue, 03 Nov 2015 17:19:18 -0800 (PST) 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=J+PyNKQRIXEKSbtjV/K7hCrdLc3Qr3jMn9WYCRpxedk=; b=do+VQppdp70LfQralt3xeKQTzrDLZDlgTEWuJshqbGrXx5UTC7emlW6Fqj6d9G1kCz YDCL/WzxFsOe8Nkv4UE7Sz0hW2R4Op+eg8kV89gSCTDjCNj3xsd6tnHeF11W0FhJk5K8 /RMZYGAVrs/XgkRA1nrZrsWQI5RfLwXO1IT0SPH9w+BYvoEMt6X34WoFx9qt7Ja41lpL Nk9vIzKrFD6ejgdD2ATF1ttT+eXCOMJXTeipB2YsiTOW/myRH+R4F0NPzdccVcVBd1N0 mbyPKlW2XHnY9bhROrXu2pgdHBDK1eEmOrNQGTkZIabp/+ENWdyijyWJugtHT2pMJz9F 9yKQ== 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=J+PyNKQRIXEKSbtjV/K7hCrdLc3Qr3jMn9WYCRpxedk=; b=MNdcOh2zFygs6MT/RDUJoxn0Xszma/Bqyh/0GYzfsmExckTaTeIw2hWgnnXWxuP+Da 86ZW/rMpliMtDSK39cxeNvfChmQ0aSGNq+m75Fii7YLwiU86x6jcMC2zo5Nk/j9L+/NA jCED7rF4WEPgApRV7iuxSHLyR5rpUcvX++zgvabyi9To4+N1j+lycCvw/CIbn1xFVAbb qEhwANUrQyewyQap5CknCw3VJey4wF5eLy1McJL95xGnJBUdt0uhRxLWCKGh+ukiY3pC IAie+pOzQS/cH0imbsb7w5nqknxz+wAkh9/C06L/gi+hVV8WavrHyJ37YZNjEZMTKnOK IwDQ== X-Gm-Message-State: ALoCoQlg/Xc2gV5oHuN+J4JywN1AA6nqrrT6kf8uMzbxLn6MM1Py6hBZjszh5n1+PNuHZjobgWOT X-Received: by 10.129.44.3 with SMTP id s3mr23066798yws.141.1446599957915; Tue, 03 Nov 2015 17:19:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Tue, 3 Nov 2015 17:18:58 -0800 (PST) In-Reply-To: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> From: Lorenzo Colitti Date: Wed, 4 Nov 2015 10:18:58 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a114278dea021be0523accc51 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 01:19:20 -0000 --001a114278dea021be0523accc51 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith wrote: > It'll also discourage IPv6 adoption if they go away. > > If people have to pay for IPv6 address space just to use IPv6 they'll > either steal public IPv6 space to use instead, or stick with IPv4 and > RFC1918s. > I don't think that's a good argument. I think it's more important to preserve the architecture and end-to-end than to rush "IPv6" adoption by deploying it the wrong way. If there are reasons we can't use global addresses everywhere (e.g., the inability to multihome), then we need to fix those, and I'd rather we accept a slightly lower adoption rate as the price of doing it right. IPv6 adoption seems to be growing just fine at the moment. If NAT is what you want, use IPv4. --001a114278dea021be0523accc51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 4, 2015 at 6:07 AM, Mark Smith <markzzzsmith@gmail.com>= ; wrote:

It&#= 39;ll also discourage IPv6 adoption if they go away.

If people have to pay for IPv6 address space just to use IPv= 6 they'll either steal public IPv6 space to use instead, or stick with = IPv4 and RFC1918s.

I don't think that's a good= argument. I think it's more important to preserve the architecture and= end-to-end than to rush "IPv6" adoption by deploying it the wron= g way. If there are reasons we can't use global addresses everywhere (e= .g., the inability to multihome), then we need to fix those, and I'd ra= ther we accept a slightly lower adoption rate as the price of doing it righ= t.

IPv6 adoption seems to be growing just fine at = the moment. If NAT is what you want, use IPv4.
--001a114278dea021be0523accc51-- From nobody Tue Nov 3 17:37: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 CE57D1A88E3 for ; Tue, 3 Nov 2015 17:37:54 -0800 (PST) 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 hZxGEV6tdZvc for ; Tue, 3 Nov 2015 17:37:51 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 DC4951A8762 for ; Tue, 3 Nov 2015 17:37:50 -0800 (PST) Received: by qgad10 with SMTP id d10so29490338qga.3 for ; Tue, 03 Nov 2015 17:37:50 -0800 (PST) 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=NnW0wTT7Ye9fchsiVl+HJQfJxnBLzvNIeDtNcM6t7fI=; b=PIiIiSp+EcQiDqOX2QrRaHJl/c0Xcn2wt35zJf/DKn4rVzHgw5uclqQBR1bNTZLwSY +RgCKwUSeoQRhxJiIDy9fZ333LADZ9mrZsXGojfMHwyPpkE7gg6l5m0d0bxIhAKXt3TR NSWOkwiF6V+i88ct/j13vIQmxhL39XLVmJC0bQjdt68i4wj7vweifJtTfZccKdubq7LB cBtmBei9w7tqQMqKHk9ROW1yxrV+haovH3YdhJwuxxvIfeHTY1ovp9UCXlGBWWPzEFax xHhtPlFUVWM9lkJ+itSyBywy0eupZfwOyzlb1+ZkGOSuo9WBQiiE5ABIWXm1qpcvgP3E OLdA== 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=NnW0wTT7Ye9fchsiVl+HJQfJxnBLzvNIeDtNcM6t7fI=; b=kR8uUXO69ZbtY2vKLMYcN8uo9QGa2BNjJhlKpWsuHg01uC9E30sVSLjnUSABTTzhhE etPiwHqNTD0+qqJN6zlMcc8WhpvCy1asbhcyyFjYRkqLInY2pdFz4eaH7kNQJ15wRg9K xETsENSf/QotdZk0zHB5h+QuDOctE5LP++lbBtraIgf7X+mGQEl7N+ZRKxK2KuPGWXZd ZJ/S9tx/KZ0/pbqlQjA9fO4FS3V+2cd1bhi+0BReeXGGAMJCFYPQ2i+eF7Wd6x1W14tq my24MRYRdF28VKVSXRMyO3BLZ+VmyO8EhC/1AFHxA7fjDMd9sj5F5tQJ7jXC9ugWz2gX sOsw== X-Gm-Message-State: ALoCoQl3t6nFctxshEN8ji2aFlSJtyDXMQvgl+q0HJerVLeaKlnVXGMJG1LIL2JtrzQdt292C4r5 X-Received: by 10.140.216.87 with SMTP id m84mr43133792qhb.97.1446601069980; Tue, 03 Nov 2015 17:37:49 -0800 (PST) Received: from ?IPv6:2001:420:c0c4:1006::2df? ([2001:420:c0c4:1006::2df]) by smtp.googlemail.com with ESMTPSA id f133sm10568241qkb.22.2015.11.03.17.37.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 17:37:49 -0800 (PST) To: Lorenzo Colitti , "Howard, Lee" References: <5637FDD0.70300@jvknet.com> From: Victor Kuarsingh Message-ID: <56396167.7030709@jvknet.com> Date: Wed, 4 Nov 2015 10:37:43 +0900 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="------------010007020807070003050705" Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 01:37:55 -0000 This is a multi-part message in MIME format. --------------010007020807070003050705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2015-11-03 1:55 PM, Lorenzo Colitti wrote: > My recollection is that we never got around to publishing this > document because we never managed to agree on what to say in the > recommendations. I think that because the working group does not > actually have consensus on what ULAs should be used for. > > Generalizing and handwaving a bit, I think that the major disagreement > is between: > > 1. Some proponents of ULAs are suggesting that ULAs (are being | can > be | should be) used in similar ways to RFC 1918, including using > them behind NPT66 or in the absence of global addresses, and say > that the document should list those as use cases. > Being a person who brought up one of the cases, I would like to clarify that this (used in similar ways to RFC1918) is not an umbrella statement (i.e. ULAs are not uniformly a replacement of where RFC1918 addresses have been used). However, there is at least one strong example where ULAs are technically suitable in place of where RFC1918 was used - (example there was modem management IPs). In this case, ULAs were used as a match for the technical requirements of such management needs. RFC1918 was also used previously as the closest match for the same technical needs, but the selection of ULAs and RFC1918s were made independently against a set of technical requirements (not as a comparative between address types chosen [ULA/RFC1918] - i.e. they were both closes match options for requirements). Not all uses of ULAs result in a decision to need to use NPT66 / NAT66. > 1. A fair number of WG members are vehemently opposed to such uses, > and say that WG documents should explicitly call out such > practices as harmful. We heard a few of those members at the mike > yesterday during the discussion of the design choices draft. > Given ULAs are already used I think it's important to document those use cases and outline the pros/cons of such usage. For use cases where there is data showing harm, that should be noted (based on the practical deployment observation/data gathered - and not based on the theory of what may occur unless this can be well articulated clearly/technically). > For as long as that disagreement exists, it will be hard to make a > recommendation, which is likely to make it hard to get consensus on > this draft. We can go through that disagreement again, but I don't > personally think the outcome will be any different from the one we had > last time around. Hence why I prefer to not name this a recommendation document. I prefer just giving it a title which denotes it as a ULA use case or deployment document. It's useful to know what has been deployed, and if possible the drivers of those decisions to better understand the reasoning behind such deployments. > > I happen to be in camp #2 and would be happy to support this draft if > it said that ULA-only deployments, NPT66 and NAT66 are harmful and > should be avoided. But I'm sure a fair number of people disagree with me. This is an interesting one. technically, NPT66 /NAT66 can be used with or without ULAs (although we know the most likely occurrence would potentiality be with ULAs - but that's not absolute). If there is a strong set of data which shows this [harm], should that not be documented interdependently as a standalone draft/RFC? (with the data gathered which shows/describes this harm in technical detail) . Then any document, including a ULA use case document, can point to that. regards, Victor K > > On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee > wrote: > > I see interest from Victor Kuarsingh, David Farmer, Alexandre > Petrescu, and > Brian Carpenter. Can I ask each of you to do a review of the current > document, and send comments to the mailing list? That will give the > authors > and the WG something to work from. > > Following that, we can discuss whether we need additional > discussion at a > meeting, or WGLC. > > Thanks, > > Lee > > > On 11/3/15, 9:20 AM, "Victor Kuarsingh" > wrote: > > >WG, > > > >My input is that we should continue this work. Given ULAs are already > >in use, having a document which outlines those use cases is, in > my mind, > >operationally beneficial. > > > >Perhaps we should be more clear that we would not be recommending the > >use of ULAs, but keep to a unbiased document which outlines how they > >have been used (just a use case discussion). We can also include > >objective technical points as to the pros/cons related to each > use case. > > > >It was also noted in another email (based on WG v6ops discussion > >yesterday), that one such valid example was Cable Modem > management IPs > >assigned ULA based addressing. This is a valid technical use case. > > > >I am willing to help if required on this document. > > > >regards, > > > >Victor K > > > >On 2015-11-02 6:17 PM, Howard, Lee wrote: > >> This document hasnÂąt had any revisions or discussion in a while. > >> Is there anyone interested in working on it? > >> > >> If we do not hear any interest, we will abandon this draft. > >> > >> Thanks, > >> Lee > >> > >> > >> ________________________________ > >> > >> This E-mail and any of its attachments may contain Time Warner > Cable > >>proprietary information, which is privileged, confidential, or > subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is > addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or > action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and > permanently > >>delete the original and any copy of this E-mail and any printout. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This > E-mail is intended solely for the use of the individual or entity > to which it is addressed. If you are not the intended recipient of > this E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may > be unlawful. If you have received this E-mail in error, please > notify the sender immediately and permanently delete the original > and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --------------010007020807070003050705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2015-11-03 1:55 PM, Lorenzo Colitti wrote:
My recollection is that we never got around to publishing this document because we never managed to agree on what to say in the recommendations. I think that because the working group does not actually have consensus on what ULAs should be used for. 

Generalizing and handwaving a bit, I think that the major disagreement is between:
  1. Some proponents of ULAs are suggesting that ULAs (are being | can be | should be) used in similar ways to RFC 1918, including using them behind NPT66 or in the absence of global addresses, and say that the document should list those as use cases.
Being a person who brought up one of the cases, I would like to clarify that this (used in similar ways to RFC1918) is not an umbrella statement (i.e. ULAs are not uniformly a replacement of where RFC1918 addresses have been used).  However, there is at least one strong example where ULAs are technically suitable in place of where RFC1918 was used - (example there was modem management IPs).  In this case, ULAs were used as a match for the technical requirements of such management needs.  RFC1918 was also used previously as the closest match for the same technical needs, but the selection of ULAs and RFC1918s were made independently against a set of technical requirements (not as a comparative between address types chosen [ULA/RFC1918] - i.e. they were both closes match options for requirements).

Not all uses of ULAs result in a decision to need to use NPT66 / NAT66.

  1. A fair number of WG members are vehemently opposed to such uses, and say that WG documents should explicitly call out such practices as harmful. We heard a few of those members at the mike yesterday during the discussion of the design choices draft.
Given ULAs are already used I think it's important to document those use cases and outline the pros/cons of such usage.  For use cases where there is data showing harm, that should be noted (based on the practical deployment observation/data gathered - and not based on the theory of what may occur unless this can be well articulated clearly/technically).
For as long as that disagreement exists, it will be hard to make a recommendation, which is likely to make it hard to get consensus on this draft. We can go through that disagreement again, but I don't personally think the outcome will be any different from the one we had last time around.
Hence why I prefer to not name this a recommendation document.  I prefer just giving it a title which denotes it as a ULA use case or deployment document.  It's useful to know what has been deployed, and if possible the drivers of those decisions to better understand the reasoning behind such deployments.


I happen to be in camp #2 and would be happy to support this draft if it said that ULA-only deployments, NPT66 and NAT66 are harmful and should be avoided. But I'm sure a fair number of people disagree with me.
This is an interesting one.  technically, NPT66 /NAT66 can be used with or without ULAs (although we know the most likely occurrence would potentiality be with ULAs - but that's not absolute).  If there is a strong set of data which shows this [harm], should that not be documented interdependently as a standalone draft/RFC? (with the data gathered which shows/describes this harm in technical detail) .

Then any document, including a ULA use case document, can point to that.

regards,

Victor K



On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee <lee.howard@twcable.com> wrote:
I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and
Brian Carpenter. Can I ask each of you to do a review of the current
document, and send comments to the mailing list?  That will give the
authors
and the WG something to work from.

Following that, we can discuss whether we need additional discussion at a
meeting, or WGLC.

Thanks,

Lee


On 11/3/15, 9:20 AM, "Victor Kuarsingh" <victor@jvknet.com> wrote:

>WG,
>
>My input is that we should continue this work.  Given ULAs are already
>in use, having a document which outlines those use cases is, in my mind,
>operationally beneficial.
>
>Perhaps we should be more clear that we would not be recommending the
>use of ULAs, but keep to a unbiased document which outlines how they
>have been used (just a use case discussion).  We can also include
>objective technical points as to the pros/cons related to each use case.
>
>It was also noted in another email (based on WG v6ops discussion
>yesterday), that one such valid example was Cable Modem management IPs
>assigned ULA based addressing.  This is a valid technical use case.
>
>I am willing to help if required on this document.
>
>regards,
>
>Victor K
>
>On 2015-11-02 6:17 PM, Howard, Lee wrote:
>> This document hasnÂąt had any revisions or discussion in a while.
>> Is there anyone interested in working on it?
>>
>> If we do not hear any interest, we will abandon this draft.
>>
>> Thanks,
>> Lee
>>
>>
>> ________________________________
>>
>> This E-mail and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or subject
>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>solely for the use of the individual or entity to which it is addressed.
>>If you are not the intended recipient of this E-mail, you are hereby
>>notified that any dissemination, distribution, copying, or action taken
>>in relation to the contents of and attachments to this E-mail is
>>strictly prohibited and may be unlawful. If you have received this
>>E-mail in error, please notify the sender immediately and permanently
>>delete the original and any copy of this E-mail and any printout.
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>


________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--------------010007020807070003050705-- From nobody Tue Nov 3 18:47: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 7BE571A8A52 for ; Tue, 3 Nov 2015 18:47:37 -0800 (PST) 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 sRwJBfIdCTWN for ; Tue, 3 Nov 2015 18:47:36 -0800 (PST) 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 8ABDA1A1B13 for ; Tue, 3 Nov 2015 18:47:36 -0800 (PST) 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 0D6DF3493B6; Wed, 4 Nov 2015 02:47:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B9FAF16003D; Wed, 4 Nov 2015 02:48:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A76816006B; Wed, 4 Nov 2015 02:48:19 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5rMh97H8gOlL; Wed, 4 Nov 2015 02:48:19 +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 335D016003D; Wed, 4 Nov 2015 02:48:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0DCDE3BC3CBF; Wed, 4 Nov 2015 13:47:31 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> In-reply-to: Your message of "Wed, 04 Nov 2015 10:18:58 +0900." Date: Wed, 04 Nov 2015 13:47:30 +1100 Message-Id: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 02:47:37 -0000 In message , Lorenzo Colitti writes: > > On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith wrote: > > > It'll also discourage IPv6 adoption if they go away. > > > > If people have to pay for IPv6 address space just to use IPv6 they'll > > either steal public IPv6 space to use instead, or stick with IPv4 and > > RFC1918s. > > > I don't think that's a good argument. I think it's more important to > preserve the architecture and end-to-end than to rush "IPv6" adoption by > deploying it the wrong way. If there are reasons we can't use global > addresses everywhere (e.g., the inability to multihome), then we need to > fix those, and I'd rather we accept a slightly lower adoption rate as the > price of doing it right. ULA + PA is NOT the "wrong way". ULA does NOT imply NAT. I don't think NAT should be done in IPv6 but that in no way indicates that I thing ULA is bad. You can misuse PI and NAT that to PA when you can't get your ISP to accept the PI. Do we ban PI because that can happen? > IPv6 adoption seems to be growing just fine at the moment. If NAT is what > you want, use IPv4. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 3 20:36: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 E71C21A9300 for ; Tue, 3 Nov 2015 20:36:09 -0800 (PST) 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 3Ksu0RZcptVD for ; Tue, 3 Nov 2015 20:36:08 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 05EEA1A92FE for ; Tue, 3 Nov 2015 20:36:07 -0800 (PST) X-SENDER-IP: 10.64.163.161 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,241,1444708800"; d="scan'208";a="450809516" Received: from unknown (HELO exchpapp20.corp.twcable.com) ([10.64.163.161]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 03 Nov 2015 23:27:38 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp20.corp.twcable.com (10.64.163.161) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 23:36:06 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 23:36:06 -0500 From: "Howard, Lee" To: Mark Andrews , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6I2lgggAAKhZCAALKNAIAAEwiAgAADuICAAPONgIAAKz1VgACZzgD//8UJmIAA+CUA Date: Wed, 4 Nov 2015 04:36:05 +0000 Message-ID: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> In-Reply-To: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21920.002 x-tm-as-result: No--46.882300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2A6D92383338F34C8D44BC696AD9C636@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 04:36:10 -0000 Here=B9s the consensus as I currently see it: 1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly the same reasons given in various NAT44/CGN documents (RFC2993 and RFC3027, as given in the draft). 2. There is consensus that NPT66 is bad, for some of the reasons give in various NAT44/CGN documents. It might be slightly less bad than NAT66, since it has slightly fewer of the problems given in those documents. 3. There is rough consensus on the use of ULAs outside of translation scenarios, such as in walled garden use cases, and/or in combination with PA space. #2 is covered with the words "it introduces similar additional complexity to applications, which may cause applications to break.=B2 (section 4.2.1) I would like to see more specifics on what breaks, in order to support a stronger statement. #3 is covered in the draft in some detail. Those who disagree with this consensus need to explain why. To everyone commenting on this draft, please refer to the document in your comments. =B3This text[=8A] should be changed to [=8A] because [=8A]=B2 is = very helpful. Argument by repetition or decibel is not helpful. Lee On 11/4/15, 11:47 AM, "v6ops on behalf of Mark Andrews" wrote: > >In message > >, Lorenzo Colitti writes: >> >> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith >>wrote: >> >> > It'll also discourage IPv6 adoption if they go away. >> > >> > If people have to pay for IPv6 address space just to use IPv6 they'll >> > either steal public IPv6 space to use instead, or stick with IPv4 and >> > RFC1918s. >> > >> I don't think that's a good argument. I think it's more important to >> preserve the architecture and end-to-end than to rush "IPv6" adoption by >> deploying it the wrong way. If there are reasons we can't use global >> addresses everywhere (e.g., the inability to multihome), then we need to >> fix those, and I'd rather we accept a slightly lower adoption rate as >>the >> price of doing it right. > >ULA + PA is NOT the "wrong way". > >ULA does NOT imply NAT. > >I don't think NAT should be done in IPv6 but that in no way >indicates that I thing ULA is bad. > >You can misuse PI and NAT that to PA when you can't get your >ISP to accept the PI. Do we ban PI because that can happen? > >> IPv6 adoption seems to be growing just fine at the moment. If NAT is >>what >> you want, use IPv4. >-- >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 ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Tue Nov 3 21:31: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 A175E1ACD54 for ; Tue, 3 Nov 2015 21:31:09 -0800 (PST) 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 L8yOHtu7KL6w for ; Tue, 3 Nov 2015 21:31:07 -0800 (PST) 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 3DDD61ACD52 for ; Tue, 3 Nov 2015 21:31:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZX01287; Wed, 04 Nov 2015 05:31:04 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 4 Nov 2015 05:31:03 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 4 Nov 2015 13:30:55 +0800 From: "Liubing (Leo)" To: "Howard, Lee" Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFVUaWz4Tcyq930Wi3jgKFnfWJ56I2lgggAAKhZD//9iUAIAAEwiAgAADt4CAAPONgIAAd9WAgAAG9ACAAEZCAIAAnv4z//+YFYCAAJR+gA== Date: Wed, 4 Nov 2015 05:30:55 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231A064@nkgeml506-mbx.china.huawei.com> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> 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.194.185.79] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56399818.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 05:31:09 -0000 Hi Lee, Thanks for the summary and the guidance. > #2 is covered with the words "it introduces similar additional complexity= to > applications, which may cause applications to break.=B2 (section 4.2.1) I= would > like to see more specifics on what breaks, in order to support a stronger > statement. Ack. I'll make it in the next version. Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee > Sent: Wednesday, November 04, 2015 1:36 PM > To: Mark Andrews; Lorenzo Colitti > Cc: v6ops list > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or > abandon? >=20 > Here=B9s the consensus as I currently see it: >=20 > 1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly = the > same reasons given in various NAT44/CGN documents (RFC2993 and RFC3027, > as given in the draft). > 2. There is consensus that NPT66 is bad, for some of the reasons give in = various > NAT44/CGN documents. It might be slightly less bad than NAT66, since it h= as > slightly fewer of the problems given in those documents. > 3. There is rough consensus on the use of ULAs outside of translation sce= narios, > such as in walled garden use cases, and/or in combination with PA space. >=20 > #2 is covered with the words "it introduces similar additional complexity= to > applications, which may cause applications to break.=B2 (section 4.2.1) I= would > like to see more specifics on what breaks, in order to support a stronger > statement. >=20 > #3 is covered in the draft in some detail. Those who disagree with this > consensus need to explain why. >=20 > To everyone commenting on this draft, please refer to the document in you= r > comments. =B3This text[=D0] should be changed to [=D0] because [=D0]=B2 i= s very helpful. > Argument by repetition or decibel is not helpful. >=20 > Lee >=20 >=20 > On 11/4/15, 11:47 AM, "v6ops on behalf of Mark Andrews" > wrote: >=20 > > > >In message > > il.com> > >, Lorenzo Colitti writes: > >> > >> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith > >>wrote: > >> > >> > It'll also discourage IPv6 adoption if they go away. > >> > > >> > If people have to pay for IPv6 address space just to use IPv6 > >> > they'll either steal public IPv6 space to use instead, or stick > >> > with IPv4 and RFC1918s. > >> > > >> I don't think that's a good argument. I think it's more important to > >>preserve the architecture and end-to-end than to rush "IPv6" adoption > >>by deploying it the wrong way. If there are reasons we can't use > >>global addresses everywhere (e.g., the inability to multihome), then > >>we need to fix those, and I'd rather we accept a slightly lower > >>adoption rate as the price of doing it right. > > > >ULA + PA is NOT the "wrong way". > > > >ULA does NOT imply NAT. > > > >I don't think NAT should be done in IPv6 but that in no way indicates > >that I thing ULA is bad. > > > >You can misuse PI and NAT that to PA when you can't get your ISP to > >accept the PI. Do we ban PI because that can happen? > > > >> IPv6 adoption seems to be growing just fine at the moment. If NAT is > >>what you want, use IPv4. > >-- > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for the > use of the individual or entity to which it is addressed. If you are not = the > intended recipient of this E-mail, you are hereby notified that any disse= mination, > distribution, copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be unlawful. If= you > have received this E-mail in error, please notify the sender immediately = and > permanently delete the original and any copy of this E-mail and any print= out. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 3 21:37: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 9A58A1ACDAB for ; Tue, 3 Nov 2015 21:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] 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 eEv1t2vmVPZa for ; Tue, 3 Nov 2015 21:37:31 -0800 (PST) Received: from tor-smtp-03.primus.ca (smtp-auth-5.primus.ca [67.230.159.5]) by ietfa.amsl.com (Postfix) with ESMTP id 318831ACDA4 for ; Tue, 3 Nov 2015 21:37:31 -0800 (PST) Received: from dhcp-29-65.meeting.ietf94.jp ([133.93.29.65]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZtqlE-0000tq-UC; Wed, 04 Nov 2015 00:37:29 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Philip Matthews In-Reply-To: Date: Wed, 4 Nov 2015 14:37:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <48A7E05C-5050-4168-8BE5-073926AACEFC@magma.ca> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> To: "Howard, Lee" X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - dhcp-29-65.meeting.ietf94.jp [133.93.29.65] Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 05:37:32 -0000 Unless there is strong consensus (which I don't think there is), then I = suggest that it is better to list the pros and cons of each usage and = let people make their own choices, than to just say "Don't do this". It = is very hard in the IETF to get solid consensus on things, and so I = suggest we just present the facts and let people draw their own = conclusions.=20 - Philip On 2015-11-04, at 13:36 , Howard, Lee wrote: > Here=B9s the consensus as I currently see it: >=20 > 1. There is consensus that NAT66 (particularly NAPT) is bad, for = exactly > the same reasons given in various NAT44/CGN documents (RFC2993 and > RFC3027, as given in the draft). > 2. There is consensus that NPT66 is bad, for some of the reasons give = in > various NAT44/CGN documents. It might be slightly less bad than NAT66, > since it has slightly fewer of the problems given in those documents. > 3. There is rough consensus on the use of ULAs outside of translation > scenarios, such as in walled garden use cases, and/or in combination = with > PA space. >=20 > #2 is covered with the words "it introduces similar additional = complexity > to applications, which may cause applications to break.=B2 (section = 4.2.1) > I would like to see more specifics on what breaks, in order to support = a > stronger statement. >=20 > #3 is covered in the draft in some detail. Those who disagree with = this > consensus need to explain why. >=20 > To everyone commenting on this draft, please refer to the document in = your > comments. =B3This text[=8A] should be changed to [=8A] because [=8A]=B2 = is very > helpful. Argument by repetition or decibel is not helpful. >=20 > Lee >=20 >=20 > On 11/4/15, 11:47 AM, "v6ops on behalf of Mark Andrews" > wrote: >=20 >>=20 >> In message >> >> , Lorenzo Colitti writes: >>>=20 >>> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith >>> wrote: >>>=20 >>>> It'll also discourage IPv6 adoption if they go away. >>>>=20 >>>> If people have to pay for IPv6 address space just to use IPv6 = they'll >>>> either steal public IPv6 space to use instead, or stick with IPv4 = and >>>> RFC1918s. >>>>=20 >>> I don't think that's a good argument. I think it's more important to >>> preserve the architecture and end-to-end than to rush "IPv6" = adoption by >>> deploying it the wrong way. If there are reasons we can't use global >>> addresses everywhere (e.g., the inability to multihome), then we = need to >>> fix those, and I'd rather we accept a slightly lower adoption rate = as >>> the >>> price of doing it right. >>=20 >> ULA + PA is NOT the "wrong way". >>=20 >> ULA does NOT imply NAT. >>=20 >> I don't think NAT should be done in IPv6 but that in no way >> indicates that I thing ULA is bad. >>=20 >> You can misuse PI and NAT that to PA when you can't get your >> ISP to accept the PI. Do we ban PI because that can happen? >>=20 >>> IPv6 adoption seems to be growing just fine at the moment. If NAT is >>> what >>> you want, use IPv4. >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Nov 3 23:46: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 571CF1B2A07 for ; Tue, 3 Nov 2015 23:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6jiuJiKd0ZTC for ; Tue, 3 Nov 2015 23:46:16 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id D962F1B2A14 for ; Tue, 3 Nov 2015 23:46:15 -0800 (PST) Received: by puck.nether.net (Postfix, from userid 507) id 844FB540A30; Wed, 4 Nov 2015 02:46:15 -0500 (EST) Date: Wed, 4 Nov 2015 02:46:15 -0500 From: Jon Mitchell To: "Howard, Lee" Message-ID: <20151104074615.GA32522@puck.nether.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 07:46:17 -0000 On 04/11/15 04:36 +0000, Howard, Lee wrote: > Here¹s the consensus as I currently see it: > > 1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly > the same reasons given in various NAT44/CGN documents (RFC2993 and > RFC3027, as given in the draft). > 2. There is consensus that NPT66 is bad, for some of the reasons give in > various NAT44/CGN documents. It might be slightly less bad than NAT66, > since it has slightly fewer of the problems given in those documents. > 3. There is rough consensus on the use of ULAs outside of translation > scenarios, such as in walled garden use cases, and/or in combination with > PA space. > #3 is covered in the draft in some detail. Those who disagree with this > consensus need to explain why. Great summary - just wanted to add as an operator my agreement with #3, I also feel after a thorough re-reading of the draft that it does not endorse ULA+NAT solutions directly and I'm supportive of having a document that covers this space. > To everyone commenting on this draft, please refer to the document in your > comments. ³This text[Š] should be changed to [Š] because [Š]² is very > helpful. Argument by repetition or decibel is not helpful. I think the below wording changes might be helpful although I don't think they will specifically address any concern raised in this thread, it may help with some of the perceived bias of the draft. -Jon Intro - replace: "normally are not used on the public Internet" with: "they are not to be globally routed on the public Internet". Section 3.2 - rename section title, these addresses are not Globally Unique - maybe "Low Probability of Non-Uniqueness" Section 4.2 - first bullet - replace: "the standard way, this will not be a big problem." with: "using the standard algorithm, this is extremely improbable." third bullet - replace entirely with: "Prefix generation: Randomly generated according to the algorithms defined in [RFC4193]. If there are some specific reasons that call for manual predictable assignments, that manipulation should be kept strictly in the Subnet ID and not the Global ID, as described in Section 3.1 of [RFC4193] to avoid collision." Section 4.3 - replace: "and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6 connectivity." with: "a ULA may be considered for providing local IPv6 connectivity needs." Section 5.1 - 2nd paragraph, replace: "But it is not necessary to combine ULAs with any kind of NAT." with: "However it is not recommended to combine ULAs (or any other IPv6 address) with any kind of NAT." Also, scratch last two sentences of paragraph. Section 5.2 - 2nd paragraph, replace: "and configure ACLs on relevant border routers to block them out of the scope." with: "and configure ACLs and appropriate route filters on relevant border routers to block them from leaving the domain." From nobody Wed Nov 4 01:39: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 F27EE1A0146 for ; Wed, 4 Nov 2015 01:39:16 -0800 (PST) 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 SGiYSy6o-5mV for ; Wed, 4 Nov 2015 01:39:15 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 878E61A0102 for ; Wed, 4 Nov 2015 01:39:15 -0800 (PST) Received: by ykdr3 with SMTP id r3so62176391ykd.1 for ; Wed, 04 Nov 2015 01:39:14 -0800 (PST) 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=ougec5cjECkQ3uWy+P8rhqvIUadE8IsSGGGTTLvinnU=; b=DgBNhOfENLWC3cnuChRxi7GHKpWk75CADY6dRp/h5BmwTZniX/wYlhoiUrc/EL9/7l 5bKd5N3Gef2x2YFo1x2fsFMXRxbOT8o+xnlhci+xC4iRGcAAFlXVCEy/5XmqKq5rth3M 3s5HHNbsLlxgM7PVwAJL0vXVGOntP6udlcR5AJbfhntGsG2/fu9zcXB8buaNSLC9WxKo EeI7WPh5rvg0aPB4WFu9YuGNQi/OmkLMrxrJNK34dMuBVQfQQ1X1VEbji3wqab+M/EWm t5UQmK/4fiyVrOHhz3aUWCGMCL6t9SJ+D22N1Wb6TfKaI/RciHd61/elliJrGYECXp5v RtmQ== MIME-Version: 1.0 X-Received: by 10.31.158.198 with SMTP id h189mr500708vke.102.1446629954907; Wed, 04 Nov 2015 01:39:14 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 01:39:14 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 01:39:14 -0800 (PST) In-Reply-To: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> Date: Wed, 4 Nov 2015 20:39:14 +1100 Message-ID: From: Mark Smith To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11425cf29571f90523b3c8b7 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 09:39:17 -0000 --001a11425cf29571f90523b3c8b7 Content-Type: text/plain; charset=UTF-8 On 4 Nov 2015 12:19 PM, "Lorenzo Colitti" wrote: > > On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith wrote: >> >> It'll also discourage IPv6 adoption if they go away. >> >> If people have to pay for IPv6 address space just to use IPv6 they'll either steal public IPv6 space to use instead, or stick with IPv4 and RFC1918s. > > I don't think that's a good argument. I think it's more important to preserve the architecture and end-to-end than to rush "IPv6" adoption by deploying it the wrong way. If there are reasons we can't use global addresses everywhere (e.g., the inability to multihome), then we need to fix those, and I'd rather we accept a slightly lower adoption rate as the price of doing it right. > > IPv6 adoption seems to be growing just fine at the moment. If NAT is what you want, use IPv4. I'm not advocating ULAs to then be used with IPv6 NAT, I'm advocating its use for closed networks that are not connected to the Internet, or for use in parallel with PI or PA space, so that internal network addressing is completely decoupled from and not dependent on external access and having to have (and pay) external parties for access space. There is only one case where I'd accept ULA only addressing that had a level of access to the Internet, and that is where the ULA addresses are used to teach a full and application specific proxy or gateway (e.g. a HTTP proxy). I'd accept that if the user truly wants the complete identities of the hosts to be hidden from the Internet - the traffic looks like it all originated from the proxy itself to outside parties. I think the fundamental use with NATs is they're a half measure - in many cases they're either not application aware, so they only translate IP header addresses, or they're not truly acting as a full and complete proxy for the hosts sitting behind them, such that the hosts aren't truly hidden from the outside destinations. Regards, Mark. --001a11425cf29571f90523b3c8b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 Nov 2015 12:19 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>> It'll also discourage IPv6 adoption if they go away.
>>
>> If people have to pay for IPv6 address space just to use IPv6 they= 'll either steal public IPv6 space to use instead, or stick with IPv4 a= nd RFC1918s.
>
> I don't think that's a good argument. I think it's more im= portant to preserve the architecture and end-to-end than to rush "IPv6= " adoption by deploying it the wrong way. If there are reasons we can&= #39;t use global addresses everywhere (e.g., the inability to multihome), t= hen we need to fix those, and I'd rather we accept a slightly lower ado= ption rate as the price of doing it right.
>
> IPv6 adoption seems to be growing just fine at the moment. If NAT is w= hat you want, use IPv4.

I'm not advocating ULAs to then be used with IPv6 NAT, I= 'm advocating its use for closed networks that are not connected to the= Internet, or for use in parallel with PI or PA space, so that internal net= work addressing is completely decoupled from and not dependent on external = access and having to have (and pay) external parties for access space.

There is only one case where I'd accept ULA only address= ing that had a level of access to the Internet, and that is where the ULA a= ddresses are used to teach a full and application specific proxy or gateway= (e.g. a HTTP proxy). I'd accept that if the user truly wants the compl= ete identities of the hosts to be hidden from the Internet - the traffic lo= oks like it all originated from the proxy itself to outside parties.

I think the fundamental use with NATs is they're a half = measure - in many cases they're either not application aware, so they o= nly translate IP header addresses, or they're not truly acting as a ful= l and complete proxy for the hosts sitting behind them, such that the hosts= aren't truly hidden from the outside destinations.

Regards,
Mark.

--001a11425cf29571f90523b3c8b7-- From nobody Wed Nov 4 01:57: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 D4FE11B2C3D for ; Wed, 4 Nov 2015 01:57:13 -0800 (PST) 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 LQGMXZP-uLNU for ; Wed, 4 Nov 2015 01:57:08 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5481B2C3A for ; Wed, 4 Nov 2015 01:57:05 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 09:56:45 +0000 Message-ID: <027101d116e6$f96526a0$4001a8c0@gateway.2wire.net> From: t.petch To: "Liubing (Leo)" , Lorenzo Colitti , "Howard, Lee" References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> Date: Wed, 4 Nov 2015 09:55:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: HE1PR05CA0060.eurprd05.prod.outlook.com (25.164.28.28) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 2:iwwI9LrQn7HX9QhnNCO5Ko6+9OU7TMcVMT8TJs91LXyWtI5/oiGZ0QhmpOMViVPEWCdbokJ/K5BIUGEgc0xhLDoipo98FaaszHC4UxiMb3oWryXhn5c/Ljjn18gxirPV9qk6ejaZ/wbx4nuotQVtSwg9znciGzAOaNCCLgJjGhY=; 3:bq//G6YLBu89GnFX07F9C283uSl235nbOoOzHWIJPkZHyuR25JY2HvsL9DXxkzlyDTF9jNCb67irzvO6MvgSwYyCf6hGhj8J61uEdL1xdlpBdmnSdqiLEurRM5EnUemk6DV9NhjENNeEQ5/cmaEipg==; 25:0zsCX/SccwCSoGFu87j7zOCFms4WGmEEJkFI3Dlfxby4lj+vreZZu7xnfR84Uxa3VTiKndhIiMbaTFP1iRLym5jwOX9n3uUiIigUkmu4YjFhLZKQvAXTqeP0puiDm7l7fiECKie51j5ptzb9qqq0pufnCgoFSw40A6OdmHjMTonG2WOrrv/GV+Zi0LwHuAQWCLyY7q1W2rcVLtfmtox5LmE9SPiMOXDUEX9OfwwlUs0BLdu/oe4RkuDpSbeTZ6bJLpkFm8yqX18bjrHEHerDmA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(3457453519779); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 4:TSW7sXVfiw9TayX8+SojTVdX7ikMUqTkDlJoh/LfDYQILpHS+ezdWn+e446dnPuAj7sgXVOnxIxTxAW9smXjOZd6Bzc4t17m6vL8+sTdecPzN9mixp9KfgGPDhsI7tZynYtTpCItG8jq8XIMAOdaEZBLnB6ESKZb+rD8bp+LmDEO9EduthltMWZ0/aeGOGT6lmufn//6QYd9q7kL51FBwR4dbs+11dGzeIEeBDf2fpoRWsGwksmPRUjIsxNJjyU3uXkgZPDVw9Hz6n4Bt+bMXrkF4G3S+XWGq6ZMdgk+xeXwiV5C69oREU1rsW0oq43ZO1T8tT9qHEZibs9ytimtzipKDe5GZVAIJUCOGdYPzOsddZPkBYwydcN/wLyxuS0b X-Forefront-PRVS: 0750463DC9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(164054003)(199003)(377454003)(13464003)(377424004)(52254002)(51444003)(24454002)(189002)(5004730100002)(101416001)(62236002)(86362001)(5008740100001)(93886004)(1456003)(81816999)(76176999)(81686999)(105586002)(23676002)(1556002)(44736004)(15975445007)(19580405001)(5890100001)(44716002)(5007970100001)(14496001)(66066001)(230783001)(40100003)(5001770100001)(50226001)(50986999)(77096005)(87976001)(92566002)(19580395003)(5820100001)(97736004)(81156007)(106356001)(5001960100002)(84392001)(122386002)(42186005)(61296003)(5001920100001)(189998001)(116806002)(33646002)(47776003)(50466002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTM7MjM6cUxGU0FGNk1iaEp0Szd2VGllOXdXbWNLc3dT?= =?utf-8?B?ZjBzRkhDanBQK0xIZklNejVrRzE0Y05BR2x2MUFGQlphdm12Y2lMTDNKdThN?= =?utf-8?B?blR1MVhHb05tdVZsNUgxVUNTanJDUFZxQXR3c2w4UitFcjFMeDR2MmNrbDkz?= =?utf-8?B?ODN5Y2toeEd6NXFNOGJXKzJOODRKRXRJSERnV2RSVTVpdHNXY0p4QVV2MTNM?= =?utf-8?B?QlpQb3hxeisxT2F5M2xVb3Q4SVVjWDFVNzQwVmdBZ1drVEN6eFlCZCtWY3pF?= =?utf-8?B?aEZrZ1ZvelA3azZ3WHFaMDBHL0NyZENESDJRK0dETG1mbEV4dXdkUUVUc1p3?= =?utf-8?B?N0hhajVGcmZ5VjNZbE1NVENDWW1mOHA2M0JLdHVqRWV1bUFIRTd1Tm5JU05I?= =?utf-8?B?UFdjREFKem56aVliVG5laFhFNm1CYWo0ekVwYmFrSmErUEt4ejBtWFAwWFNz?= =?utf-8?B?VkFnNHc3OThjOGZvZVZTQm43Vi9DK3VTOXhHc0p4cGJkYXZ1VWZNNlNpeEZv?= =?utf-8?B?Tk1TcFlkc3N3dDJEekhOdXFxSnRjMDZQVGI5aTdneENzcHMzK1NkcWVuK2M3?= =?utf-8?B?ZkZBR3pNVG1WbWMyWTR4TldQV2xjbTBDYUZsR0thREhheXlJdFNzbTF5Tlo0?= =?utf-8?B?cEZodGhONzhEK0VaWnN6Mkw5bjk0QUI4aTgva2xQWW5BeTExUHZqRkxiRitK?= =?utf-8?B?OVZyeVVMM0ZpZkZ4bEw5Ny9jRnFDb0NsUm1tblN1MGxwU0U1d0JnaU5hcDBR?= =?utf-8?B?Ym1SK3BFbWxvUlVDSDRWMnZ3dlBRellyNms5N2xTREtBZVdhckhZSVpxSnF3?= =?utf-8?B?Wm9yUzVObXZ5R2JWRnc2WlNwM01wWDh1QlRiN2FrdFY4ZFh6d2VlZXN3U3Jh?= =?utf-8?B?Z0I2ODErd1V2UGtVREFwR1g3TlhodG5pOHgxVjE3WWUwdEt6WkxoajVReERG?= =?utf-8?B?SEtUREJoTWxzYjc2OGRWYk5sWnY5VmF5ditUbEUzYVZDVkRlWkU4S3k1SWM4?= =?utf-8?B?ZnJLT2NKZGFxS3ZPbllQV3g5VitMRTNvK1cxaTBiVUpLL3N2OVdCencyakpo?= =?utf-8?B?OUVUVnA0YkwxUzhzZ0RSRzNUUThCVWR0ZUNTWUk0VGVVYm8xMVI5VWUybFJO?= =?utf-8?B?NTk4bmh6NE1ZNmtEKzFmdU9RTHhtcTdBT0I1QXdmdUhXWVBLRUYwdXAwRDdE?= =?utf-8?B?K05aM2VOUUoyVGVlbDR6RWJuOWlYVCszNDdnLzc4bGNsYkVnZFozdzdMRGRt?= =?utf-8?B?ZXkvUEw0ZnJPWFR0VmZxUE9PMmdHUW90UjlLVjBnUC9wTFBvbWdmYy9vbVpy?= =?utf-8?B?aWlpcmkwaFRIUlNvUHlRM1ZBbFg0cWh5SnNKYkR4R0lNTnY0V3VzSThBdkE1?= =?utf-8?B?dE92YW1yNkFhNW96K3F2S3R1bzYrMm1zNlBVWVNxRkF5Qk9wREpuWXR6Sk9Q?= =?utf-8?B?SUIyanNJZ2lqMk9LekpIOGtuWlNQM05nbm9IQmJzU3NUazVlNUJiVU92ODB5?= =?utf-8?B?Vm16RWNZRGZNc3h3TTh0Vm04Uk5DbWJTMU5xNUh2NVZ6QmRoWGQ1VFhKNk5z?= =?utf-8?B?L3ZBUDhqQ3d0WHowRnFTUjFNcmFwckFaUVBkYnNJN3daekoycmRyY1VOMml2?= =?utf-8?B?RFQzM09JYUVmemN0Q0tUS1R5dGd3UWxENmJYYTJWc1hHTFNwanJsZDg3YXoy?= =?utf-8?B?cEMzK2ltVnZHa2g2NWxSSUUyRmdJMUNvQ3R3MDl5VlpLY1paOEJoQ0VyS242?= =?utf-8?B?K1BHNDQ5S0hXelhpZmxBZ1ZxbjM2cGtlR2ZydTJDanVUUFRlZ3N0UGpqcVAz?= =?utf-8?B?MDE0VGRiWExBUU5uRG1XRDFQVVhuUHlaQmhZOUFFa2tyMXhBbkZ5YThTbWZD?= =?utf-8?B?SmsvR2J0b3lvWFgzSThPWWJSZEdvSHA1N2cxd1k4enNQdGJrNjJtRFExWklY?= =?utf-8?B?T1ZUMDN3bjRPK28zUW1QNDBibzJMMUxuQVAzUXAwSmNIb1lCVnRtaGFhdFpz?= =?utf-8?B?T1h5cXVzUUlJZmd5U0pIcEFtUk9qWjZEVWN4K1FsV0h4Y0I2WkVXVDEyQW0y?= =?utf-8?Q?e7Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 5:HAGM4etRhTAvKAI6jhip6U2qFmcyes+7EyHGcs6tOHoakhz7StybGFVR1wIRmU1FLs/9ky/VTwLy1cW35EQVb2ezh943TrF7A+15IQ6N8xoaayTP+GYk/MM7nXD5Hd9mrsX7QysxesU0lfw4LdDgqw==; 24:IWSPUWXOso/jyOhXTJu+GweQjYpBT+wPLMnxFDNE3AAKPX6f8Yq7d3KlprO0dKhWWjyKqhJBUAkciq2WFPEzY2DPTjMqRMJLr3FPftrkHfg=; 20:mhpCH7t7lGvjJmVWDbbiJ7nlK/eVJTS8W+Pg7FH/g7Y4IBIHMvRI0AkzJn3m+1cA9Ia9vest5DeuZfaWx9n97A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2015 09:56:45.5724 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 09:57:14 -0000 ----- Original Message ----- From: "Liubing (Leo)" To: "Lorenzo Colitti" ; "Howard, Lee" Cc: "IPv6 Operations" Sent: Tuesday, November 03, 2015 5:33 AM Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? > Hi Lorenzo and all, > > Thanks for your feedback. > > > For as long as that disagreement exists, it will be hard to make a recommendation, > > which is likely to make it hard to get consensus on this draft. > > We can go through that disagreement again, but I don't personally think > > the outcome will be any different from the one we had last time around. > [Bing] I basically agree with this claim. But that is actually why we changed the document’s purpose from recommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make any formal recommendation. > But maybe because the draft’s short name was not changed accordingly, it has been still “draft-ietf-v6ops-ula-recommendations”, which made people misunderstand the purpose of the draft. > > I’ve requested to the chairs to change the draft’s short name to “draft-ietf-v6ops-ula-considerations”, I hope it is doable. I think that an extraordinarily bad idea. The draft name is an identifier, something to tie together the various versions, comments thereon, Last Calls etc. in the years to come. Change the identifier - as some foolish WGs are wont to do - and that link is broken so it becomes difficult to see what has gone on previously. What matters is what the RFC contains, such as the title and the running footing thereof, not the identifier we use to tie together the work while getting there. Tom Petch p.s. More generally, I have seen overloading an identifier with semantics cause many network problems over the years and is always a bad idea. > Best regards, > Bing > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti > Sent: Tuesday, November 03, 2015 1:55 PM > To: Howard, Lee > Cc: IPv6 Operations > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? > > My recollection is that we never got around to publishing this document because we never managed to agree on what to say in the recommendations. I think that because the working group does not actually have consensus on what ULAs should be used for. > > Generalizing and handwaving a bit, I think that the major disagreement is between: > > 1. Some proponents of ULAs are suggesting that ULAs (are being | can be | should be) used in similar ways to RFC 1918, including using them behind NPT66 or in the absence of global addresses, and say that the document should list those as use cases. > 2. A fair number of WG members are vehemently opposed to such uses, and say that WG documents should explicitly call out such practices as harmful. We heard a few of those members at the mike yesterday during the discussion of the design choices draft. > For as long as that disagreement exists, it will be hard to make a recommendation, which is likely to make it hard to get consensus on this draft. We can go through that disagreement again, but I don't personally think the outcome will be any different from the one we had last time around. > > I happen to be in camp #2 and would be happy to support this draft if it said that ULA-only deployments, NPT66 and NAT66 are harmful and should be avoided. But I'm sure a fair number of people disagree with me. > > On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee > wrote: > I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and > Brian Carpenter. Can I ask each of you to do a review of the current > document, and send comments to the mailing list? That will give the > authors > and the WG something to work from. > > Following that, we can discuss whether we need additional discussion at a > meeting, or WGLC. > > Thanks, > > Lee > > > On 11/3/15, 9:20 AM, "Victor Kuarsingh" > wrote: > > >WG, > > > >My input is that we should continue this work. Given ULAs are already > >in use, having a document which outlines those use cases is, in my mind, > >operationally beneficial. > > > >Perhaps we should be more clear that we would not be recommending the > >use of ULAs, but keep to a unbiased document which outlines how they > >have been used (just a use case discussion). We can also include > >objective technical points as to the pros/cons related to each use case. > > > >It was also noted in another email (based on WG v6ops discussion > >yesterday), that one such valid example was Cable Modem management IPs > >assigned ULA based addressing. This is a valid technical use case. > > > >I am willing to help if required on this document. > > > >regards, > > > >Victor K > > > >On 2015-11-02 6:17 PM, Howard, Lee wrote: > >> This document hasn¹t had any revisions or discussion in a while. > >> Is there anyone interested in working on it? > >> > >> If we do not hear any interest, we will abandon this draft. > >> > >> Thanks, > >> Lee > >> > >> > >> ________________________________ > >> > >> This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 4 02:42: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 DD0761AD375 for ; Wed, 4 Nov 2015 02:42:13 -0800 (PST) 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 Scz85EFoK3dx for ; Wed, 4 Nov 2015 02:42:12 -0800 (PST) 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 086F11B2AC9 for ; Wed, 4 Nov 2015 02:42:11 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4A90362E64 for ; Wed, 4 Nov 2015 11:42:09 +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 E817360128 for ; Wed, 4 Nov 2015 11:42:08 +0100 (CET) Received: (qmail 95817 invoked by uid 1007); 4 Nov 2015 11:42:08 +0100 Date: Wed, 4 Nov 2015 11:42:08 +0100 From: Gert Doering To: "Howard, Lee" Message-ID: <20151104104208.GL70452@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> 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 list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 10:42:14 -0000 Hi, On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: > 2. There is consensus that NPT66 is bad, for some of the reasons give in > various NAT44/CGN documents. It might be slightly less bad than NAT66, > since it has slightly fewer of the problems given in those documents. I don't think there is consensus on that... otherwise we wouldn't have published NTP66. 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 Wed Nov 4 04:26: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 6AB2C1B2E42 for ; Wed, 4 Nov 2015 04:26:30 -0800 (PST) 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 p2boX5JjuajJ for ; Wed, 4 Nov 2015 04:26:29 -0800 (PST) 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 D95A81B2E3F for ; Wed, 4 Nov 2015 04:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5227; q=dns/txt; s=iport; t=1446639988; x=1447849588; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i5KuWhuo8UFxudCJsN23+cfvTsHxmon9RsniP4QCrl8=; b=Gf+d22JhTC4302E5LteszJ+VQDyNwCg95DtjqWkvki7r8FjbeG0TCXUT 35COvRuvuQF0WyrxyLHsnfEOX319PdhIjU6iVP8cwwRv0mBwu3OECwaOH QRwkd9dIUXmlq7gz1uACr1+5eikI/LX9OtPfnlsyuczAgJ1eY7x08n2Lt M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxAgAy+DlW/5tdJa1egzuBQga9Pg6BXYYTAoFAOBQBAQEBAQEBgQqENQEBAQMBeQULAgEIBA4GJwchERQDDgIEDgUOiAsDCgi9CQ2ELgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8JiGWCboJThVGBFAWWSAGCUYFhhnyBdIFakxWDYINxAR8BQ4QEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="asc'?scan'208,217";a="204931286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 04 Nov 2015 12:26:28 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA4CQRxn032570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 12:26:28 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 07:26:26 -0500 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; Wed, 4 Nov 2015 07:26:26 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFvwGW+Bklb5Loku+uw8b9sz4Dw== Date: Wed, 4 Nov 2015 12:26:26 +0000 Message-ID: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> 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.70.233.10] Content-Type: multipart/signed; boundary="Apple-Mail=_08B433C6-107F-45B1-8DAD-3EA0530718E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 12:26:30 -0000 --Apple-Mail=_08B433C6-107F-45B1-8DAD-3EA0530718E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_87F7C7E8-7E27-46C7-9F79-7402E398D8B0" --Apple-Mail=_87F7C7E8-7E27-46C7-9F79-7402E398D8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti = wrote: >=20 > On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith > wrote: > It'll also discourage IPv6 adoption if they go away. >=20 > If people have to pay for IPv6 address space just to use IPv6 they'll = either steal public IPv6 space to use instead, or stick with IPv4 and = RFC1918s. >=20 > I don't think that's a good argument. I think it's more important to = preserve the architecture and end-to-end than to rush "IPv6" adoption by = deploying it the wrong way. If there are reasons we can't use global = addresses everywhere (e.g., the inability to multihome), then we need to = fix those, and I'd rather we accept a slightly lower adoption rate as = the price of doing it right. >=20 > IPv6 adoption seems to be growing just fine at the moment. If NAT is = what you want, use IPv4. So, in your mind, the only usage of ULA is NAT. I actually think there = are other uses, such as for addressing cable modems and the like that = don't go through a NAT. Assume we agree that NAT is evil. Is there a = reason uses in which an address is excluded from inter-network usage is = therefore bad? --Apple-Mail=_87F7C7E8-7E27-46C7-9F79-7402E398D8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith <markzzzsmith@gmail.com> = wrote:

It'll also discourage IPv6 adoption if they go = away.

If people have = to pay for IPv6 address space just to use IPv6 they'll either steal = public IPv6 space to use instead, or stick with IPv4 and = RFC1918s.

I don't think that's a good = argument. I think it's more important to preserve the architecture and = end-to-end than to rush "IPv6" adoption by deploying it the wrong way. = If there are reasons we can't use global addresses everywhere (e.g., the = inability to multihome), then we need to fix those, and I'd rather we = accept a slightly lower adoption rate as the price of doing it = right.

IPv6 = adoption seems to be growing just fine at the moment. If NAT is what you = want, use IPv4.

So, in your mind, the only usage of ULA is NAT. I = actually think there are other uses, such as for addressing cable modems = and the like that don't go through a NAT. Assume we agree that NAT is = evil. Is there a reason uses in which an address is excluded from = inter-network usage is therefore bad?
= --Apple-Mail=_87F7C7E8-7E27-46C7-9F79-7402E398D8B0-- --Apple-Mail=_08B433C6-107F-45B1-8DAD-3EA0530718E6 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 iQIVAwUBVjn5cUayAOS/EQ8MAQK2fQ/8Cu+CjxgPDgk2p/inF3vXVVaP9YLWwRWl UhQ0K0lXALv3d0IwkuwQe3yKMhMZyBlTudTifdFTGZVPcukeZyaGXRYf7qD9HyVh EvlqpVAgH5xmIpTTvVILyacER5Zzuida0Cyege5BYlVjt5hdCRpu5uwcD7imQYwH gWTlzpDVNPU2qGRb0Bws/8W1l+TPDxxZIDnUhzSwTvcodP0oAFq/dVzSOaef7T3g Eu1xN/NwtMw421+/WStjKk9wmgw5QFgi1AMxSGKsRhZ6Clks/WZg63G6/x3oJoyQ A0cITPgOzddCPmaDwj+56OwdpTdBFTxTDIcjMkUMC0WIfOMO+/YeWfuQA2j19oft CsbXWf4FNN0MFtRY6EFHHsri3uctn+XG0JvuKDSKpCKExag18onyLSV+Bbbo5L0T Q5UbRo5KchVWDIrJfSrw3T8C7pKTt0B/DscG08w07Lmc4tAq5ePHX1VeAUtSB2oq 6RdOGd3TCQ40ScuYN0YBrLOPDpQ9MP4Ihuw2RKBKy96PIpxXCy/f+KTyEVRWalxS y+h98gWVKwHuM6+KogKyfl6HqkYZNY8FbmP9Goj5+Zqj1oCzAd4CdGlguqT/a/fR bwqIIo6TK+jfW9fG59H7lxuXdHWTCAYYri9HOjPHku661knYt4JeZTGc4prGOGus 5hIXGJtWL6s= =x4dU -----END PGP SIGNATURE----- --Apple-Mail=_08B433C6-107F-45B1-8DAD-3EA0530718E6-- From nobody Wed Nov 4 06:40: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 53DB41B308F for ; Wed, 4 Nov 2015 06:40:26 -0800 (PST) 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 HNQp_ed0dpmE for ; Wed, 4 Nov 2015 06:40:25 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id E22731B30B8 for ; Wed, 4 Nov 2015 06:40:24 -0800 (PST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 4 Nov 2015 08:40:21 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f175.google.com [209.85.223.175] #+LO+TS+TR X-Umn-Classification: local Received: by iody8 with SMTP id y8so55278791iod.1 for ; Wed, 04 Nov 2015 06:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=oT3XlLSepD21PNVo6Qzx3H9to/HGz3rBnILSWVBwl4A=; b=Z6/ppRMZKUOhiSSkXMKu2of7MUo//8NnbAsTHqRGh1VAmfZv5bUJv4zw746t/7XZ7t CU2mMcFre7ZUHNuP2aKYq34yMiutGLySkUMdAymgS9y6rRnm9mG838nkSigthvnmVp7o xdsM/8lG0Gdskclq9D6XOuBnCj9xlD0iGy2Ic= 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-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=oT3XlLSepD21PNVo6Qzx3H9to/HGz3rBnILSWVBwl4A=; b=Gfupol+WYJ5eTweJi/34ViZWhtuUHDqACaKVNZlzAmA37p5WU6ZAntwZQJkhz5nBK9 H8jH7QoO0u7nQAw5dCz65csJT7wpyNG83yTHsv/v9ukJeGnGTpNKhdlKkpYRj3nnqDL+ 7r0dHYvQqeIlsHF6sSWFGPukuj2cQOBFaFotp98RRam34N0B81ASW/mYoPhqU5d5vNoA 5ynclhxQ9a+mnMFYawUUwltf0ARF6xPXZXnP05WJJI9QyhkfdNb0G1pE0UuCEYMybAC9 av3ojTt8c5SiF7DNPWq0zwc6n2IYEPnlorgIcEEM7eW21gexXwfx1dDWpL+EFNm39KNb ajXw== X-Gm-Message-State: ALoCoQk5eJW6ch76nPcda3dnMEnRBTc5UAxgmedqiToBKiv1LruPugt2ZPsh9uatkGcCfm2yEWWfM0r05AB2cYcoBHeVAQq7IKrRMJam5aIRar33JbtVoGIL+oscLAKT4l1SxmbprPpb X-Received: by 10.107.136.106 with SMTP id k103mr3292466iod.187.1446648020914; Wed, 04 Nov 2015 06:40:20 -0800 (PST) X-Received: by 10.107.136.106 with SMTP id k103mr3292442iod.187.1446648020687; Wed, 04 Nov 2015 06:40:20 -0800 (PST) Received: from ?IPv6:2601:449:8400:5b37:ed22:128b:ec37:8b83? ([2601:449:8400:5b37:ed22:128b:ec37:8b83]) by smtp.gmail.com with ESMTPSA id g12sm9360923igh.2.2015.11.04.06.40.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 06:40:19 -0800 (PST) References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> In-Reply-To: <20151104104208.GL70452@Space.Net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> X-Mailer: iPad Mail (13B143) From: David Farmer Date: Wed, 4 Nov 2015 08:40:18 -0600 To: Gert Doering Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 14:40:26 -0000 > On Nov 4, 2015, at 04:42, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: >> 2. There is consensus that NPT66 is bad, for some of the reasons give in >> various NAT44/CGN documents. It might be slightly less bad than NAT66, >> since it has slightly fewer of the problems given in those documents. >=20 > I don't think there is consensus on that... otherwise we wouldn't have > published NTP66. Please don't mistake support for publishing a document as support for a tech= nology. The only thing I think is worse than NAT66, and the slightly less objectiona= ble NPT66, are a 1000 slightly and subtly different versions of NAT66. Not p= ublishing a document can ensure we will have those 1000 different versions o= f NAT66, it will not ensure that NAT66 is not deployed. I believe our only hope of a world without NAT66 deployed all over the place= is to define the beast and explain why we think it is a bad idea. Until we= charter the IEP (the Internet Engineering Police) and/or the IEA (the Inter= net Engineering Army) the only weapons we have are words and their power to p= ersuade. =20 We could try to holding or breath until NAT66 goes away, but all that will l= ead too is a bunch of passed-out network engineers on the carpet at the IETF= Plenary.=20 To explain why we think NAT66 is a bad idea, we have to acknowledge it exist= s. Just a with IPv4 our failure to define a standard form of NAT, will not p= revent the deployment of NAT, it will ensure the deployment of subtly incomp= atible and worse versions of NAT. Our only useful way forward is to define N= AT66 and explain why we think it is a bad idea. Thanks. > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? --=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 Wed Nov 4 07:02: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 010CB1B30FF for ; Wed, 4 Nov 2015 07:02:23 -0800 (PST) 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 IHGu4gKR20qC for ; Wed, 4 Nov 2015 07:02:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1D71B30EB for ; Wed, 4 Nov 2015 07:02:21 -0800 (PST) Received: from [192.168.88.235] (host226-63.122-190.riotel.com.ar [190.122.63.226] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA4F1GrC016683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 07:01:19 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> Date: Wed, 4 Nov 2015 12:01:13 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 15:02:23 -0000 I actually agree with what David says below. However, I=E2=80=99d like = to make sure that EVERYWHERE we document any form of IPv6 NAT, we also = document that it is considered harmful. Owen > On Nov 4, 2015, at 11:40 AM, David Farmer wrote: >=20 >=20 >> On Nov 4, 2015, at 04:42, Gert Doering wrote: >>=20 >> Hi, >>=20 >>> On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: >>> 2. There is consensus that NPT66 is bad, for some of the reasons = give in >>> various NAT44/CGN documents. It might be slightly less bad than = NAT66, >>> since it has slightly fewer of the problems given in those = documents. >>=20 >> I don't think there is consensus on that... otherwise we wouldn't = have >> published NTP66. >=20 > Please don't mistake support for publishing a document as support for = a technology. >=20 > The only thing I think is worse than NAT66, and the slightly less = objectionable NPT66, are a 1000 slightly and subtly different versions = of NAT66. Not publishing a document can ensure we will have those 1000 = different versions of NAT66, it will not ensure that NAT66 is not = deployed. >=20 > I believe our only hope of a world without NAT66 deployed all over the = place is to define the beast and explain why we think it is a bad idea. = Until we charter the IEP (the Internet Engineering Police) and/or the = IEA (the Internet Engineering Army) the only weapons we have are words = and their power to persuade. =20 >=20 > We could try to holding or breath until NAT66 goes away, but all that = will lead too is a bunch of passed-out network engineers on the carpet = at the IETF Plenary.=20 >=20 > To explain why we think NAT66 is a bad idea, we have to acknowledge it = exists. Just a with IPv4 our failure to define a standard form of NAT, = will not prevent the deployment of NAT, it will ensure the deployment of = subtly incompatible and worse versions of NAT. Our only useful way = forward is to define NAT66 and explain why we think it is a bad idea. >=20 > Thanks. >=20 >> Gert Doering >> -- NetMaster >> --=20 >> have you enabled IPv6 on something today...? >=20 > --=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 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 4 09:06: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 2582D1B36F2 for ; Wed, 4 Nov 2015 09:06:46 -0800 (PST) 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 qbU_f3qj4-Kn for ; Wed, 4 Nov 2015 09:06:43 -0800 (PST) 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 AEC241B36F1 for ; Wed, 4 Nov 2015 09:06:42 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5BAD962EFF for ; Wed, 4 Nov 2015 18:06:39 +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 F1B4660775 for ; Wed, 4 Nov 2015 18:06:38 +0100 (CET) Received: (qmail 36989 invoked by uid 1007); 4 Nov 2015 18:06:38 +0100 Date: Wed, 4 Nov 2015 18:06:38 +0100 From: Gert Doering To: David Farmer Message-ID: <20151104170638.GU70452@Space.Net> References: <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0bOnQVrRKCQiBNYT" Content-Disposition: inline In-Reply-To: <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 17:06:46 -0000 --0bOnQVrRKCQiBNYT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 04, 2015 at 08:40:18AM -0600, David Farmer wrote: > > On Nov 4, 2015, at 04:42, Gert Doering wrote: > >=20 > >> On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: > >> 2. There is consensus that NPT66 is bad, for some of the reasons give = in > >> various NAT44/CGN documents. It might be slightly less bad than NAT66, > >> since it has slightly fewer of the problems given in those documents. > >=20 > > I don't think there is consensus on that... otherwise we wouldn't have > > published NTP66. >=20 > Please don't mistake support for publishing a document as support for a t= echnology. Oh, there might not be consensus to *like* NPT66, but there definitely is no consensus that "it is bad" either. I, for one, would object. As do lots of enterprise networks that like to have it in their toolbox. *Mandating* NAT is bad (IPv4, CGN, DS-Lite, ...) - "having tools" is *good*. 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 --0bOnQVrRKCQiBNYT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjo7Ht9WwGXkzn/FAQLAfhAAhepMXGmqogw8p9ogJUw/1peX53Vg3tWr std/o//8M7zq3SmRwNqnicAYdX529U2221S5s1/bnA3GKkEAfy5xeqd5C4XqRGAs 34mylC7ZtrS63ota0CFt3ED7+gfrWD4ddSPFSJJXGHodNVcCaHw3fibXgP0dUQ98 /vK0vSDFpBDchYbagAozf2eKb0IyNDG+XAJNOt4B8/VHieweCDBvFd2KWQuDAhDF uB6YfpUiPu0jG0/nsQY9Rqbn+CAFQrQYWSraqXLqzPf+OWHuWUwZlYVMl0ISOwyk z89d2rKrM+zEgyd7srN5ROggl8bp2aI1ryOiPXPRDVCK9Iag4hS76FOSJlMuBc5z 6pZh8vr7bipQeZXCwZx4UMWoOfXiE/qGxfy/4wzJgDgwuBCnQUIgXqZl/SFIpqAI iQNOiOPpR4nKi5eBcZ6RdOho94tAPIJf+ClxUQq+6Fu5qGNsSNlD/BLMa12r3yo8 3kz/ywhwxqhNZ4YlqX9em4bF0au0/HZLXf69MFUscW+DhMoErNYnOTPLJNVcPlXy zI7/i7QK5wQVFjDVOMaAS1CMwJ9vLahV/hh4vLEHNJBHJIZnd25FqqE7Wbiy1OMl S1cJmIfGXGfbMBD94potz8WysUpHbPbFsJ44QHKrpOIvbH3oo/Iu/uoAUtftJrLW D1l8GUmgPEI= =OO+1 -----END PGP SIGNATURE----- --0bOnQVrRKCQiBNYT-- From nobody Wed Nov 4 09:07: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 663B11B2A2D for ; Wed, 4 Nov 2015 09:07:14 -0800 (PST) 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 S51_ODTVpP8Y for ; Wed, 4 Nov 2015 09:07:13 -0800 (PST) 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 4333E1AD363 for ; Wed, 4 Nov 2015 09:07:13 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9498762EFF for ; Wed, 4 Nov 2015 18:07:11 +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 5DE1D60274 for ; Wed, 4 Nov 2015 18:07:11 +0100 (CET) Received: (qmail 37033 invoked by uid 1007); 4 Nov 2015 18:07:11 +0100 Date: Wed, 4 Nov 2015 18:07:11 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151104170711.GV70452@Space.Net> References: <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lPCGCRNctwsjJZmt" Content-Disposition: inline In-Reply-To: <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 17:07:14 -0000 --lPCGCRNctwsjJZmt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 04, 2015 at 12:01:13PM -0300, Owen DeLong wrote: > I actually agree with what David says below. However, I???d like to make = sure that EVERYWHERE we document any form of IPv6 NAT, we also document tha= t it is considered harmful. "That some people in IETF consider it harmful" Please do not speak for me. Gert --=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 --lPCGCRNctwsjJZmt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjo7P99WwGXkzn/FAQIKNhAAhgXYnzPBZo8GG5j1gtR0EJTTZ9ZKhTM9 825cg9j6u/L8ffF+Aox+77ApvrZswGxcDtWeDTWbsGcoM7iXnKQQirbYiYRSsnhD 5WHIyyG7I9dORHiK2uIHJ2VlfhKgGGTCi0Uszfle5RpN7q2FZ2DQZavMcGm79hR1 vnr0kbpJmQGGfx+hVhpzWAo8Jd6RlP1gGtDEEkH9Dhtlo5qPDxeQC3PwNgFJeUi+ 1TKYuquv3aSThz9fEOs2Oav+BVAb0mvS5U38JmJ5PoGomtvxodpHiMxnCbsnJafp zP0GLoJi8W0RYSEWlpCLNE4hm4UG8PqWD8OLdL1Uyg6VznvvV0F71QJHzTfDdg6c l75CCqhHiUrVHIXc/fGGZ/0Vjx3rXqRWx40LPje90zO4/5H3cMAzCt6Ml0wGRjQW RHWPscKmSnWZV5E/gdmRVRNJMH+Ozm/bZF6GPjHqQ7dRzQXiN/4yJhDzpnuW0E9c quc2vuZyKhwGYCjvZ3wSUTx6mxen9MUxdFpYq4uguNnECm193E2pMYhB0+xETR9G 8m+Ap/yQLiIfCsMHTAT1O0u4Ufn5d5ZJRAMBx4z+uScDSt2zIW2jEYiqdJ0Zl7Yb 6qEDpV1DToTVyUVpfnpT5gBjIdPMg0Zxa1Y1rwXkXGgg3qGB2ypfgLM7aCere7s7 rg7Dtv5TLgA= =f7ST -----END PGP SIGNATURE----- --lPCGCRNctwsjJZmt-- From nobody Wed Nov 4 11: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 0CC751A1B59 for ; Wed, 4 Nov 2015 11:38:55 -0800 (PST) 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 AzG1YI1bjQss for ; Wed, 4 Nov 2015 11:38:54 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C02A41A1B48 for ; Wed, 4 Nov 2015 11:38:52 -0800 (PST) Received: from [192.168.2.54] (232.149.220.201.itc.com.ar [201.220.149.232] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA4JbjR1013509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 11:37:51 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151104170711.GV70452@Space.Net> Date: Wed, 4 Nov 2015 16:37:44 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 19:38:55 -0000 > On Nov 4, 2015, at 2:07 PM, Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Nov 04, 2015 at 12:01:13PM -0300, Owen DeLong wrote: >> I actually agree with what David says below. However, I???d like to = make sure that EVERYWHERE we document any form of IPv6 NAT, we also = document that it is considered harmful. >=20 > "That some people in IETF consider it harmful" >=20 > Please do not speak for me. Are you really claiming you can make a case that deployment of NAT is = not harmful? I=E2=80=99m very skeptical that such a case can be made. Owen From nobody Wed Nov 4 11:53: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 A687C1A9075 for ; Wed, 4 Nov 2015 11:52:59 -0800 (PST) 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 ch7SHWamCwgf for ; Wed, 4 Nov 2015 11:52:57 -0800 (PST) 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 A0B9B1A90BD for ; Wed, 4 Nov 2015 11:52:57 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7CDAA60934 for ; Wed, 4 Nov 2015 20:52: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 4026062C66 for ; Wed, 4 Nov 2015 20:52:54 +0100 (CET) Received: (qmail 44806 invoked by uid 1007); 4 Nov 2015 20:52:54 +0100 Date: Wed, 4 Nov 2015 20:52:54 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151104195254.GW70452@Space.Net> References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="20O8YeZZ/OhD4Z1F" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 19:52:59 -0000 --20O8YeZZ/OhD4Z1F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 04, 2015 at 04:37:44PM -0300, Owen DeLong wrote: > >> I actually agree with what David says below. However, I???d like to ma= ke sure that EVERYWHERE we document any form of IPv6 NAT, we also document = that it is considered harmful. > >=20 > > "That some people in IETF consider it harmful" > >=20 > > Please do not speak for me. >=20 > Are you really claiming you can make a case that deployment of NAT is=20 > not harmful? I???m very skeptical that such a case can be made. Widen your mind :-) - and indeed, I am making this case. Multiple different scenarios where NAT is making life much easier (or enabling a solution at all that might not be otherwise possible). And none of this is the trivial case of conflicting RFC1918 IP address=20 usage in enterprise VPN scenarios. Or the case of destination NAT used for load-balancing... (still NAT, even if not N:1 source NAPT). 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 --20O8YeZZ/OhD4Z1F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjpiFd9WwGXkzn/FAQIlAw//ed1H2JKEz4aYWaC/84zmpMwI1MGY5fo2 YFoL4yNVmmQqFTIRXahN2bFuEKXJRulrEZ6hjPQRovRD4doqgC6NjE9aGIMz1owN 3MjMFtKYp+A9/VOdk+MydZeIAtsz8jEqg5Md9pWs7/kYB9YLn+vinMkj3iX9A+n/ SsOpLijpAPp3bPFOibyiJHLiFoC/oRrKI0W/iAiJWwxojURWczGFYoC8vhgZVh1w ipAX2GFuINJ2Ykm10dnCywDuAjMj7zkrLzZaiTH5422hKceP9Y4vqVhricjGerMZ DN2fVf5o6d9I46LMEYJW5xAOBOyifl90ec5shaaJzs5FpGPIh3OAzjGuvayBN4RF tkx+PFV43dEEAU2MCTAniciQnPKvD2yN/ZsBof0bBR6dh8/vWiTOmNfRJeBM23bn NkeUT57TPluKc4kLlDHAwaisFbKF1ZgG/0wpZmS5lyjXJ9OpiA9upl+ajH1wyh/+ Bmv66oLDYMcjQKARfTqvLtKkeakfd6Zx9G2tgLZAT4RnB2Gz3k8eJu5SEa03+s+L 0mwAC1OEq6lDplohUQGkJp1DV3JYREKOUYoShcPlp9+2RWzXHOx5p1geNUI0F8/L VoiRck24NswZ2tR0n5KWkNORVKVSE2KVkorWz6aP2B0OqzWURIjYHZEmeU/Rg/CT JhtZXHa9ItU= =XYqZ -----END PGP SIGNATURE----- --20O8YeZZ/OhD4Z1F-- From nobody Wed Nov 4 12:13: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 8CA191B33EC for ; Wed, 4 Nov 2015 12:13:49 -0800 (PST) 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 m42_HECyBJlA for ; Wed, 4 Nov 2015 12:13:48 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 30BAB1B33EB for ; Wed, 4 Nov 2015 12:13:47 -0800 (PST) Received: from [192.168.2.54] (232.149.220.201.itc.com.ar [201.220.149.232] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA4KCdIl020384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 12:12:45 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151104195254.GW70452@Space.Net> Date: Wed, 4 Nov 2015 17:12:37 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:13:49 -0000 > On Nov 4, 2015, at 4:52 PM, Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Nov 04, 2015 at 04:37:44PM -0300, Owen DeLong wrote: >>>> I actually agree with what David says below. However, I???d like to = make sure that EVERYWHERE we document any form of IPv6 NAT, we also = document that it is considered harmful. >>>=20 >>> "That some people in IETF consider it harmful" >>>=20 >>> Please do not speak for me. >>=20 >> Are you really claiming you can make a case that deployment of NAT is=20= >> not harmful? I???m very skeptical that such a case can be made. >=20 > Widen your mind :-) - and indeed, I am making this case. Multiple > different scenarios where NAT is making life much easier (or enabling > a solution at all that might not be otherwise possible). In IPv6? Such as? Even in IPv4, each and every one of those cases is actually harmful. It = may also come with some benefits which some people may believe outweigh = the harm, but denying that it is also harmful is misguided at best and = deceitful at worst. > And none of this is the trivial case of conflicting RFC1918 IP address=20= > usage in enterprise VPN scenarios. Which doesn=E2=80=99t apply to IPv6. Note that my specific statement was = about IPv6 NAT. > Or the case of destination NAT used for load-balancing... (still NAT, > even if not N:1 source NAPT). Unnecessary in IPv6 and not entirely harmless. Owen From nobody Wed Nov 4 12:14: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 4CC921B33EB for ; Wed, 4 Nov 2015 12:14:12 -0800 (PST) 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 963L_ns8mfLp for ; Wed, 4 Nov 2015 12:14:10 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 4159D1B33DB for ; Wed, 4 Nov 2015 12:14:10 -0800 (PST) Received: by ykdr3 with SMTP id r3so93016968ykd.1 for ; Wed, 04 Nov 2015 12:14:09 -0800 (PST) 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=cw7GjLisnDg9kqGYfS6M6cJfisQzq+Qe0pTPOFbKt+I=; b=rJyMhmT+xK0Uk+c3ZTbo4gi2zPrgd0oLoTTUD2ftfjL3nlGWFTBmGe4QBySGhBbkiC 1Z6XOCCp6rCQrKTTiymzEUTnigib1d7kaxA5mb7xT9+RSDFYSWqL43nv+Olenc1oAqh+ vtMntDj87ElToE0FyFBzrUnIDo4fO5P6Xh21WGOhgPyir3BKt1WDGY1ZADIgK7+difO6 F8KO9N35ocNDWvIRB7Sngp9UvTN3u4iuAYfpyOmLoBT00RqtPnpfFN1f9t9GCtYCUyaw YPJ2wGYMhIIpEcrsiLhJlmugvimC+9hWdYECZC1TwbiRhXnydyuZ6hKAnOZ2INwtNfwx mFpQ== MIME-Version: 1.0 X-Received: by 10.31.158.198 with SMTP id h189mr3791991vke.102.1446668049488; Wed, 04 Nov 2015 12:14:09 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 12:14:09 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 12:14:09 -0800 (PST) In-Reply-To: <20151104195254.GW70452@Space.Net> References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> Date: Thu, 5 Nov 2015 07:14:09 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a11425cf2329ff90523bca70e Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:14:12 -0000 --001a11425cf2329ff90523bca70e Content-Type: text/plain; charset=UTF-8 On 5 Nov 2015 6:53 AM, "Gert Doering" wrote: > > Hi, > > On Wed, Nov 04, 2015 at 04:37:44PM -0300, Owen DeLong wrote: > > >> I actually agree with what David says below. However, I???d like to make sure that EVERYWHERE we document any form of IPv6 NAT, we also document that it is considered harmful. > > > > > > "That some people in IETF consider it harmful" > > > > > > Please do not speak for me. > > > > Are you really claiming you can make a case that deployment of NAT is > > not harmful? I???m very skeptical that such a case can be made. > > Widen your mind :-) - and indeed, I am making this case. Multiple > different scenarios where NAT is making life much easier (or enabling > a solution at all that might not be otherwise possible). > Are people who use it "successfully" aware of the limitations it imposes i.e. those described in RFC2993? Something working doesn't mean it works well, or that the costs imposed by it are immediately obvious or possibly ever obvious if they're externalised costs, that you may indirectly pay (e.g., periodic "bubble" packets to keep NAT sessions alive so that VoIP handsets can receive calls when they're behind a NAT) > And none of this is the trivial case of conflicting RFC1918 IP address > usage in enterprise VPN scenarios. > > Or the case of destination NAT used for load-balancing... (still NAT, > even if not N:1 source NAPT). > Breaks PMTUD because a unicast address isn't being used as a unicast address - an address to identify a unique destination/host. The PMTUD problems would go away if the LB terminated the TCP connections - which has also then restored the unicast address = unique (single) destination property. Regards, Mark. > 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 > --001a11425cf2329ff90523bca70e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Nov 2015 6:53 AM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Wed, Nov 04, 2015 at 04:37:44PM -0300, Owen DeLong wrote:
> > >> I actually agree with what David says below. However, I?= ??d like to make sure that EVERYWHERE we document any form of IPv6 NAT, we = also document that it is considered harmful.
> > >
> > > "That some people in IETF consider it harmful"
> > >
> > > Please do not speak for me.
> >
> > Are you really claiming you can make a case that deployment of NA= T is
> > not harmful? I???m very skeptical that such a case can be made. >
> Widen your mind :-) - and indeed, I am making this case.=C2=A0 Multipl= e
> different scenarios where NAT is making life much easier (or enabling<= br> > a solution at all that might not be otherwise possible).
>

Are people who use it "successfully" aware of the = limitations it imposes i.e. those described in RFC2993?

Something working doesn't mean it works well, or that th= e costs imposed by it are immediately obvious or possibly ever obvious if t= hey're externalised costs, that you may indirectly pay (e.g., periodic = "bubble" packets to keep NAT sessions alive so that VoIP handsets= can receive calls when they're behind a NAT)

> And none of this is the trivial case of conflicting RFC= 1918 IP address
> usage in enterprise VPN scenarios.
>
> Or the case of destination NAT used for load-balancing...=C2=A0 (still= NAT,
> even if not N:1 source NAPT).
>

Breaks PMTUD because a unicast address isn't being used = as a unicast address - an address to identify a unique destination/host.

The PMTUD problems would go away if the LB terminated the TC= P connections - which has also then restored the unicast address =3D unique= (single) destination property.

Regards,
Mark.

> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a11425cf2329ff90523bca70e-- From nobody Wed Nov 4 12:17: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 688951B3400 for ; Wed, 4 Nov 2015 12:17:48 -0800 (PST) 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 PO5L1EK2e371 for ; Wed, 4 Nov 2015 12:17:47 -0800 (PST) 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 354A91B33FD for ; Wed, 4 Nov 2015 12:17:36 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B6D6762F15 for ; Wed, 4 Nov 2015 21:17:34 +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 7783E6099E for ; Wed, 4 Nov 2015 21:17:34 +0100 (CET) Received: (qmail 45662 invoked by uid 1007); 4 Nov 2015 21:17:34 +0100 Date: Wed, 4 Nov 2015 21:17:34 +0100 From: Gert Doering To: Mark Smith Message-ID: <20151104201734.GZ70452@Space.Net> References: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReC6eBXgY35T+BYH" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:17:48 -0000 --ReC6eBXgY35T+BYH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 05, 2015 at 07:14:09AM +1100, Mark Smith wrote: > > Widen your mind :-) - and indeed, I am making this case. Multiple > > different scenarios where NAT is making life much easier (or enabling > > a solution at all that might not be otherwise possible). >=20 > Are people who use it "successfully" aware of the limitations it imposes > i.e. those described in RFC2993? Yes. The most important limitation in these cases is "make sure your documentation is precise". I said before that *imposing* NAT on people is bad, but taking away tools is also bad. And as such, I oppose the statement that there would be IETF consensus on "NAT is bad". In almost all cases, alternative approaches could be used (like, in the loadbalancing case, use a reverse proxy, add extra http headers so the real server can know the real client IP, etc) - but in many cases, these are more expensive or require cooperation by other parties that have no interest. Tool. Useful. By conscenting adults. 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 --ReC6eBXgY35T+BYH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjpn3t9WwGXkzn/FAQJJrQ//Vvt2bjbJH6mSYZF9Q0ePTHoUh4P8hgEf HTsIx3rsyFVP7F2QOdjxRiFyI9R7fzD9XQYYXhiWVB1mO7xj6H7QnaCVEX899Z3a KTx+RydtNcPh23dSYgmn/3klTbA60QwnRuDywEmtccFSBXA0UNMMZlAe1WdzRJWt C2T4qnJ0UiCB+9bN0mNCwrOXWBy2Z1uT8a1vCnFDUIKD8lM8vcLHizSQEkOlAQax +7r15AzbNh3ugkjKDWA1SEh4ok/SlCI8yhQ8olr5UVOiTOjeuJAL3rxMp2PQCq7h vq6oVj2/xyMMmiFacF9gTpXjqRQqdALuDWjmAslXKssRA8Rav642R4doiAXF7sC8 0KhFQXNyqctMykYs2zwnd8BgTtBtVpXaXszykkY5f5KjWETLoUHIkP9yZYhUd3CQ k/Psw/BDmaXsV9U/DnGHg0mKWVirRpSuXuuFAkhg2TPPLk2A/yCEgyprHSwYegZo LOHUzkfER3TbRu3aXyeqDF2bS8j0aLGNnIVbZp7KFmvy9UqcTmiuR3/VCbQ/HMRB /+/BW0l138cDsTVzY81Ejw+h7Ojo4whQASqi9dTlgMvakmJJYO3aiJ7VExgn9Z7O pdMmDR+QpjbNcRpKOfI6+0gMj2mkQ5bTxE9zwB6/yu/nQYonDFv5FSPo7OVxZmub q7DMgjV29xk= =ZvrE -----END PGP SIGNATURE----- --ReC6eBXgY35T+BYH-- From nobody Wed Nov 4 12:19: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 F0CAD1B340C for ; Wed, 4 Nov 2015 12:19:04 -0800 (PST) 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 ckB6L4PQcY9U for ; Wed, 4 Nov 2015 12:19:04 -0800 (PST) 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 B80341B3409 for ; Wed, 4 Nov 2015 12:19:03 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1928462F15 for ; Wed, 4 Nov 2015 21:19:02 +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 C51B660128 for ; Wed, 4 Nov 2015 21:19:01 +0100 (CET) Received: (qmail 45724 invoked by uid 1007); 4 Nov 2015 21:19:01 +0100 Date: Wed, 4 Nov 2015 21:19:01 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151104201901.GA70452@Space.Net> References: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n4SASLGpMjXF4n/9" Content-Disposition: inline In-Reply-To: <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:19:05 -0000 --n4SASLGpMjXF4n/9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 04, 2015 at 05:12:37PM -0300, Owen DeLong wrote: > > Or the case of destination NAT used for load-balancing... (still NAT, > > even if not N:1 source NAPT). >=20 > Unnecessary in IPv6 and not entirely harmless. Lots of different ways to build loadbalancer exist, and they all have benefits and drawbacks. Otherwise people would not use all the variants. 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 --n4SASLGpMjXF4n/9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjpoNd9WwGXkzn/FAQKpBxAAkHUzAj0gUIRdvolk/hpwKxIoj2JghWCL FXc/g1/feSlcGdIS8fUt3ZOoOQ4xbvGXXri26stjT2W/Cp4v48Vyo11q3IR9lizE Y8/E6Rx8nlAnSSE4sP+85jywpl+0Viqse/B7SF1GZzBFS74CWQIO1iPWXbUYOOU8 UNOI+QjlnU7PH7G9SKuHmXe7hWmu/0LlEE4TXzjxn3FE4Hk4DIiA9cM3X6zuca6q 3kEcIuNgFhibwrO0qxqIpcaOl8YSEL4CDZDykYcTb6v2OPyxGiDC7IdaKu5Giv9Y MZmIVKu6OnLZ68nXumLAUs26jaWCc/uj3eB4K7r5+PLfL3hLOb2++c1WKkPm0Wvc LHr0MDKA1s13XIHOUG6W4bLyfj9HeumvmKr/VSyTxzu1dRLD1F2OVUHZf+BPdT6l r2IO/6od2FHfnyUEq/WdGocXOq79V4wncm3mAOBMusdIFpYLOsH3cq7qh7dmaXHJ mDdsQfw7/iiNXU35/my9yOX9/fHqGI8ovCRVAl7eiRUi9I+/qJMUWnC8sdy2w2lR hbyVbJrWlUj6bjvOZ1x7tmTOaATQcYGlTXAcC1jNjWGS6X6H7qfsxpXPbo+jtw4W UJFL1hnmqauXcqAH2qc2kqeYpFT0SmGEu9DEYUEiRCAOQyrQowPYRezqSrdgUCTR /IoyyFJ/IkA= =llc9 -----END PGP SIGNATURE----- --n4SASLGpMjXF4n/9-- From nobody Wed Nov 4 12:42: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 4FFDC1A1F16 for ; Wed, 4 Nov 2015 12:42:47 -0800 (PST) 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 isd2_d8tL-VJ for ; Wed, 4 Nov 2015 12:42:46 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0612E1A1EFD for ; Wed, 4 Nov 2015 12:42:45 -0800 (PST) Received: from [192.168.2.54] (232.149.220.201.itc.com.ar [201.220.149.232] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA4KfbHP025053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 12:41:43 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151104201901.GA70452@Space.Net> Date: Wed, 4 Nov 2015 17:41:35 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:42:47 -0000 > On Nov 4, 2015, at 5:19 PM, Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Nov 04, 2015 at 05:12:37PM -0300, Owen DeLong wrote: >>> Or the case of destination NAT used for load-balancing... (still = NAT, >>> even if not N:1 source NAPT). >>=20 >> Unnecessary in IPv6 and not entirely harmless. >=20 > Lots of different ways to build loadbalancer exist, and they all have > benefits and drawbacks. Otherwise people would not use all the = variants. So I notice you completely left out all of the other responses. Does = that mean that we have consensus that NAT in IPv6 is actually harmful? Even in the load balancer case, you=E2=80=99ve admitted there are = drawbacks. Owen From nobody Wed Nov 4 12:56: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 0FD361A6F92 for ; Wed, 4 Nov 2015 12:56:49 -0800 (PST) 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 gNeO_28IlVeM for ; Wed, 4 Nov 2015 12:56:47 -0800 (PST) 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 34EDF1A6F8E for ; Wed, 4 Nov 2015 12:56:46 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 09F6862CF7 for ; Wed, 4 Nov 2015 21:56:42 +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 BB3F960274 for ; Wed, 4 Nov 2015 21:56:41 +0100 (CET) Received: (qmail 47044 invoked by uid 1007); 4 Nov 2015 21:56:41 +0100 Date: Wed, 4 Nov 2015 21:56:41 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151104205641.GD70452@Space.Net> References: <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtP8RSojkinV8wmk" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 20:56:49 -0000 --qtP8RSojkinV8wmk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 04, 2015 at 05:41:35PM -0300, Owen DeLong wrote: > So I notice you completely left out all of the other responses. Does that= mean that we have consensus that NAT in IPv6 is actually harmful? No. It is a tool, which has uses, and drawbacks. Not having the tool available would be harmful. WE HAVE NO CONSENSUS THAT NAT IS HARMFUL. For those that are a bit slow. > Even in the load balancer case, you???ve admitted there are drawbacks. Sure. Breathing has drawbacks. 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 --qtP8RSojkinV8wmk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjpxCd9WwGXkzn/FAQJPAw//fHe2AMR+44rzyT/rCS+jJ9XMPvoRobto 4FS+udG6GVTBG/f3mIdQwudC01w3tAfcWHe0BFypl4C34IrdryaFpVZhqYZi5KlI U9XE7gf/zeO4T5QTY37cTn//n3Jvu1BFA38MwLKRM0j53RT2adw6zgkEm1hUqDJ3 HNem+gR9//vT1hOYzpZQ3sJrzv7EWclAWdqTSxqE3sxv0UZ08BogCftcTIyRpXIj mILwJYF7y0b+vOYNweGriJ6IkBZ0wNiMNju3c3D/2/L0bLrlgrRCgyesgMdzCjSE 05KKAWtpIEZ7SOU0/eIEVN4Vj+2Qyptk6HHU8W+Qrm/Hy8SAGmfC7MEJjmb2zRa7 edvwZTy4kuzfAMAEBv67YHOPuwLxak5VRSDu7wYWUBniXMpwYbf/83Is7aeNOgHr KrBRuh8JTgoYFim+9LJdrzwG5NhjS7x6goDVL/y/oDYHmaRZzvRIGFE6m8frJ+ER EeviDyBV9NE2O2jWLxB5eXt4KDX9k+KeW1MNUe9DhbzCu1dzsYJGhkXf37kbtq8E 7vml8eFms/Ad+a/b3aCv56iuYrmUgXFXUMSqSK3vqLKrLInOqiiphhXUPIPJDBRf UEV1ADIEVSn5oPcnidK55azR9pEdXNUO4HYf3UTCf80wn8OFRtl/W9qIJi7q60aj i/EJ7Pymkow= =7/DE -----END PGP SIGNATURE----- --qtP8RSojkinV8wmk-- From nobody Wed Nov 4 13:05: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 3F0FF1A6FC7 for ; Wed, 4 Nov 2015 13:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 jBeLz8yMyul5 for ; Wed, 4 Nov 2015 13:04:59 -0800 (PST) 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 255941A6FC6 for ; Wed, 4 Nov 2015 13:04:57 -0800 (PST) X-Envelope-To: Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tA4L4tXG073566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Nov 2015 21:04:55 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> From: Nick Hilliard Message-ID: <563A72F7.1080709@foobar.org> Date: Wed, 4 Nov 2015 21:04:55 +0000 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: <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 21:05:01 -0000 On 04/11/2015 15:01, Owen DeLong wrote: > I actually agree with what David says below. However, I’d like to make > sure that EVERYWHERE we document any form of IPv6 NAT, we also document > that it is considered harmful. Just then they came in sight of thirty or forty windmills that rise from that plain. And no sooner did Don Quixote see them that he said to his squire, "Fortune is guiding our affairs better than we ourselves could have wished. Do you see over yonder, friend Sancho, thirty or forty hulking giants? I intend to do battle with them and slay them. With their spoils we shall begin to be rich for this is a righteous war and the removal of so foul a brood from off the face of the earth is a service God will bless." Nick From nobody Wed Nov 4 13:43: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 B4A351B33B0 for ; Wed, 4 Nov 2015 13:43:16 -0800 (PST) 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 RGon7HpY8Y_A for ; Wed, 4 Nov 2015 13:43:15 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 385401B3357 for ; Wed, 4 Nov 2015 13:43:15 -0800 (PST) Received: by ykdr3 with SMTP id r3so97431072ykd.1 for ; Wed, 04 Nov 2015 13:43:14 -0800 (PST) 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=QcRhKhk7ntanCW3v31hzz1xcSc4eBR4Sg9jkAtUt3HE=; b=fW/A6+hPfMxzJkTb2boFemYBNeal8kpr+8remJJ50XhmqAzW9Kd2nnyiP3jaKpBYfZ F9u4OSvxI+ymf7N9jzfUgXmVpsQJVLPmVe77WghqT32QnTpOfLxHUO1xermkx2HoO6EA pHWdDK046o1VUw/fTNarheoQfvUZqFLbG2A4rZ1Ejl+FMWjMD0C6hD2fPxBKylKauI8R msBHDCqC7PpU1G3XHe0QDDt6Q6UBIfuBWmzF1pqzTm4g8zhfZ9SV0deHyNQUg64BGDKV GY/oz0UQn/2wsvql/JZboI0rl2oGrf5KwwN4iL1bitAHDO7Yf+fmFmEQVskpPT2vTeXH +3jA== MIME-Version: 1.0 X-Received: by 10.31.158.198 with SMTP id h189mr4136103vke.102.1446673394132; Wed, 04 Nov 2015 13:43:14 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 13:43:13 -0800 (PST) Received: by 10.103.67.194 with HTTP; Wed, 4 Nov 2015 13:43:13 -0800 (PST) In-Reply-To: <20151104205641.GD70452@Space.Net> References: <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> <20151104205641.GD70452@Space.Net> Date: Thu, 5 Nov 2015 08:43:13 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a11425cf2c36d1b0523bde50b Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 21:43:16 -0000 --001a11425cf2c36d1b0523bde50b Content-Type: text/plain; charset=UTF-8 On 5 Nov 2015 07:57, "Gert Doering" wrote: > > Hi, > > On Wed, Nov 04, 2015 at 05:41:35PM -0300, Owen DeLong wrote: > > So I notice you completely left out all of the other responses. Does that mean that we have consensus that NAT in IPv6 is actually harmful? > > No. It is a tool, which has uses, and drawbacks. Not having the tool > available would be harmful. > > WE HAVE NO CONSENSUS THAT NAT IS HARMFUL. For those that are a bit slow. > Next time you're about to resort to insults, don't. Your not going to convince Owen and I by calling us idiots. (And you'll also have to overcome my 20 years of seeing and encountering NAT limitations over and over again, including the very first time a customer of mine wanted to use it in 1995 because one of the earliest NAT implementations couldn't NAT NetBIOS). > > Even in the load balancer case, you???ve admitted there are drawbacks. > > Sure. Breathing has drawbacks. > 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 > --001a11425cf2c36d1b0523bde50b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Nov 2015 07:57, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Wed, Nov 04, 2015 at 05:41:35PM -0300, Owen DeLong wrote:
> > So I notice you completely left out all of the other responses. D= oes that mean that we have consensus that NAT in IPv6 is actually harmful?<= br> >
> No.=C2=A0 It is a tool, which has uses, and drawbacks.=C2=A0 Not havin= g the tool
> available would be harmful.
>
> WE HAVE NO CONSENSUS THAT NAT IS HARMFUL.=C2=A0 For those that are a b= it slow.
>

Next time you're about to resort to insults, don't. =

Your not going to convince Owen and I by calling us idiots.<= /p>

(And you'll also have to overcome my 20 years of seeing = and encountering NAT limitations over and over again, including the very fi= rst time a customer of mine wanted to use it in 1995 because one of the ear= liest NAT implementations couldn't NAT NetBIOS).

> > Even in the load balancer case, you???ve admitted = there are drawbacks.
>
> Sure.=C2=A0 Breathing has drawbacks.

> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a11425cf2c36d1b0523bde50b-- From nobody Wed Nov 4 13:44: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 F25361B340B for ; Wed, 4 Nov 2015 13:44:50 -0800 (PST) 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 aFCv35z1xfhb for ; Wed, 4 Nov 2015 13:44:49 -0800 (PST) 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 169841B33F2 for ; Wed, 4 Nov 2015 13:44:48 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 40BF560AA4 for ; Wed, 4 Nov 2015 22:44: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 0EB3960A56 for ; Wed, 4 Nov 2015 22:44:47 +0100 (CET) Received: (qmail 49330 invoked by uid 1007); 4 Nov 2015 22:44:46 +0100 Date: Wed, 4 Nov 2015 22:44:46 +0100 From: Gert Doering To: Mark Smith Message-ID: <20151104214446.GG70452@Space.Net> References: <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> <20151104205641.GD70452@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pnOoiv9CBYEgxC/g" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 21:44:51 -0000 --pnOoiv9CBYEgxC/g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 05, 2015 at 08:43:13AM +1100, Mark Smith wrote: > Your not going to convince Owen and I by calling us idiots. There is no way to convince Owen and you. What I'm doing here is to state for the record that there is no consensus. 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 --pnOoiv9CBYEgxC/g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVjp8Tt9WwGXkzn/FAQKn9w/+LV3XGhKL4gFO+vzv4BHkWnJKLHSCyZDc VPKsBBjo87oj9yukIW/hmlroYJsZtXVqQXeWYrqMe3nBmYT6i8XPmKpjyzxxN4ry cZz4OB1Ai1TUEDJ1d87tckyIhykUAbmcX60bRUfs/6+8UqkKQzQq4/80n7FSgSht 1EFeXYnCg1xzGdDwCZsQ7/LemlBYT6NxR/mFcBFgZadRjtCGHCZSHeh6sXtor/Kk RTBs5tkYvvZkKxtIZhpA59WLnhL3k4Njv+HuR6dCXtYp0KVtybCgrygnIl8l8vkl zTrimYLaxcLJyuMtJGypw1iSnl7+UD9z/0ZZkH7aFrA4tVOfDUzqEOZkyP2Guk1n zSlw2K+xBVt39Viw2ygnTHShfCQptlyCd9aBN9GX2ZBARIUZRguonOIcIA13dgJ+ 9GXx0vaXLwVf1Nx7/n857PkVVxGxrBhQfLDu79dSvXsZZwI2TmtKmL5rX9injYPu R+gujUUe4HGpXGXIXBT3rj0Vl47CZC9zmGE6jhrb9z4Wsrg/2+nQr2TFr85I/KKs gZzRw5hpECPtWRFKPxxFmmet3mpXOPhlivj8oVptPdvD1vNcpWsIJtTHvSpMcQ1x 4XY9pfYMKz6/TmrFgy4iWE9LgPRoRiVbAVWo75DJ7Ys9IW96dBrZ+IEUcVIwYDDy 9ERs2BYj2MI= =zQHd -----END PGP SIGNATURE----- --pnOoiv9CBYEgxC/g-- From nobody Wed Nov 4 14:44: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 7B0821B3562 for ; Wed, 4 Nov 2015 14:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 o1L-Sxuh6Z0L for ; Wed, 4 Nov 2015 14:44:44 -0800 (PST) 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 D76A71B3561 for ; Wed, 4 Nov 2015 14:44:44 -0800 (PST) Received: from [22.64.25.171] ([172.56.12.146]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA4MiYDb095435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 22:44:40 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/alternative; boundary=Apple-Mail-62EF2542-D415-42F3-B030-0A7819C5B08D Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Thu, 5 Nov 2015 07:44:28 +0900 Content-Transfer-Encoding: 7bit Message-Id: <02183D7D-19E5-46DE-A5EC-2CB8D27A996A@bogus.com> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> To: "Fred Baker (fred)" Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 22:44:46 -0000 --Apple-Mail-62EF2542-D415-42F3-B030-0A7819C5B08D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Nov 4, 2015, at 21:26, Fred Baker (fred) wrote: >=20 >=20 >> On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti wrote: >>=20 >>> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith wrot= e: >>> It'll also discourage IPv6 adoption if they go away. >>>=20 >>> If people have to pay for IPv6 address space just to use IPv6 they'll ei= ther steal public IPv6 space to use instead, or stick with IPv4 and RFC1918s= . >>>=20 >> I don't think that's a good argument. I think it's more important to pres= erve the architecture and end-to-end than to rush "IPv6" adoption by deployi= ng it the wrong way. If there are reasons we can't use global addresses ever= ywhere (e.g., the inability to multihome), then we need to fix those, and I'= d rather we accept a slightly lower adoption rate as the price of doing it r= ight. >>=20 >> IPv6 adoption seems to be growing just fine at the moment. If NAT is what= you want, use IPv4. >=20 > So, in your mind, the only usage of ULA is NAT. I actually think there are= other uses, such as for addressing cable modems and the like that don't go t= hrough a NAT. Stable interior only prefixes in the absensence of pi. Numbering of temporarily isolated networks sandboxes and so on. Link local o= nly goes so far. > Assume we agree that NAT is evil. Is there a reason uses in which an addre= ss is excluded from inter-network usage is therefore bad? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-62EF2542-D415-42F3-B030-0A7819C5B08D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Nov 4, 2015, at 21:26, Fred Baker (fred) <fred@cisco.com> wrote:


On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Nov 4, 2015= at 6:07 AM, Mark Smith <markzzzsmith@gmail.com> wrote:

It'll also discourage IPv6 adoption if they go a= way.

If people have to pa= y for IPv6 address space just to use IPv6 they'll either steal public IPv6 s= pace to use instead, or stick with IPv4 and RFC1918s.

I don't think that's a good argument. I think it's more important t= o preserve the architecture and end-to-end than to rush "IPv6" adoption by d= eploying it the wrong way. If there are reasons we can't use global addresse= s everywhere (e.g., the inability to multihome), then we need to fix those, a= nd I'd rather we accept a slightly lower adoption rate as the price of doing= it right.

IPv6 ad= option seems to be growing just fine at the moment. If NAT is what you want,= use IPv4.

So, in your mind, the only usage of ULA is NAT. I actually think there ar= e other uses, such as for addressing cable modems and the like that don't go= through a NAT.

Stable interior only p= refixes in the absensence of pi.

Numbering of temporarily= isolated networks sandboxes and so on. Link local only goes so far.

Assume we agree that NAT is evil= . Is there a reason uses in which an address is excluded from inter-network u= sage is therefore bad?
_______________________________________________
v6op= s mailing list
v6ops@ietf.= org
https://www.ietf.org/mailman/listinfo/v6ops
= --Apple-Mail-62EF2542-D415-42F3-B030-0A7819C5B08D-- From nobody Wed Nov 4 14:45: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 2A5F41B356E for ; Wed, 4 Nov 2015 14:45:11 -0800 (PST) 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 Vy5Oj92mxfsp for ; Wed, 4 Nov 2015 14:45:08 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 3FE1A1B3564 for ; Wed, 4 Nov 2015 14:45:08 -0800 (PST) Received: by pacdm15 with SMTP id dm15so41375604pac.3 for ; Wed, 04 Nov 2015 14:45:07 -0800 (PST) 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=+/Ayi7gfw+szUxqqvybRJ/6E3yKP5HE+aIoDpxFwC60=; b=ckZSAfh5Pz+VXKaMQG9YXya/LjcXIG2JYik4d6Ag7pE8hheOe6Jv9kjGPa8h5mA01v gVKVam60SPXfTUJvrMyN0Aiev2EPw1N4uBBEdUO/NisO/GJfn4H0O5wpqQQUQ7yxcwRM O6iHdzHV+Pcn6vpz5MFcGqBqG621TcDs08I+lz4FiV1SWCxPpgzdpXRHUNChtGFTjzdm DW/Nu3b7rwGqTGS4en2zEBAtqHOi5Dwy54lPlQiFoStChAaFax8p2STah72zhX9T6ufw HPvuwMYuG2iTn8/cbMopjDL2tMEvhQORKKDDYR+k2L7l0qf/40BJB1ztu4qK6b4Vko/E Iyww== X-Received: by 10.66.228.199 with SMTP id sk7mr5122056pac.78.1446677107767; Wed, 04 Nov 2015 14:45:07 -0800 (PST) Received: from ?IPv6:2406:e007:4700:1:28cc:dc4c:9703:6781? ([2406:e007:4700:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ey2sm3939755pbd.77.2015.11.04.14.45.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 14:45:06 -0800 (PST) To: Gert Doering , "Howard, Lee" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563A8A76.1040304@gmail.com> Date: Thu, 5 Nov 2015 11:45: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: <20151104104208.GL70452@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 22:45:11 -0000 Going back a bit: On 04/11/2015 23:42, Gert Doering wrote: > Hi, > > On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: >> 2. There is consensus that NPT66 is bad, for some of the reasons give in >> various NAT44/CGN documents. It might be slightly less bad than NAT66, >> since it has slightly fewer of the problems given in those documents. > > I don't think there is consensus on that... otherwise we wouldn't have > published NTP66. There was rough consensus to publish NPTv6 as experimental. There was clearly no consensus to publish it on the standards track. But anyway: that is history now. IMHO we need text in the current draft that not only states that ULA+NPTv6 has drawbacks, but actually summarises them. And states that the IETF has not defined NAT66, and summarises the additional drawbacks that ULA+NAT66 would bring. I believe that most of the information about the drawbacks is already documented, in RFC 6296 itself, RFC 4864, RFC 2993 and maybe elsewehere. There is a good set of references in RFC 6296. However, I don't think any of those references discusses the load balancer drawback. It is mentioned in a different context at http://tools.ietf.org/html/rfc7098#page-10. As it happens, that describes a case where NPTv6 is definitely less harmful than NAPT. (When we say NAT66, are we referring to NAT66 or NAPT66?) Bing already indicated that the authors will add more or less what I suggest. That's really the only change needed, IMHO. I'll save a detailed re-review for the next draft. Brian From nobody Wed Nov 4 15:32: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 5B5FD1B383B for ; Wed, 4 Nov 2015 15:32:43 -0800 (PST) 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 CQvJPfrY1oCe for ; Wed, 4 Nov 2015 15:32:42 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCE1B383C for ; Wed, 4 Nov 2015 15:32:40 -0800 (PST) X-SENDER-IP: 10.136.163.148 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,245,1444708800"; d="scan'208";a="857723322" Received: from unknown (HELO exchpapp07dr.corp.twcable.com) ([10.136.163.148]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 04 Nov 2015 18:25:21 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp07dr.corp.twcable.com (10.136.163.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 18:32:36 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 18:32:36 -0500 From: "Howard, Lee" To: Owen DeLong , Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6I2lgggAAKhZCAALKNAIAAEwiAgAADuICAAPONgIAAKz1VgACZzgD//8UJmIAA+CUA///gKwCAAEKLAIAABdiAgAAjMoCAACoQAIAABD0AgAAFgoCAAAHKgIAABk6AgAC10QA= Date: Wed, 4 Nov 2015 23:32:21 +0000 Message-ID: References: <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21922.002 x-tm-as-result: No--46.078800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 23:32:43 -0000 Observation: the use of the words =B3bad=B2 and =B3harmful=B2 do not advanc= e the cause of a clearer document or finding consensus. I apologize for using such words. We have at least two documents describing limitations of NAT, which are cited in this draft. I think we have consensus on the way we say it, so unless you want to propose new words for this document, stop talking about NAT. In order to advance this document, we need words describing why NPT66 is not as good as native IPv6. The only documentation of that at present is the NPT66 RFC itself, RFC6296 (especially Section 5). I don=B9t recall any arguments against the use of ULA when there is no NAT or NPT being used. Please send text reminding me. Lee On 11/5/15, 5:41 AM, "v6ops on behalf of Owen DeLong" wrote: > >> On Nov 4, 2015, at 5:19 PM, Gert Doering wrote: >> >> Hi, >> >> On Wed, Nov 04, 2015 at 05:12:37PM -0300, Owen DeLong wrote: >>>> Or the case of destination NAT used for load-balancing... (still NAT, >>>> even if not N:1 source NAPT). >>> >>> Unnecessary in IPv6 and not entirely harmless. >> >> Lots of different ways to build loadbalancer exist, and they all have >> benefits and drawbacks. Otherwise people would not use all the >>variants. > >So I notice you completely left out all of the other responses. Does that >mean that we have consensus that NAT in IPv6 is actually harmful? > >Even in the load balancer case, you=B9ve admitted there are drawbacks. > >Owen > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Wed Nov 4 15:33: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 6D12D1B383B for ; Wed, 4 Nov 2015 15:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 SNE7HGHMLIkr for ; Wed, 4 Nov 2015 15:33:53 -0800 (PST) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDAC1B3849 for ; Wed, 4 Nov 2015 15:33:52 -0800 (PST) X-SENDER-IP: 10.136.163.148 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,245,1444708800"; d="scan'208,217";a="857724594" Received: from unknown (HELO exchpapp07dr.corp.twcable.com) ([10.136.163.148]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 04 Nov 2015 18:26:31 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp07dr.corp.twcable.com (10.136.163.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 18:33:49 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 18:33:47 -0500 From: "Howard, Lee" To: Lorenzo Colitti , Mark Smith Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6I2lgggAAKhZCAALKNAIAAEwiAgAADuICAAPONgIAAKz1VgACZzgCAAfsOgA== Date: Wed, 4 Nov 2015 23:33:47 +0000 Message-ID: References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21922.002 x-tm-as-result: No--34.951400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D260BCCFC9D73LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 04 Nov 2015 23:33:55 -0000 --_000_D260BCCFC9D73LeeHowardtwcablecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: v6ops > on beha= lf of Lorenzo Colitti > Date: Tuesday, November 3, 2015 at 9:18 PM To: Mark Smith > Cc: 'IPv6 Operations' > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? I'd rather we accept a slightly lower adoption rate as the price of doing = it right. Speaking only as an operator, I disagree. Operators need IPv6 to be universally adopted before they run out of IPv4 a= ddresses. Otherwise, they will have to deploy some form of NAT. Your argument says that any of the set of NAT444 or address family transiti= on service is preferable to ULA (which, especially in the absence of NAT66/= NPT66, doesn't make sense to me(. IPv6 adoption seems to be growing just fine at the moment. If NAT is what y= ou want, use IPv4. It is growing, and it's good to see. It is not growing fast enough, or we w= ouldn't need transition technologies or CGN. Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D260BCCFC9D73LeeHowardtwcablecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <52A8257E18475E4DA22FA3BABCDED213@twcable.com> Content-Transfer-Encoding: quoted-printable


From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo = Colitti <lorenzo@google.com>= ;
Date: Tuesday, November 3, 2015 at = 9:18 PM
To: Mark Smith <markzzzsmith@gmail.com>
Cc: 'IPv6 Operations' <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6o= ps-ula-usage-recommendations - work or abandon?
 I'd rather we accept a slightly lower adoption rate as the price= of doing it right.

Speaking only as an operator, I disagree.
Operators need IPv6 to be universally adopted before they run out of I= Pv4 addresses. Otherwise, they will have to deploy some form of NAT.
Your argument says that any of the set of NAT444 or address family tra= nsition service is preferable to ULA (which, especially in the absence of N= AT66/NPT66, doesn’t make sense to me(.


IPv6 adoption seems to be growing just fine at the moment. If NAT is w= hat you want, use IPv4.

It is growing, and it’s good to see. It is not growing fast enou= gh, or we wouldn’t need transition technologies or CGN.

Lee



This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
 --_000_D260BCCFC9D73LeeHowardtwcablecom_-- From nobody Wed Nov 4 17:03: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 085751B3498 for ; Wed, 4 Nov 2015 17:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 12t9SxCrMEsU for ; Wed, 4 Nov 2015 17:03:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 94CC41B2E47 for ; Wed, 4 Nov 2015 17:03:14 -0800 (PST) Received: from [192.168.2.54] (232.149.220.201.itc.com.ar [201.220.149.232] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA51169J012132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 17:01:10 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_C9AAF3BE-D023-4687-B4F1-BC99AC61BE30" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Wed, 4 Nov 2015 22:01:04 -0300 Message-Id: <5B8E7768-BEF4-4D65-B7CC-D7DCCA096529@delong.com> References: <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <307C3852-01BA-425E-A556-1ACAEC646EFC@delong.com> <20151104201901.GA70452@Space.Net> <20151104205641.GD70452@Space.Net> To: Mark Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:03:18 -0000 --Apple-Mail=_C9AAF3BE-D023-4687-B4F1-BC99AC61BE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gert, There are a number of tools which are harmful and yet still in wide use = for a variety of reasons. I=E2=80=99m not saying NAT is prohibited. I=E2=80=99m not saying the IETF should say NAT is bad. (NAT is bad, but = the IETF probably shouldn=E2=80=99t say so.). Nonetheless, even in the cases where NAT is the best solution, it = remains harmful. At this point, I believe that to be documented fact rather than opinion. Think of it in the same way that, for example, aripiprazole is necessary = and often the only choice of drug that works for some people=E2=80=99s = particular conditions, yet almost universally does cause some harm in = the process. Usually the benefit outweighs the drawbacks or it isn=E2=80=99= t prescribed. Nonetheless, it is considered =E2=80=9Charmful=E2=80=9D. So it=E2=80=99s interesting that while you yourself have acquiesced that = NAT causes harm, you still claim not to agree that NAT is harmful. Owen > On Nov 4, 2015, at 6:43 PM, Mark Smith wrote: >=20 >=20 > On 5 Nov 2015 07:57, "Gert Doering" > wrote: > > > > Hi, > > > > On Wed, Nov 04, 2015 at 05:41:35PM -0300, Owen DeLong wrote: > > > So I notice you completely left out all of the other responses. = Does that mean that we have consensus that NAT in IPv6 is actually = harmful? > > > > No. It is a tool, which has uses, and drawbacks. Not having the = tool > > available would be harmful. > > > > WE HAVE NO CONSENSUS THAT NAT IS HARMFUL. For those that are a bit = slow. > > >=20 > Next time you're about to resort to insults, don't. >=20 > Your not going to convince Owen and I by calling us idiots. >=20 > (And you'll also have to overcome my 20 years of seeing and = encountering NAT limitations over and over again, including the very = first time a customer of mine wanted to use it in 1995 because one of = the earliest NAT implementations couldn't NAT NetBIOS). >=20 > > > Even in the load balancer case, you???ve admitted there are = drawbacks. > > > > Sure. Breathing has drawbacks. >=20 > > 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 = > > --Apple-Mail=_C9AAF3BE-D023-4687-B4F1-BC99AC61BE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Gert,

There= are a number of tools which are harmful and yet still in wide use for a = variety of reasons.

I=E2=80=99m not saying NAT is prohibited.
I=E2=80=99m not saying the IETF should say NAT is bad. (NAT = is bad, but the IETF probably shouldn=E2=80=99t say so.).

Nonetheless, even in the = cases where NAT is the best solution, it remains harmful. At this point, = I believe
that to be documented fact rather than = opinion.

Think = of it in the same way that, for example, aripiprazole is necessary and = often the only choice of drug that works for some people=E2=80=99s = particular conditions, yet almost universally does cause some harm in = the process. Usually the benefit outweighs the drawbacks or it isn=E2=80=99= t prescribed. Nonetheless, it is considered =E2=80=9Charmful=E2=80=9D.

So it=E2=80=99s = interesting that while you yourself have acquiesced that NAT causes = harm, you still claim not to agree that NAT is harmful.

Owen

On Nov 4, 2015, at 6:43 PM, = Mark Smith <markzzzsmith@gmail.com> wrote:


On 5 Nov 2015 07:57, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Wed, Nov 04, 2015 at 05:41:35PM -0300, Owen DeLong wrote:
> > So I notice you completely left out all of the other = responses. Does that mean that we have consensus that NAT in IPv6 is = actually harmful?
>
> No.  It is a tool, which has uses, and drawbacks.  Not = having the tool
> available would be harmful.
>
> WE HAVE NO CONSENSUS THAT NAT IS HARMFUL.  For those that are = a bit slow.
>

Next time you're about to resort to = insults, don't.

Your not going to convince = Owen and I by calling us idiots.

(And = you'll also have to overcome my 20 years of seeing and encountering NAT = limitations over and over again, including the very first time a = customer of mine wanted to use it in 1995 because one of the earliest = NAT implementations couldn't NAT NetBIOS).

> > Even in the load balancer case, you???ve admitted = there are drawbacks.
>
> Sure.  Breathing has drawbacks.

> 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
>


= --Apple-Mail=_C9AAF3BE-D023-4687-B4F1-BC99AC61BE30-- From nobody Wed Nov 4 17:05: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 757781B3528 for ; Wed, 4 Nov 2015 17:05:16 -0800 (PST) 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 x2cz-tnUOr80 for ; Wed, 4 Nov 2015 17:05:14 -0800 (PST) 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 DE3841B3526 for ; Wed, 4 Nov 2015 17:05:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZY06203; Thu, 05 Nov 2015 01:05:11 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 5 Nov 2015 01:05:10 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 5 Nov 2015 09:05:02 +0800 From: "Liubing (Leo)" To: Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFVUaWz4Tcyq930Wi3jgKFnfWJ56I2lgggAAKhZD//9iUAIAAEwiAgAADt4CAAPONgIAAd9WAgAAG9ACAAEZCAIAAnv4z//+YFYCAAGZGAIAAygMAgACs2wA= Date: Thu, 5 Nov 2015 01:05:01 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231A544@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <563A8A76.1040304@gmail.com> In-Reply-To: <563A8A76.1040304@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.185.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.563AAB47.00CF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4633bbab830c6171c31e2aaa515f0135 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:05:16 -0000 Hi Brian, Thanks for your constructive suggestions. And I expect your detailed review= of the future version. Thank you in advance. B.R. Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Thursday, November 05, 2015 7:45 AM > To: Gert Doering; Howard, Lee > Cc: v6ops list > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or > abandon? >=20 > Going back a bit: >=20 > On 04/11/2015 23:42, Gert Doering wrote: > > Hi, > > > > On Wed, Nov 04, 2015 at 04:36:05AM +0000, Howard, Lee wrote: > >> 2. There is consensus that NPT66 is bad, for some of the reasons give > >> in various NAT44/CGN documents. It might be slightly less bad than > >> NAT66, since it has slightly fewer of the problems given in those docu= ments. > > > > I don't think there is consensus on that... otherwise we wouldn't have > > published NTP66. >=20 > There was rough consensus to publish NPTv6 as experimental. There was > clearly no consensus to publish it on the standards track. >=20 > But anyway: that is history now. IMHO we need text in the current draft t= hat > not only states that ULA+NPTv6 has drawbacks, but actually summarises the= m. > And states that the IETF has not defined NAT66, and summarises the additi= onal > drawbacks that ULA+NAT66 would bring. I believe that most of the informat= ion > about the drawbacks is already documented, in RFC 6296 itself, RFC 4864, = RFC > 2993 and maybe elsewehere. There is a good set of references in RFC 6296. >=20 > However, I don't think any of those references discusses the load balance= r > drawback. It is mentioned in a different context at > http://tools.ietf.org/html/rfc7098#page-10. As it happens, that describes= a > case where NPTv6 is definitely less harmful than NAPT. (When we say NAT66= , > are we referring to NAT66 or NAPT66?) >=20 > Bing already indicated that the authors will add more or less what I sugg= est. > That's really the only change needed, IMHO. I'll save a detailed re-revie= w for > the next draft. >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 4 17:05: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 4FA241A21B6 for ; Wed, 4 Nov 2015 17:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 n-luVWyydeYr for ; Wed, 4 Nov 2015 17:05:41 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id B00751ACD62 for ; Wed, 4 Nov 2015 17:05:39 -0800 (PST) Received: from [192.168.2.54] (232.149.220.201.itc.com.ar [201.220.149.232] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tA512Q49012430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 17:02:31 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F6AECB5-02CB-452D-AD68-099725C909F6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <02183D7D-19E5-46DE-A5EC-2CB8D27A996A@bogus.com> Date: Wed, 4 Nov 2015 22:02:25 -0300 Message-Id: <14CD1A69-CBDC-4634-BDED-EA7AC7928935@delong.com> References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <02183D7D-19E5-46DE-A5EC-2CB8D27A996A@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:05:43 -0000 --Apple-Mail=_8F6AECB5-02CB-452D-AD68-099725C909F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 4, 2015, at 7:44 PM, Joel Jaeggli wrote: >=20 >=20 >=20 > Sent from my iPhone >=20 > On Nov 4, 2015, at 21:26, Fred Baker (fred) > wrote: >=20 >>=20 >>> On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti > wrote: >>>=20 >>> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith > wrote: >>> It'll also discourage IPv6 adoption if they go away. >>>=20 >>> If people have to pay for IPv6 address space just to use IPv6 = they'll either steal public IPv6 space to use instead, or stick with = IPv4 and RFC1918s. >>>=20 >>> I don't think that's a good argument. I think it's more important to = preserve the architecture and end-to-end than to rush "IPv6" adoption by = deploying it the wrong way. If there are reasons we can't use global = addresses everywhere (e.g., the inability to multihome), then we need to = fix those, and I'd rather we accept a slightly lower adoption rate as = the price of doing it right. >>>=20 >>> IPv6 adoption seems to be growing just fine at the moment. If NAT is = what you want, use IPv4. >>=20 >> So, in your mind, the only usage of ULA is NAT. I actually think = there are other uses, such as for addressing cable modems and the like = that don't go through a NAT. >=20 > Stable interior only prefixes in the absensence of pi. >=20 > Numbering of temporarily isolated networks sandboxes and so on. Link = local only goes so far. True, but there=E2=80=99s no advantage to using ULA for this over GUA if = you have GUA available. >=20 >> Assume we agree that NAT is evil. Is there a reason uses in which an = address is excluded from inter-network usage is therefore bad? >> _______________________________________________ >> 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 --Apple-Mail=_8F6AECB5-02CB-452D-AD68-099725C909F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 4, 2015, at 7:44 PM, Joel Jaeggli <joelja@bogus.com> = wrote:


Sent from my iPhone

On = Nov 4, 2015, at 21:26, Fred Baker (fred) <fred@cisco.com> = wrote:


On Nov = 4, 2015, at 10:18 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith <markzzzsmith@gmail.com> = wrote:

It'll also discourage IPv6 adoption if they go = away.

If people have = to pay for IPv6 address space just to use IPv6 they'll either steal = public IPv6 space to use instead, or stick with IPv4 and = RFC1918s.

I don't think that's a good = argument. I think it's more important to preserve the architecture and = end-to-end than to rush "IPv6" adoption by deploying it the wrong way. = If there are reasons we can't use global addresses everywhere (e.g., the = inability to multihome), then we need to fix those, and I'd rather we = accept a slightly lower adoption rate as the price of doing it = right.

IPv6 = adoption seems to be growing just fine at the moment. If NAT is what you = want, use IPv4.

So, in your mind, the only usage of ULA = is NAT. I actually think there are other uses, such as for addressing = cable modems and the like that don't go through a = NAT.

Stable = interior only prefixes in the absensence of pi.

Numbering of temporarily isolated = networks sandboxes and so on. Link local only goes so = far.

True, but = there=E2=80=99s no advantage to using ULA for this over GUA if you have = GUA available.



Assume we = agree that NAT is evil. Is there a reason uses in which an address is = excluded from inter-network usage is therefore = bad?
_______________________________________________
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

= --Apple-Mail=_8F6AECB5-02CB-452D-AD68-099725C909F6-- From nobody Wed Nov 4 17:11: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 B32941A0143 for ; Wed, 4 Nov 2015 17:11:02 -0800 (PST) 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 7nzixi0aqsAE for ; Wed, 4 Nov 2015 17:10:58 -0800 (PST) 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 333991B352B for ; Wed, 4 Nov 2015 17:10:58 -0800 (PST) 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 tA51AuIR025723 for ; Thu, 5 Nov 2015 02:10:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37627200EAC for ; Thu, 5 Nov 2015 02:16:56 +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 2EF43200CB8 for ; Thu, 5 Nov 2015 02:16:56 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.3]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tA51Apg4008313 for ; Thu, 5 Nov 2015 02:10:54 +0100 To: v6ops@ietf.org References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> From: Alexandre Petrescu Message-ID: <563AAC9A.6050304@gmail.com> Date: Thu, 5 Nov 2015 10:10:50 +0900 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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:11:02 -0000 Le 05/11/2015 05:14, Mark Smith a écrit : [...] > Are people who use it "successfully" aware of the limitations it imposes > i.e. those described in RFC2993? Which makes think the RFC 2993's section on IPv6 may need update given that now IPv6 NATs do exist, that 6to4 is deprecated, that ULAs substituted site-locals, etc. Alex > > Something working doesn't mean it works well, or that the costs imposed > by it are immediately obvious or possibly ever obvious if they're > externalised costs, that you may indirectly pay (e.g., periodic "bubble" > packets to keep NAT sessions alive so that VoIP handsets can receive > calls when they're behind a NAT) > > > And none of this is the trivial case of conflicting RFC1918 IP address > > usage in enterprise VPN scenarios. > > > > Or the case of destination NAT used for load-balancing... (still NAT, > > even if not N:1 source NAPT). > > > > Breaks PMTUD because a unicast address isn't being used as a unicast > address - an address to identify a unique destination/host. > > The PMTUD problems would go away if the LB terminated the TCP > connections - which has also then restored the unicast address = unique > (single) destination property. > > Regards, > Mark. > > > 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 > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 4 17:23: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 E42C71B35B9 for ; Wed, 4 Nov 2015 17:23:48 -0800 (PST) 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 E4SWAiiEzTyt for ; Wed, 4 Nov 2015 17:23:42 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 78A091B358D for ; Wed, 4 Nov 2015 17:23:41 -0800 (PST) Received: by qgad10 with SMTP id d10so55304506qga.3 for ; Wed, 04 Nov 2015 17:23:40 -0800 (PST) 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=zDV2qy4LLctK57Zbpd3uvot4zw1FV7zP300GHqwKyU0=; b=t+H/oOwEhUiDRNGwpel65LH/p/SNddo25R6ppkdyDmiyY1JDc2OQ1lI0vJ4HTGqUwb C62Bac1Iv+0dNMyHW/zIhN0JS4UgXSO7qTmlP1XNIcBPMVxVqmXppFDPHEPB76GAjjDf dtzAnImto8VE4SsKYvswIg5oo28UGj+xAPLfwTY+ASvRqQyJD+ZKozbIBK4GgWxZP8aS sk2ao1Fp3C6Vl1cYmosqIDFQcrXDMXus/+OxSHEeFYEJF+PguMPqfQI+7ioagVaODt3a eMa/6AcfMkqpsRtAX0cYBy7VrSiTtybJgIhr6hy6kRDP0/Oi/Yct+6Nc5+dEdDHhK1yu 45Qg== 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=zDV2qy4LLctK57Zbpd3uvot4zw1FV7zP300GHqwKyU0=; b=VweyW7euESCD6pv08Ti5tuVWlPyxQNPJqQveHXJ4qLGOVjmab7pGPSjyKxcjIZfa68 llg7dM0qT/2cLziOFYNG4wrhRwiEEFaPWsUwimULpcu5UgUx6i1OpL5nws4yXARtmkW6 x3nHPSymoKku18TdHJEovUOmX1cRTy9w5UVdqcpBw1i5v48a75QR75u7nm0hJGn/vzNU gTzD23cE2XneGXRe5VU0xO7ZA4b9WJ7xXbH4AjjruJnkIG1s1Iruc2G5z5ZmC2kWhV80 UojoMptLeDTfZaVfN9lOt1heCLjm7xLPcLRJr+09nrB/CIbl6J9bKoeTkI+NCvJnLxXC EgIQ== X-Gm-Message-State: ALoCoQlu2KvUKZPjpQvYLWqbbt+nnpRqW5eMM4/7E6KePXEKy3sxVS7x0gqyY30WyCGmyD4Y4Er7 X-Received: by 10.140.31.38 with SMTP id e35mr4738616qge.22.1446686620618; Wed, 04 Nov 2015 17:23:40 -0800 (PST) Received: from [10.82.239.15] ([173.38.117.91]) by smtp.googlemail.com with ESMTPSA id 79sm1053748qkv.23.2015.11.04.17.23.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 17:23:39 -0800 (PST) To: Owen DeLong , Joel Jaeggli References: <563733AF.4010509@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <02183D7D-19E5-46DE-A5EC-2CB8D27A996A@bogus.com> <14CD1A69-CBDC-4634-BDED-EA7AC7928935@delong.com> From: Victor Kuarsingh Message-ID: <563AAF96.7050300@jvknet.com> Date: Thu, 5 Nov 2015 10:23:34 +0900 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: <14CD1A69-CBDC-4634-BDED-EA7AC7928935@delong.com> Content-Type: multipart/alternative; boundary="------------000106070206040601010604" Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:23:49 -0000 This is a multi-part message in MIME format. --------------000106070206040601010604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit >> >> Stable interior only prefixes in the absensence of pi. >> >> Numbering of temporarily isolated networks sandboxes and so on. Link >> local only goes so far. > > True, but there’s no advantage to using ULA for this over GUA if you > have GUA available. > > That's not necessarily true. In past experience, we had a need to nail up temporary networks quickly to test functions, and getting GUA was going to take time (based on procedures) and ULA was available right away. Given the testing was related to network impairments, having immediate access to addressing was beneficial. So GUA was available, but not in the time frame needed. There is also an operational benefit to using ULAs for some functions where the hosts do not need inter-domain reachability. The security perimeter and related policy can be much more stable (requiring less changes as you add space) depending on what GUA space you have access to (as it may not be contiguous). Also, from an front line ops perspective, there is also a very clear visual discriminator that comes in handy (vs. GUAs which can be hard to differentiate as to which are for interior-only functions vs. inter-domain functions.). regards, Victor K >> >>> Assume we agree that NAT is evil. Is there a reason uses in which an >>> address is excluded from inter-network usage is therefore bad? >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------000106070206040601010604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Stable interior only prefixes in the absensence of pi.

Numbering of temporarily isolated networks sandboxes and so on. Link local only goes so far.

True, but there’s no advantage to using ULA for this over GUA if you have GUA available.



That's not necessarily true.  In past experience, we had a need to nail up temporary networks quickly to test functions, and getting GUA was going to take time (based on procedures) and ULA was available right away.  Given the testing was related to network impairments, having immediate access to addressing was beneficial.  So GUA was available, but not in the time frame needed.

There is also an operational benefit to using ULAs for some functions where the hosts do not need inter-domain reachability.  The security perimeter and related policy can be much more stable (requiring less changes as you add space) depending on what GUA space you have access to (as it may not be contiguous).  Also, from an front line ops perspective, there is also a very clear visual discriminator that comes in handy (vs. GUAs which can be hard to differentiate as to which are for interior-only functions vs. inter-domain functions.).

regards,

Victor K



Assume we agree that NAT is evil. Is there a reason uses in which an address is excluded from inter-network usage is therefore bad?
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



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

--------------000106070206040601010604-- From nobody Wed Nov 4 17:31: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 1C4781B3526 for ; Wed, 4 Nov 2015 17:31:22 -0800 (PST) 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 I1djzQCyvlX0 for ; Wed, 4 Nov 2015 17:31:15 -0800 (PST) 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 9EDC61B35B1 for ; Wed, 4 Nov 2015 17:31:15 -0800 (PST) Received: by pabfh17 with SMTP id fh17so69774413pab.0 for ; Wed, 04 Nov 2015 17:31:15 -0800 (PST) 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=QvRB17ingwp5xH36gJSwoFkglI1MwtDgWckbSb+W2YE=; b=aXuxs/vvHiNIV64IE38dXaRZSz+grwEmBY/CEkbWFkAUruVhDCmt8zgd3mCgcB5Fsf UGjBz9VYOjUXFXOtprNKtJAEo0zAEEjSwr0vLFht2cyu+yHdNucbKKyIoQMYXjgW9fIl 2YRIm7BuxoQQeHGpo4ouoFC/oD2ENxBOcVxAA+bQrq1rPQKGIsj5niEQt+2QLZDEeMQb D/30EGRA4GdM0j1I2+STnANLpQtxvyV2AarfxWlud7JQm8As3lF73dtKuwJjl8mYxsGz KG6nwAi9Cd9hD7OqnyTfwt2PPWrLIwrQBctVJye/3NkBbmV9Mi4zppPzQ0RN+AeqnyQy nT+g== X-Received: by 10.68.235.3 with SMTP id ui3mr5853158pbc.168.1446687075169; Wed, 04 Nov 2015 17:31:15 -0800 (PST) Received: from ?IPv6:2406:e007:4700:1:28cc:dc4c:9703:6781? ([2406:e007:4700:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id so4sm4339953pbc.72.2015.11.04.17.31.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 17:31:13 -0800 (PST) To: Alexandre Petrescu , v6ops@ietf.org References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <563AAC9A.6050304@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563AB166.3060109@gmail.com> Date: Thu, 5 Nov 2015 14:31:18 +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: <563AAC9A.6050304@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:31:22 -0000 On 05/11/2015 14:10, Alexandre Petrescu wrote: ... > Which makes think the RFC 2993's section on IPv6 may need update given that now IPv6 NATs do exist, that 6to4 is deprecated, > that ULAs substituted site-locals, etc. I can testify that 6to4 had not been invented when RFC 2993 was written, so its deprecation is hardly relevant. Brian From nobody Wed Nov 4 17:39: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 C82021B360D for ; Wed, 4 Nov 2015 17:39:07 -0800 (PST) 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 6U1Kf7EwwvHa for ; Wed, 4 Nov 2015 17:39:04 -0800 (PST) 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 63E1A1B35A0 for ; Wed, 4 Nov 2015 17:39:03 -0800 (PST) Received: by qgeo38 with SMTP id o38so56114318qge.0 for ; Wed, 04 Nov 2015 17:39:02 -0800 (PST) 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=797kTHYequ+OnSNM2GfSiUt9OZLiRFtEXcylRiw+T54=; b=mNGnZyhVoMgQi3g8tnM58Jx4trY+uxQCqcNP99CcZesWEZauZn4I78LAnFCOQZv8DG oCCzeNPv+IXMgj25xXG89d3m0wuxdAWgXC61bwF8dg1zSFN1KTpCLZCbxXbNR4RsDzYP hLqV1QekQzTs0+PQ6wI1LlGAxdfFh9FWcg96MsSIrPO3vaX5RHAMXRo/f9X/7Vte6wMC 6I2WWRt/A72U4padT4xcPz1PWPuKfYa0/FDlmvwyLO9qCAgwTQXZLWRw8Q3hofViLeJR 31CVgCq9zTeYm8Zp7ZQZXvEolLcMm+OFeWUVqZHR5LT7JSf+9dNmex1eKKxl1vaCj0d9 QlGw== 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=797kTHYequ+OnSNM2GfSiUt9OZLiRFtEXcylRiw+T54=; b=nNwzup0Q9PPnLaaZ0qmVK/P/UXV1q2v/V4/urp35D5h6OLIU9QgQeVevFg24JKVHwz MKiJGUUOIHbd0jPJqXTaiegH7GFvskPFwuBl2HzUga4Tyt+71Gug5tWIQFTgFoVZLxg6 LBWMfa9YQWUHn1s/jHx5sp16W6w+84Rfx5/UZ9JfNivpb8KoFo8bmygnQ6CSnzoBZj+P H6PeBFpxCcyNJOEN6K6KNsxjyVxmaX/fxmOEJOWALmR38Fa+9xfcfblqeRz2p4xdh27D t8OCnvv7lh0qSLy5Jsc500SEE13Bk2gooQSpGVAiaAq45lcNLlHObfZZVwoXyy1jdVjY QEFg== X-Gm-Message-State: ALoCoQl4IH07GZ4GminGqUPoSzWgiAzKI64BWmkUvYHzx/iqrW6GKXXmUmkdyNKmBHjFG3uGMhi6 X-Received: by 10.140.42.16 with SMTP id b16mr4983694qga.78.1446687542525; Wed, 04 Nov 2015 17:39:02 -0800 (PST) Received: from [10.82.239.15] ([173.38.117.91]) by smtp.googlemail.com with ESMTPSA id l33sm1063601qge.22.2015.11.04.17.39.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 17:39:02 -0800 (PST) To: Brian E Carpenter , Gert Doering , "Howard, Lee" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <563A8A76.1040304@gmail.com> From: Victor Kuarsingh Message-ID: <563AB330.2020602@jvknet.com> Date: Thu, 5 Nov 2015 10:38:56 +0900 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: <563A8A76.1040304@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 01:39:07 -0000 On 2015-11-05 7:45 AM, Brian E Carpenter wrote: > But anyway: that is history now. IMHO we need text in the current > draft that not only states that ULA+NPTv6 has drawbacks, but actually > summarises them. And states that the IETF has not defined NAT66, and > summarises the additional drawbacks that ULA+NAT66 would bring. I > believe that most of the information about the drawbacks is already > documented, in RFC 6296 itself, RFC 4864, RFC 2993 and maybe > elsewehere. There is a good set of references in RFC 6296. However, I > don't think any of those references discusses the load balancer > drawback. It is mentioned in a different context at > http://tools.ietf.org/html/rfc7098#page-10. As it happens, that > describes a case where NPTv6 is definitely less harmful than NAPT. > (When we say NAT66, are we referring to NAT66 or NAPT66?) These are good points, however, how do we constructively provide objective information as to the technical drawbacks of a function which is not fully defined (re: NAT66). I heard it noted this week that folks needed to differentiate between NAT66 and NAPT66 (as an example) at mics to then provide further input to the discussion (in v6ops). This lack of definition (of NAT66 and/or its variants) makes it difficult to make a full constructive argument (as we will need to keep repeating/expressing what we mean by NAT66 in each instance , or we just hope everyone has the same reference points - which is unlikely) I can see how we can make the points against NPT66 since we at least have that documented. regards, Victor K > Bing already indicated that the authors will add more or less what I > suggest. That's really the only change needed, IMHO. I'll save a > detailed re-review for the next draft. Brian > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 4 17:41: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 55E971A8769 for ; Wed, 4 Nov 2015 17:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 rrkLlmBklCCW for ; Wed, 4 Nov 2015 17:41:11 -0800 (PST) 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 8DF3B1A8794 for ; Wed, 4 Nov 2015 17:41:11 -0800 (PST) Received: by pasz6 with SMTP id z6so72356556pas.2 for ; Wed, 04 Nov 2015 17:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=Dpx4VxkpjLlxY2dms4oqkhHWf61e4GlvK1ptvT6l2WI=; b=CQ+ToHPKzLurA9N4DN4e8CSbHZNDkjECC8R9uN8k6QOn+E0EVgmKjU7Ei4hIBKor2D EWMhelKyVLGV7JZJtUV0Q+axBdBDulKKpC9sbc1K6C7X23D4mmJr7Oadp98mrDrtoDBf KhzXvG0VTspDsOChNeYBa+5P0fGZlBKV6wnhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=Dpx4VxkpjLlxY2dms4oqkhHWf61e4GlvK1ptvT6l2WI=; b=CmK5XTtVhWLpFlBcEC4ryK0z79fHQs9TlAmSTVszUSB8eeb5UJROvKYxv6pk1dg9sA qo/Wl27Icc5Uj6CMkJ0bpILT28ApOxiqDrv4N2hnFr0c2EY2Q1m/faIXNfG4xvsirAGw 5IKinZcN6ZtnFUmb8lAd3jKcOxtegjB9pc786mntvjpoYvR/Biv0v6HxdrKZoaGYWlG1 NMidlAqLQKfPtPMYVlsKWnS6o/5qZglnOVvhDGTSWNuDdgamV6DAHiN4DZ+BtMXUUE1T m/OZdD8x5A3sHqlhfK/jRKnDiXp7wgqPl6s7TENERXI38lHrubrFucNOPH0AjI9MxN+4 JrBw== X-Gm-Message-State: ALoCoQndFNxKGSVzZS5AiMbyOkpTfFTqYkHOLWMNpJQviX0V2HB4CyfOP792K9j3xGrml0H1H9+AtPdCYx21BdUfGcL7zDzlyVjOvwGbZg8f9RojfuSERsEKgz8rn2trzLaHPmOm9uKCdaibngDdsT2BPFlMkgkfg/C57GmD1gQh+07YuUJZID4= X-Received: by 10.68.135.132 with SMTP id ps4mr5911497pbb.111.1446687671024; Wed, 04 Nov 2015 17:41:11 -0800 (PST) Received: from t20010c4000003024ed296f969d755b01.v6.meeting.ietf94.jp (t20010c4000003024ed296f969d755b01.v6.meeting.ietf94.jp. [2001:c40:0:3024:ed29:6f96:9d75:5b01]) by smtp.gmail.com with ESMTPSA id ou3sm4403648pbb.44.2015.11.04.17.41.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:41:10 -0800 (PST) From: James Woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_B50217F9-CD50-44B8-9304-63F1A0354478" Message-Id: <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Thu, 5 Nov 2015 10:41:07 +0900 References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> To: V6OPS Working Group In-Reply-To: <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.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, 05 Nov 2015 01:41:14 -0000 --Apple-Mail=_B50217F9-CD50-44B8-9304-63F1A0354478 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Everyone=E2=80=94 This draft A) uses normative requirements language with RFC 2119 = keywords and B) calls for publication in the Informational category. Is = the document really intended for the Best Current Practice (BCP) = category? If not, could we please either remove the citation of RFC 2119 = and all the usage of upper case keywords, or insert an explanation for = why the document uses normative requirements language despite being an = Informational category document? =E2=80=94james= --Apple-Mail=_B50217F9-CD50-44B8-9304-63F1A0354478 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Everyone=E2=80=94

This draft A) uses = normative requirements language with RFC 2119 keywords and B) calls for = publication in the Informational category. Is the document really = intended for the Best Current Practice (BCP) category? If not, could we = please either remove the citation of RFC 2119 and all the usage of upper = case keywords, or insert an explanation for why the document uses = normative requirements language despite being an Informational category = document?


=E2=80=94james
= --Apple-Mail=_B50217F9-CD50-44B8-9304-63F1A0354478-- From nobody Wed Nov 4 17:47: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 98D7B1B3608 for ; Wed, 4 Nov 2015 17:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwt3EChQ5lOr for ; Wed, 4 Nov 2015 17:47:29 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428371A882A for ; Wed, 4 Nov 2015 17:47:29 -0800 (PST) Received: from [133.93.28.217] (dhcp-28-217.meeting.ietf94.jp [133.93.28.217]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tA51lGem015877 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2015 17:47:18 -0800 To: "Fred Baker (fred)" , "v6ops@ietf.org WG" References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> From: Erik Nordmark Message-ID: <563AB521.8000309@acm.org> Date: Thu, 5 Nov 2015 10:47:13 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 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 X-Sonic-CAuth: UmFuZG9tSVYG1qtu6NJzGZ2aGynY7vnJjZCUfuT7qlzMXt/3bVMy1F3C4s9Ck5TIX79LJGI9bHO9XWgwwA1FZmqVfoaGvWrR X-Sonic-ID: C;UvuCJF+D5RGHzL0U9jFv0A== M;zpgIJl+D5RGHzL0U9jFv0A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 05 Nov 2015 01:47:30 -0000 [Resent with corrected from address] On 10/2/15 3:39 AM, 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 > > > 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. Fred, I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and fully agreed with the the recommendations in section 4 about implementation and configuration of routers. However, in 01 there was a section added (4.2 - now 5.2) with device side recommendations/requirements, with with I have serious reservations at several levels: 1. The text uses terms like "maintain IPv6 connectivity" and "disconnect from the IPv6 network" which are not defined. I would not know what impact this has on an implementation with those terms being defined. E.g., does "disconnect" mean to discard all IPv6 addresses and prefixes and release all DHCPv6 leases? Kill all connections? What? 2. Section 5.2 changes (or at least clarifies) the IPv6 standards which seems to not be in scope in the v6ops charter. Thus I think section 5.2 should be removed and that discussion be had in the 6man WG. Sorry for not catching the scope expansion in -01 earlier. Regards, Erik > >> 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: >> >> 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 4 18:01: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 2A2D61B3632 for ; Wed, 4 Nov 2015 18:01:25 -0800 (PST) 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 4Um8Bs2DAke1 for ; Wed, 4 Nov 2015 18:01:23 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 ADDE11B3636 for ; Wed, 4 Nov 2015 18:01:23 -0800 (PST) Received: by ykdv3 with SMTP id v3so17355353ykd.0 for ; Wed, 04 Nov 2015 18:01:23 -0800 (PST) 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=ID1XTbZMpbHG1917AD+vIPCsa2dVxrgwraQi9Nmtqac=; b=mj8vugq9DHfx168jx6wtOAOYLPA/bRLNnCwrxzLeYh3TIyX5dzwo9mStFeyuLMQdcA LOln4WtFbCm4gK4ZLH2YxfI3K/9jxG/5ODyE486xP5V2+RmGE0dxrDEHT2Df8stIh6WG OyAjfl5X51MvVob778RqwHqicqpExBYIlkjnPGckK1RCFDZYN/TYVY1ILJr9nFVW7jwM tWPgw5W2/btjjPBEKUrUV4+OgRpEE1TAcbz0ZoOs1xuErbskq6sE3Iqumbt4kXDPI83d HgyzcA8OW3QNxO0Qe5SBaHqNa4zRwAztEllMGLRnZUBlHw4wS0NFfW56Z7mEG9BzqUY/ cZZg== 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=ID1XTbZMpbHG1917AD+vIPCsa2dVxrgwraQi9Nmtqac=; b=Ehhb8W2nNoINpHZ3LYiwbRdrIRJEr19kmUz8u99WoSjGFcRAm5N7uxLWOel2+0KaeF t4Rqfo96aj42eMSINnIJbEPs2G0as4sNdhFJ2+GxUTnKhVNll7/iZTlkGSNb5zFpHcqn qj7H2gijwVzqaL6Gl475hXaSwvGoGLZuL2kbiIdvMLOAeN/IanNB56AV+6+P8Afeqz+V R32ld0pkjrTpO1QmfpcvoMcvvCJ4HW45970fZOBNN/cX6r/3sVy9Bjl3ilNFYvFYLXRg WU/LsGdP6BTlNOTjK/Xgf3ftB892D1ZtyZjkph18iT3GdxaSlX9fDy1f5kKukZxpwD3j j+zA== X-Gm-Message-State: ALoCoQk8Ovbc2SK4qBTcTTWY68Mo8j+7e/jNaV5AZ8ZNvx9XOk0ko2q3/v7/0v/KoEybRgcRqHUX X-Received: by 10.129.136.5 with SMTP id y5mr4492543ywf.35.1446688882914; Wed, 04 Nov 2015 18:01:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Wed, 4 Nov 2015 18:01:03 -0800 (PST) In-Reply-To: <563AB521.8000309@acm.org> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> From: Lorenzo Colitti Date: Thu, 5 Nov 2015 11:01:03 +0900 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a114effbaf7e0dd0523c18000 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, 05 Nov 2015 02:01:25 -0000 --001a114effbaf7e0dd0523c18000 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 5, 2015 at 10:47 AM, Erik Nordmark wrote: > > However, in 01 there was a section added (4.2 - now 5.2) with device side > recommendations/requirements, with with I have serious reservations at > several levels: > 1. The text uses terms like "maintain IPv6 connectivity" and "disconnect > from the IPv6 network" which are not defined. I would not know what impact > this has on an implementation with those terms being defined. E.g., does > "disconnect" mean to discard all IPv6 addresses and prefixes and release > all DHCPv6 leases? Kill all connections? What? > "Maintain IPv6 connectivity" means "maintain the ability to correctly send and receive IPv6 packets as configured by the network". Example: suppose that while a node is asleep a network sends out a number of RAs setting the lifetime of the current default router to 0 and adding another default router, or changing the on-link prefix. The node's IPv6 connectivity is broken until such time that it receives an RA. "Disconnect from the IPv6 network" means whatever process the device would follow when disconnecting from the link. Happy to clarify that in the draft if necessary. 2. Section 5.2 changes (or at least clarifies) the IPv6 standards which > seems to not be in scope in the v6ops charter. Thus I think section 5.2 should be removed and that discussion be had in > the 6man WG. > Section 5.2 changes does not clarify the standards. It provides operational guidance to implementers. It points out that if implementations do not listen to RAs when asleep, then they will lose the ability to correctly send packets off-link, and says that if implementations want avoid that, then they need to listen to RAs. --001a114effbaf7e0dd0523c18000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 5, 2015 at 10:47 AM, Erik Nordmark <nordmark@acm.org>= wrote:
However, in 01 there was a section added (4.2 - now 5.2) with device side r= ecommendations/requirements, with with I have serious reservations at sever= al levels:
1. The text uses terms like "maintain IPv6 connectivity" and &quo= t;disconnect from the IPv6 network" which are not defined. I would not= know what impact this has on an implementation with those terms being defi= ned. E.g., does "disconnect" mean to discard all IPv6 addresses a= nd prefixes and release all DHCPv6 leases? Kill all connections? What?
<= /blockquote>

"Maintain IPv6 connectivity" mean= s "maintain the ability to correctly send and receive IPv6 packets as = configured by the network".

Example: suppose = that while a node is asleep a network sends out a number of RAs setting the= lifetime of the current default router to 0 and adding another default rou= ter, or changing the on-link prefix. The node's IPv6 connectivity is br= oken until such time that it receives an RA.

"= ;Disconnect from the IPv6 network" means whatever process the device w= ould follow when disconnecting from the link.

Happ= y to clarify that in the draft if necessary.

2. Section 5.2 changes (or at least clarifies) the IPv6 standards which see= ms to not be in scope in the v6ops charter.
= Thus I think section 5.2 should be removed and that discussion be had in th= e 6man WG.

Section 5.2 changes does not= clarify the standards. It provides operational guidance to implementers. I= t points out that if implementations do not listen to RAs when asleep, then= they will lose the ability to correctly send packets off-link, and says th= at if implementations want avoid that, then they need to listen to RAs.
--001a114effbaf7e0dd0523c18000-- From nobody Wed Nov 4 18:23: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 6E60A1B38FD for ; Wed, 4 Nov 2015 18:23:33 -0800 (PST) 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 315Fl8hZQUUE for ; Wed, 4 Nov 2015 18:23:32 -0800 (PST) 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 042C31B3691 for ; Wed, 4 Nov 2015 18:23:32 -0800 (PST) Received: by pacdm15 with SMTP id dm15so46939036pac.3 for ; Wed, 04 Nov 2015 18:23:31 -0800 (PST) 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=SKEdIEQ2XeHdgGf3/r9XvIgP4apjVo7ABSGxh5TJgME=; b=XGHlYLRXarWw1h0HEeW54mTJhTxzhw02eYZ2CU/EKXqaTwYX/eETFUeH/d8pAtfXwB KpdrP2TMpdRsI8xdB+sIwQ/MOb+HKJNEkGZi09Lg/vPpDv3m6AHhGjbAMH4YVj2KLRLn zAADC8Q7fNbyZLdsICbIYSdxjHzHFj7gUV12tSjHdKoP2bmcTZwAp2Ouor+DBEzdFWP5 97aq58vddbmpGuR+O3bJzhWVdcGOWtEyh58jXsAlGhBf3JeYdxmoGrcAUEA4++wBlZHL nZdNAilMc9RCIoS6OE2RszpQIA0TJWYbon1oCkfx+JeSq7ilnMDtXMosFM7yy+r/XbG2 f64w== X-Received: by 10.66.152.134 with SMTP id uy6mr6172856pab.123.1446690211511; Wed, 04 Nov 2015 18:23:31 -0800 (PST) Received: from ?IPv6:2406:e007:4700:1:28cc:dc4c:9703:6781? ([2406:e007:4700:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id st5sm4490365pab.42.2015.11.04.18.23.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 18:23:30 -0800 (PST) To: IPv6 Operations References: <20151103204237.GJ70452@Space.Net> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <20151104195254.GW70452@Space.Net> <563AAC9A.6050304@gmail.com> <563AB166.3060109@gmail.com> <563AB556.8010801@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563ABDA7.1090005@gmail.com> Date: Thu, 5 Nov 2015 15:23:35 +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: <563AB556.8010801@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 02:23:33 -0000 Yes, Alexandre has caught me out. I had completely overlooked that RFC 2993 has a stray reference to 6to4 as work in progress. However, it's beside the main point of that particular paragraph in RFC 2993, which really says that NAPT44 can be useful to allow legacy IPv4 to coexist with IPv6. That has happened, quite regardless of 6to4. Looking at the change made when the 6to4 reference was added: (https://tools.ietf.org/rfcdiff?url2=3Ddraft-iab-nat-implications-06.txt)= I suspect that our thinking was a bit confused at the time. But I don't think it really needs an updated RFC from the IAB. Regards Brian On 05/11/2015 14:48, Alexandre Petrescu wrote: >=20 >=20 > Le 05/11/2015 10:31, Brian E Carpenter a =C3=A9crit : >> On 05/11/2015 14:10, Alexandre Petrescu wrote: >> >> ... >>> Which makes think the RFC 2993's section on IPv6 may need update give= n that now IPv6 NATs do exist, that 6to4 is deprecated, >>> that ULAs substituted site-locals, etc. >> >> I can testify that 6to4 had not been invented when RFC 2993 was writte= n, >> so its deprecation is hardly relevant. >=20 > So they presciently used the word "6to4"... >=20 > Alex >=20 >> >> Brian >> >=20 >=20 From nobody Wed Nov 4 18:36: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 99D2B1B3622 for ; Wed, 4 Nov 2015 18:36:18 -0800 (PST) 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 hyANmXkkNpVK for ; Wed, 4 Nov 2015 18:36:16 -0800 (PST) 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 978581A8951 for ; Wed, 4 Nov 2015 18:36:15 -0800 (PST) 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 CDR39235; Thu, 05 Nov 2015 02:36:13 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 5 Nov 2015 02:36:11 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Thu, 5 Nov 2015 10:36:06 +0800 From: "Liubing (Leo)" To: James Woodyatt , V6OPS Working Group Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.txt Thread-Index: AQHP8bkSnl4Ta4Q1h0SqUF2rOiPn2p6O8tNVgAAOWlA= Date: Thu, 5 Nov 2015 02:36:06 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231A658@nkgeml506-mbx.china.huawei.com> References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> In-Reply-To: <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.185.79] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C231A658nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.563AC09D.009E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 475fc74399a30cb070ee79c983c442be Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.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, 05 Nov 2015 02:36:18 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C231A658nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClRoYW5rcyBmb3IgcmFpc2luZyB0aGlzIGlzc3VlLg0KDQpUaGlzIGRyYWZ0 IG9yaWdpbmFsbHkgaW50ZW5kZWQgdG8gYmUgQkNQLCBidXQgaXQgd2FzIGNoYW5nZWQgdG8gSW5m b3JtYXRpb25hbCBsYXRlciwgYWNjb3JkaW5nIHRvIFdH4oCZcyBjb25zZW5zdXMgYXQgdGhhdCB0 aW1lLg0KVGhlIEJDUCBjYXRlZ29yeSBpbiBjdXJyZW50IGRyYWZ0IHNob3VsZCBiZSBlZGl0b3Jp YWwgaXNzdWUsIEnigJlsbCBmaXggaXQgaW4gdGhlIG5leHQgdmVyc2lvbiwgYXMgd2VsbCBhcyBy ZXBocmFzaW5nIHRoZSBSRkMyMTE5IHdvcmRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCkZy b206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEph bWVzIFdvb2R5YXR0DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDUsIDIwMTUgMTA6NDEgQU0N ClRvOiBWNk9QUyBXb3JraW5nIEdyb3VwDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMtMDQudHh0DQoNCkV2 ZXJ5b25l4oCUDQoNClRoaXMgZHJhZnQgQSkgdXNlcyBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGxh bmd1YWdlIHdpdGggUkZDIDIxMTkga2V5d29yZHMgYW5kIEIpIGNhbGxzIGZvciBwdWJsaWNhdGlv biBpbiB0aGUgSW5mb3JtYXRpb25hbCBjYXRlZ29yeS4gSXMgdGhlIGRvY3VtZW50IHJlYWxseSBp bnRlbmRlZCBmb3IgdGhlIEJlc3QgQ3VycmVudCBQcmFjdGljZSAoQkNQKSBjYXRlZ29yeT8gSWYg bm90LCBjb3VsZCB3ZSBwbGVhc2UgZWl0aGVyIHJlbW92ZSB0aGUgY2l0YXRpb24gb2YgUkZDIDIx MTkgYW5kIGFsbCB0aGUgdXNhZ2Ugb2YgdXBwZXIgY2FzZSBrZXl3b3Jkcywgb3IgaW5zZXJ0IGFu IGV4cGxhbmF0aW9uIGZvciB3aHkgdGhlIGRvY3VtZW50IHVzZXMgbm9ybWF0aXZlIHJlcXVpcmVt ZW50cyBsYW5ndWFnZSBkZXNwaXRlIGJlaW5nIGFuIEluZm9ybWF0aW9uYWwgY2F0ZWdvcnkgZG9j dW1lbnQ/DQoNCg0K4oCUamFtZXMNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C231A658nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovk vZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBKYW1lcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzIGZvciByYWlzaW5nIHRoaXMgaXNzdWUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZHJhZnQgb3JpZ2luYWxseSBpbnRlbmRlZCB0byBiZSBC Q1AsIGJ1dCBpdCB3YXMgY2hhbmdlZCB0byBJbmZvcm1hdGlvbmFsIGxhdGVyLCBhY2NvcmRpbmcg dG8gV0figJlzIGNvbnNlbnN1cyBhdCB0aGF0IHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGUgQkNQIGNhdGVnb3J5IGluIGN1cnJlbnQgZHJhZnQgc2hv dWxkIGJlIGVkaXRvcmlhbCBpc3N1ZSwgSeKAmWxsIGZpeCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9u LCBhcyB3ZWxsIGFzIHJlcGhyYXNpbmcgdGhlIFJGQzIxMTkgd29yZHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K YW1lcyBXb29keWF0dDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMDUsIDIw MTUgMTA6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFY2T1BTIFdvcmtpbmcgR3JvdXA8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bGEt dXNhZ2UtcmVjb21tZW5kYXRpb25zLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkV2ZXJ5b25l4oCUPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGJyPg0KVGhpcyBkcmFmdCBBKSB1c2VzIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgbGFu Z3VhZ2Ugd2l0aCBSRkMgMjExOSBrZXl3b3JkcyBhbmQgQikgY2FsbHMgZm9yIHB1YmxpY2F0aW9u IGluIHRoZSBJbmZvcm1hdGlvbmFsIGNhdGVnb3J5LiBJcyB0aGUgZG9jdW1lbnQgcmVhbGx5IGlu dGVuZGVkIGZvciB0aGUgQmVzdCBDdXJyZW50IFByYWN0aWNlIChCQ1ApIGNhdGVnb3J5PyBJZiBu b3QsIGNvdWxkIHdlIHBsZWFzZSBlaXRoZXIgcmVtb3ZlIHRoZSBjaXRhdGlvbg0KIG9mIFJGQyAy MTE5IGFuZCBhbGwgdGhlIHVzYWdlIG9mIHVwcGVyIGNhc2Uga2V5d29yZHMsIG9yIGluc2VydCBh biBleHBsYW5hdGlvbiBmb3Igd2h5IHRoZSBkb2N1bWVudCB1c2VzIG5vcm1hdGl2ZSByZXF1aXJl bWVudHMgbGFuZ3VhZ2UgZGVzcGl0ZSBiZWluZyBhbiBJbmZvcm1hdGlvbmFsIGNhdGVnb3J5IGRv Y3VtZW50Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJRqYW1lczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C231A658nkgeml506mbxchi_-- From nobody Wed Nov 4 20:10: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 EBA831A6F68 for ; Wed, 4 Nov 2015 20:10:37 -0800 (PST) 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 DH9U-oV1eDJb for ; Wed, 4 Nov 2015 20:10:31 -0800 (PST) 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 738DC1A873C for ; Wed, 4 Nov 2015 20:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1764; q=dns/txt; s=iport; t=1446696631; x=1447906231; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xi1JznTQHTrqz4116Miveq+g+M6aTyyMsnGW/hu/Y6A=; b=S8oAHgdh4s/z/VLV07ye9nXmmlM3ImTifofGRmb65PQ+tHRZujv8R5cX fEcjiC9wkRJitW8Fi5hgz8cGWyKlmRCL5Svh8xRcreYlXVtO6EAG0kv00 z+OJ2SgYhUJ68Q4HXUabykVW6vF4WpF0gn4hegqGRD8rDlfW29U6D8eoI 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C5AgCs1TpW/4ENJK1egzuBQga9eQ6BXoYSAoFBOBQBAQEBAQEBgQqENQEBAQMBeQULAgEIGC4yJQIEDgUOiBgIwX8BAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYhkgm6IJIEUAQSWSAGCUYFhiHCBWpZ1g3EBHwFDhARyhBiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="asc'?scan'208";a="41966873" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2015 04:10:30 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA54AUtr005780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 04:10:30 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; Wed, 4 Nov 2015 23:10:29 -0500 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; Wed, 4 Nov 2015 23:10:29 -0500 From: "Fred Baker (fred)" To: Erik Nordmark Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt Thread-Index: AQHRF3/owQdu0txsyUenmT0+e1z/lg== Date: Thu, 5 Nov 2015 04:10:29 +0000 Message-ID: References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB457.20302@sonic.net> In-Reply-To: <563AB457.20302@sonic.net> 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.233.10] Content-Type: multipart/signed; boundary="Apple-Mail=_B3248A5F-AB14-4F73-B1ED-86BA031F97E9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 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, 05 Nov 2015 04:10:38 -0000 --Apple-Mail=_B3248A5F-AB14-4F73-B1ED-86BA031F97E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Nov 5, 2015, at 10:43 AM, Erik Nordmark wrote: >=20 > Thus I think section 5.2 should be removed and that discussion be had = in the 6man WG. Dumb question - is your reservation a charter question or a technical = question? If it's a charter question, one possible resolution would be = to request a supporting 6man consensus statement. If it's technical, = that is a whole different discussion. --Apple-Mail=_B3248A5F-AB14-4F73-B1ED-86BA031F97E9 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 iQIVAwUBVjrWtEayAOS/EQ8MAQIpCQ/9GJKo5XVVk1ZhnVrr56K6eP/NWKkKRMN0 NkmyRbWP4fD+qJAud5tCMDQL8IAts2G/eFqo8OkoiYsVGtNbadTtDgvrD5Y3xH50 j+SGoqJuzJ/LSLhg3BJZTTtA1iUonmKmLMYDWlJdNmt3SMH7aM/aee2oMFjYjvxh LB7lygzNYoWi40oa4v5Qo8h9TikdXcZOsNNUBhgRZh2wGPVT56f/zrfcicXeo5dP INh6WkCPJquxk21EtoqZVZTaLGE5J0TYrEkCjJjhXcwDkm8HONGSEMHqQFvnUvz5 h5k21txukAZDKpHol1QT2Bvx35rp8wWtHbjURKJK6GuZrjU4GxsISgl9HgJWHs8B JkWUZVK9g3U5BmQqT/tVdSuCnv2VhKZQCnHKIqxnj1rYnvIV5SiRGO0v5ftiLqLU Vh0Sv6HiBiNMER1nIqSHwblkl9VA+a5wTmj883HjEf3Rn1gHD+IfcaLykq6Hba5Y qgQAVrvEDCjKeZcV18eQG9jUiWeDzpumNOBsSTMHjsh/6qcCfKC1EacPvgpYjBxy vkGq2l78145rPXgvSugsZJk+4LasCSLzgJUHRRlcJG9AEer5vvoDAiOymh0tYj/+ yKtTMnybaud5PbVSc1CXD6oAvbfJqG+wF3vAkt54OzaX8ap1W2mNJCQzBT+RGw5K 7i2NrKLKH6M= =G6NT -----END PGP SIGNATURE----- --Apple-Mail=_B3248A5F-AB14-4F73-B1ED-86BA031F97E9-- From nobody Wed Nov 4 20: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 1B5FB1B36B5 for ; Wed, 4 Nov 2015 20:30:10 -0800 (PST) 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, 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 REVjUaAPb_bv for ; Wed, 4 Nov 2015 20:30:08 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id C98B01B3646 for ; Wed, 4 Nov 2015 20:30:08 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 4 Nov 2015 22:30:07 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f181.google.com [209.85.223.181] #+LO+TS+TR X-Umn-Classification: local Received: by iody8 with SMTP id y8so77496343iod.1 for ; Wed, 04 Nov 2015 20:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=AjdkCG8G62VxEVVWRSjLIemlmqWThg1ua2+Kr+cC5kc=; b=ha6+sCRbbsIp8Uqly2elzfkI4+Mis4LXeUDdeViMVW4vhpb6NY/vfaCahfsew/0p/D u0hjToI7eIt+3GSjdCITJxOfeDeCZ2LmFdtk3//oXMeqtCXSnikiWDS04zaaTlXdd9f5 SZYOYHtPfg0miINbKgl/RtvJcuvL4XqxE99G4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=AjdkCG8G62VxEVVWRSjLIemlmqWThg1ua2+Kr+cC5kc=; b=nOFlD0vcXpG2LAtpNOxY5B7HfEjavFDpuItqZG75lsSswJiCQhZS64fcjsDliJJaX0 oLV2I+n13btB+/gsYYjq624kOibDZ/d8dEpFRetfd90KumQkc1Rd1JirMnSDnmXft2hF Ku9oYUeEc+v/WIuXKB2sqWFhYT9jRMrsePPYKqsX4HtP97mQ4SzOGZqzvf6i3lzpz7qW IPKLJWiyv+c8JLJbEZDeQE2RytcYpVygHmdjegIZzw76TXl0X4aSvX7aCxyM2coWtpoF 1BI5zfCKHkuy9u1eCRj4AwcFU5pkgB1mWzixcnNO/LMK9ERmD/jeYUTIBir6xsO/r0Vi XKng== X-Gm-Message-State: ALoCoQmr4E6jvYBzObxh3NU21z/aADPX/uzdNxuoxBy4UUGhZ/0i8Ln7iOkEfLI9URJs87f8aYXFb+gBJKFmOoFdMNES3hMiB4sJpXBS9asMC4v+j3ulda09yLQfv+IdpidhiFdLGO3W X-Received: by 10.107.128.27 with SMTP id b27mr6936972iod.64.1446697807122; Wed, 04 Nov 2015 20:30:07 -0800 (PST) X-Received: by 10.107.128.27 with SMTP id b27mr6936961iod.64.1446697806960; Wed, 04 Nov 2015 20:30:06 -0800 (PST) Received: from x-134-84-0-199.vpn.umn.edu ([2607:ea00:103:4801::47]) by smtp.gmail.com with ESMTPSA id ha7sm10592224igb.5.2015.11.04.20.30.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 20:30:04 -0800 (PST) References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> To: James Woodyatt , V6OPS Working Group From: David Farmer Organization: University of Minnesota Message-ID: <563ADB4B.4070409@umn.edu> Date: Wed, 4 Nov 2015 22:30:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:30:10 -0000 On 11/4/15 19:41 , James Woodyatt wrote: > Everyone— > > This draft A) uses normative requirements language with RFC 2119 > keywords and B) calls for publication in the Informational category. Is > the document really intended for the Best Current Practice (BCP) > category? If not, could we please either remove the citation of RFC 2119 > and all the usage of upper case keywords, or insert an explanation for > why the document uses normative requirements language despite being an > Informational category document? The only use of use upper case RFC2119 keywords in the document are in quotes from other documents. Such use seem appropriate, even if you think upper case RFC2119 keywords are not normally appropriate in an Informational category document. Since quotes using upper case RFC2119 keywords are included I think the citation of RFC 2119 is also appropriate and clarifies their use. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Nov 4 20:45: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 119A41A89FE for ; Wed, 4 Nov 2015 20:45:28 -0800 (PST) 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 arQurAT4kzEp for ; Wed, 4 Nov 2015 20:45:27 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 16B961A90E7 for ; Wed, 4 Nov 2015 20:45:27 -0800 (PST) Received: by ykdr3 with SMTP id r3so112030889ykd.1 for ; Wed, 04 Nov 2015 20:45:26 -0800 (PST) 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=D76nZkZaz3lh2zols+4fnuC/VKFPR83XQzTwLhS795s=; b=QvWqikE/eQ1VWOG5Idb0pIGuK1v+zEegyQRtyasguRe21WCLXRVeC8N7NS0Icw1PUN Cx6boTAtQRcNhp+09fOAWcav8mkqxc9Bt4tb7rss9dr4APQx4YR7Qc6a6zfg3tmrxO6k 4wqIFi6iVR54W9v1+vgH8Cz3xHGd5Wtw5/y6E639pAuqLF310GQueN8x7dBzqU3D4NTp ueQQZS2Ro9v0HBNFCC/P2Pb04kLpbTUt/Tbf6I6GxfA42tzxBydwU/xamW1mZkUcnrPC X/CW3VG4HaeD7vAg1DI6PXDRBoZZTTNz/lbHASJ1ekIK1rcocRhzLVRqBXCo1Lx+SfjW IZwg== 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=D76nZkZaz3lh2zols+4fnuC/VKFPR83XQzTwLhS795s=; b=gBt0U9kfY8oTvxdPrj0Fi7ORcEg+rpe9C6342+Qf84rQGf5M3aB7b2vAlGw7Fgp4W0 Q1HxXqhLnCETmTiTnRiwa4k4/BJuCcnQnXcFfWtCok2k98LhlVg5emmVhZNLhJGqhwNA OKMhyTeI4QL+G76h9Ow1fDXNGGyH9mzCao7QYsvugLOe7izfghKxKL4RVRtdJ1eTEg/Q +4SMwmdKkCWGyWwqDIU7Brl+/0l4FlrlxdxoJHqKh4AesBUViLTMAAghiTEuCEoPO3uw Q9buQ/FT6SU0x13Fnig+RS4HmraRrO3Z95mn+CVkxnUdeoGCxAbZtt5PN0trzQQFNt22 /tmg== X-Gm-Message-State: ALoCoQlT+HDIEYOAIvNZdV/tejWdjL8fi7pdqg6tzKItS8mScfVeaFAImZjopA4SWl7hgNhsmdn7 X-Received: by 10.129.137.198 with SMTP id z189mr4354308ywf.307.1446698726282; Wed, 04 Nov 2015 20:45:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Wed, 4 Nov 2015 20:45:06 -0800 (PST) In-Reply-To: <563AB521.8000309@acm.org> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> From: Lorenzo Colitti Date: Thu, 5 Nov 2015 13:45:06 +0900 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=94eb2c06bf26adc28b0523c3cb07 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, 05 Nov 2015 04:45:28 -0000 --94eb2c06bf26adc28b0523c3cb07 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 5, 2015 at 10:47 AM, Erik Nordmark wrote: > However, in 01 there was a section added (4.2 - now 5.2) with device side > recommendations/requirements, with with I have serious reservations at > several levels: > Erik, are you still in Yokohama? Do you have time to discuss in person to see if we can reach consensus? --94eb2c06bf26adc28b0523c3cb07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 5, 2015 at 10:47 AM, Erik Nordmark <nordmark@acm.org>= wrote:
However, in 01 there was a sectio= n added (4.2 - now 5.2) with device side recommendations/requirements, with= with I have serious reservations at several levels:
<= br>
Erik, are you still in Yokohama? Do you have time to discuss = in person to see if we can reach consensus?
--94eb2c06bf26adc28b0523c3cb07-- From nobody Wed Nov 4 21:33: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 E775B1B39CD for ; Wed, 4 Nov 2015 21:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4HOJDIXIPVv for ; Wed, 4 Nov 2015 21:33:53 -0800 (PST) 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 5D77C1B39C9 for ; Wed, 4 Nov 2015 21:33:53 -0800 (PST) Received: by padhx2 with SMTP id hx2so68174682pad.1 for ; Wed, 04 Nov 2015 21:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dZkRDYuv8p0w0hs5ysckmKcddflgZswEy0Ecbrx1KbU=; b=Q8ORukyp4oOs1YX+Ru3df8Fz6h+OGrKQGqz2pqzrbHNb5KX5KGSi37TRZFnXQqZuHU 7bwNq++XLO/DH7OyjnZQhTZbVOydS++BxCrHIFf1M3LDIjPpu6E/MaYD+O2x3l0trGxL 5YeCrkbv0Nb9yG5s0LnFFlkb6xT0qd+53Az54= 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=dZkRDYuv8p0w0hs5ysckmKcddflgZswEy0Ecbrx1KbU=; b=SDjhQbSjXrBHejKEcmrrNDmP5Pp5nwoGrddUQ0IppVVU4rwnLVWRQPsLsDedp0miML KBKGRw2jZuX83DlWXFhum/2s7VxKtmqoi/V/NawIvBCSsEJPDzgew90wgCMT2cQedI0S BreZu0v5Pmr8zYenTRtKoz620cw4GZYh+UgRk2FcW4KgiA486XBftxw2/Vj+CrfV+My1 CLsJ++emgKfHp7H0yU/9MLN69cFzfPMS0HhV5TOdZoiyUjEXs9M7Tf05AL2eMA41FXLQ /jjcC6ddx6PZA+hsOLyBFs1N1n3S7i8AYthJbRi86uoFm0vQrQ5zQ+RVXh/SZgdFNC0I pzGg== X-Gm-Message-State: ALoCoQlM3gf0vV5jQzrmMaEXxDquDB3/fW9IN53AWuAaH7JBq/hDCo7DvS4EtAypF8eAMK8LRXdt X-Received: by 10.66.254.234 with SMTP id al10mr6987855pad.115.1446701632976; Wed, 04 Nov 2015 21:33:52 -0800 (PST) Received: from t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp (t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp. [2001:c40:0:3024:bcdd:4368:2b0b:79a2]) by smtp.gmail.com with ESMTPSA id xs2sm5282871pbb.75.2015.11.04.21.33.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 21:33:52 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: James Woodyatt In-Reply-To: <563ADB4B.4070409@umn.edu> Date: Thu, 5 Nov 2015 14:33:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <03D76035-B91D-407A-98D0-7D83E73DF319@nestlabs.com> References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> <563ADB4B.4070409@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: V6OPS Working Group Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.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, 05 Nov 2015 05:33:55 -0000 On Nov 5, 2015, at 13:30, David Farmer wrote: >=20 > The only use of use upper case RFC2119 keywords in the document are in = quotes from other documents. Such use seem appropriate, even if you = think upper case RFC2119 keywords are not normally appropriate in an = Informational category document. Since quotes using upper case RFC2119 = keywords are included I think the citation of RFC 2119 is also = appropriate and clarifies their use. Indeed. I didn=92t notice that. The text in section 2, Requirements = Language, doesn=92t actually observe that RFC 2119 keywords only appear = in quotations taken from other Standards Track documents, and hence the = reason that only the ALL CAPS versions of the keywords are interpreted = as normative requirements language. I think, perhaps, more clarification = would have helped. The way I got started down that path was noting the sentence in section = 4.2.1 that reads "Thus this document does not recommend the use of = ULA+NPTv6=94 and thinking, hey, this document actually cites RFC 2119 = and that phrase =93does not recommend=94 looks suspiciously like the RFC = 2119 keyword =93not recommended=94 while not actually being an instance = of it. Furthermore, the exception statement that only the ALL CAPS = versions of the keywords are interpreted as normative requirements = language is a peculiar feature of this draft, not commonly used in other = documents, and the reason for it escaped me at the time. =97james= From nobody Wed Nov 4 22:00: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 A729A1B3A46 for ; Wed, 4 Nov 2015 22:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfmCfwKqeCKZ for ; Wed, 4 Nov 2015 22:00:17 -0800 (PST) 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 B952F1B3A3C for ; Wed, 4 Nov 2015 22:00:17 -0800 (PST) Received: by padhx2 with SMTP id hx2so68874477pad.1 for ; Wed, 04 Nov 2015 22:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3TNER+x7i9dezgtK3Xpb6WswpZzFHU589gMK2uZ78fs=; b=O1poVkR2MIxGB+aa8aKYKwjXbc7ZtlRA/2kvGDLZaFOFK/x+AQGMmt07VftTpGwSGO dYArhOyoIpUOzJ4bbEBh6Ab/MTQQ02QfPN/2DOPd2pUaLe2t3Yx5lfsjVbGoFQQizz1L DnUWGPhJvxOtLVQ2r3Ofpp1IA23XgRVuxBCmM= 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:content-transfer-encoding:message-id:references:to; bh=3TNER+x7i9dezgtK3Xpb6WswpZzFHU589gMK2uZ78fs=; b=dUgJg+FhDGaBKfNIf2cA5A4QExqd8a3ZPIPPBe3zvhzIC6oiuR9VXE/82sCVuEZWI6 rvX9fCTsl7sEcuTIC1pv/TbH0MCfeLLFRJo54/tB1p7n4qVhQrCB86e5JQ31WC6hWcjt dOk9Zp81PAnna2ju5h/0hgQ1jCqWKTYifXAStNeD7DQAmbaU4DLNKJX63DaN7vdTTo2x GJv7MzLdGSWpu3hfTSjSzgT64ILawxaQXqSK4Zki59QJoCDxuW0HLTeZkwlZF2sGg+uD 3cuNcHPy6rmRKRwkxJVwm9mklicMKESDQyj1yCxys/6RNrWt/9iWonNv8dhxXdm0aFmn 6C2g== X-Gm-Message-State: ALoCoQmDgsu3uwPz56ZOOuEjDU1tL0+W+R2sJJ2OQZAlL6RfNICLaVRHe3ODZD6PuRMrkOB8Sc1iS1B1w7s7kcntH/mj0x2ve0PV6NyZ9ugVWE4wtf31RdDRN0KLCrMX+35LvWNo+sCNJeC5ixdxFMCX3onFSYz7JVzUuMyOUcIuv9oPoPbVLvw= X-Received: by 10.67.13.206 with SMTP id fa14mr7178693pad.143.1446703217329; Wed, 04 Nov 2015 22:00:17 -0800 (PST) Received: from t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp (t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp. [2001:c40:0:3024:bcdd:4368:2b0b:79a2]) by smtp.gmail.com with ESMTPSA id rn7sm5490505pab.23.2015.11.04.22.00.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 22:00:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: James Woodyatt In-Reply-To: <563AB521.8000309@acm.org> Date: Thu, 5 Nov 2015 15:00:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.3096.5) 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, 05 Nov 2015 06:00:22 -0000 On Nov 5, 2015, at 10:47, Erik Nordmark wrote: >=20 > I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and = fully agreed with the the recommendations in section 4 about = implementation and configuration of routers. >=20 > However, in 01 there was a section added (4.2 - now 5.2) with device = side recommendations/requirements, with with I have serious reservations = at several levels: > 1. The text uses terms like "maintain IPv6 connectivity" and = "disconnect from the IPv6 network" which are not defined. I would not = know what impact this has on an implementation with those terms being = defined. E.g., does "disconnect" mean to discard all IPv6 addresses and = prefixes and release all DHCPv6 leases? Kill all connections? What? I had to talk verbally with Lorenzo before I understood this properly = that A) =E2=80=9Cmaintain IPv6 connectivity=E2=80=9D means to delegate = either an internal or an external sleep proxy with the task of remaining = =E2=80=9Creachable=E2=80=9D under NUD, e.g. the ECMA ProxyZzzz service = or the Bonjour Sleep Proxy service, and that B) =E2=80=9Cdisconnect from = the IPv6 network=E2=80=9D means to detach from the link, thereby leaving = the set of =E2=80=9Creachable=E2=80=9D nodes under NUD and entailing the = commission of the DNAv6 procedure (RFC 6059) when the host reawakens and = reattaches to the link. Perhaps some wordsmithing would be in order, to use terminology more in = keeping with the language of RFC 6059. > 2. Section 5.2 changes (or at least clarifies) the IPv6 standards = which seems to not be in scope in the v6ops charter. >=20 > Thus I think section 5.2 should be removed and that discussion be had = in the 6man WG. I=E2=80=99m opposed to that suggestion. The practice described in = section 5.2 is necessary today for dealing with behavior of deployed = networks that conform to existing standards. If 6MAN wants to clarify or = improve the ND6 specification to change the need for the behavior = documented here, then that would be splendid, but please count me on the = list of people who prefer not to wait for the deliberations in 6MAN to = resolve successfully before a practical solution to real world problems = can be applied. =E2=80=94james= From nobody Wed Nov 4 23:17: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 210931B3AAB for ; Wed, 4 Nov 2015 23:17:47 -0800 (PST) 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 3d9WVUy6aVoB for ; Wed, 4 Nov 2015 23:17:45 -0800 (PST) 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 84E6D1B3A49 for ; Wed, 4 Nov 2015 23:17:45 -0800 (PST) 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 3F5C11FCAB8; Thu, 5 Nov 2015 07:17:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5CAD4160076; Thu, 5 Nov 2015 07:17:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4887A160031; Thu, 5 Nov 2015 07:17:41 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SCPEMwTqb6s6; Thu, 5 Nov 2015 07:17:41 +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 90B44160076; Thu, 5 Nov 2015 06:40:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 308F23BE9BE0; Thu, 5 Nov 2015 17:40:52 +1100 (EST) To: David Farmer From: Mark Andrews References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> <563ADB4B.4070409@umn.edu> In-reply-to: Your message of "Wed, 04 Nov 2015 22:30:03 -0600." <563ADB4B.4070409@umn.edu> Date: Thu, 05 Nov 2015 17:40:52 +1100 Message-Id: <20151105064052.308F23BE9BE0@rock.dv.isc.org> Archived-At: Cc: V6OPS Working Group Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.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, 05 Nov 2015 07:17:47 -0000 In message <563ADB4B.4070409@umn.edu>, David Farmer writes: > On 11/4/15 19:41 , James Woodyatt wrote: > > Everyone- > > > > This draft A) uses normative requirements language with RFC 2119 > > keywords and B) calls for publication in the Informational category. Is > > the document really intended for the Best Current Practice (BCP) > > category? If not, could we please either remove the citation of RFC 2119 > > and all the usage of upper case keywords, or insert an explanation for > > why the document uses normative requirements language despite being an > > Informational category document? > > The only use of use upper case RFC2119 keywords in the document are in > quotes from other documents. Such use seem appropriate, even if you > think upper case RFC2119 keywords are not normally appropriate in an > Informational category document. Since quotes using upper case RFC2119 > keywords are included I think the citation of RFC 2119 is also > appropriate and clarifies their use. Then you have to think about all use of "must", "should" etc. in terms of RFC2119. For reference I've got drafts which quote documents with RFC2119 semantics but have not cited RFC 2119. There is also nothing preventing the use of RFC 2119 in BCP or INFO documents. The use of RFC 2119 does not imply standard. Mark > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > _______________________________________________ > 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 Wed Nov 4 23:32: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 31EC11B3B27 for ; Wed, 4 Nov 2015 23:32:41 -0800 (PST) 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 tuHQDRL0chBF for ; Wed, 4 Nov 2015 23:32:40 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 183661B3B4F for ; Wed, 4 Nov 2015 23:32:40 -0800 (PST) Received: by ykdv3 with SMTP id v3so26915704ykd.0 for ; Wed, 04 Nov 2015 23:32:39 -0800 (PST) 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=tDwvxDch+BOuzKGjGHzvFtcffpP07sq6oD9Dvj2ZSJs=; b=axsNfGdmQPq0cf7zhJdLsRHpvl+1iiELhnnVLzp5zvN/nZk/T7UpLvU3COLLf2EbXf 63gfnYY3YZ8UtnToiS9DGZnFVrSmA4jqlcpRiKMEna2GGplyS8e9/HUff81m4NdhKdtl yFak1R7O5C4cMkhBxCT2YRjpVFcczJFKnE6BVeDiMJ5WcO2YczItQR04tqHAReMAPUvZ MQcz/Py/IvZBzEsH3Ae4MnOVcpefp8dQ3RTAFSqWMtfXQCiP0NjAuYCLlyvWbB1xz21B 49TVSkoJwKa9FSG3KXDq+LzC7SRBAT57i1re8/TFlhWVN6eSAlQGlgZ9O8EkfuJ8tMVe OXrA== 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=tDwvxDch+BOuzKGjGHzvFtcffpP07sq6oD9Dvj2ZSJs=; b=NTXPbCr1WWnMWCMXY9k2dyr5ZH6sk7aIlvSPVrFDGcPDY10cvLxYxTypWQ07zpmgvv 6CIF+DfFIkvTbRce4VnwrG0sJo3Qoa9Cat37MIOkczYMvzlF/7d2swKfuzcNaYwM0PbM 2MqXxWFOWpIXTsAVUO5tR7WQChe8AWX0gtqsfyO6Vv1Cq/7eJ6QS3wAcG8Tlys8w2Pcm c6EHHhBRm58RQ4XMPnvB31cclMOdP39mI8eJlzCdHMjemqurz3WDrDcT2pLelyBtWqVu 0zqHmxFonwvtCubO3RyKkQSnDHFrI1wN1G+1CCmnH6UF/ZuuwGPd2zzTQFSQWuTKhdrE TAlA== X-Gm-Message-State: ALoCoQmvUWtrYh3uS+ayWQ/c+YGBKCD15nth2bPwXFeE+9uE3QMEM06kGIjkyAhKMM0XodTO1Etz X-Received: by 10.13.246.70 with SMTP id g67mr5703664ywf.116.1446708759282; Wed, 04 Nov 2015 23:32:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Wed, 4 Nov 2015 23:32:19 -0800 (PST) In-Reply-To: <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> From: Lorenzo Colitti Date: Thu, 5 Nov 2015 16:32:19 +0900 Message-ID: To: James Woodyatt , Erik Nordmark Content-Type: multipart/alternative; boundary=94eb2c0338d4b12d480523c62155 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, 05 Nov 2015 07:32:41 -0000 --94eb2c0338d4b12d480523c62155 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt wrote: > I=E2=80=99m opposed to that suggestion. The practice described in section= 5.2 is > necessary today for dealing with behavior of deployed networks that confo= rm > to existing standards. If 6MAN wants to clarify or improve the ND6 > specification to change the need for the behavior documented here, then > that would be splendid, but please count me on the list of people who > prefer not to wait for the deliberations in 6MAN to resolve successfully > before a practical solution to real world problems can be applied. > Erik, James and I worked on this together and I believe we're OK with the following text: 1. Maintaining IPv6 connectivity requires that hosts be able to receive periodic multicast RAs [RFC4861]. Therefore, hosts that process unicast packets sent while they are asleep MUST also process multicast RAs sent while they are asleep. Hosts MAY rate-limit identical RAs if they are sent too frequently. 2. Mobile devices that do not intend to maintain IPv6 connectivity while asleep SHOULD either disconnect from the network, abandoning all IPv6 configuration, or perform DNAv6 procedures [RFC6059] when waking up. Erik, James, can you confirm? Cheers, Lorenzo --94eb2c0338d4b12d480523c62155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 5, 2015 at 3:00 PM, James Woodyatt <jhw@nestlabs.com>= wrote:
I=E2=80=99m opposed to that suggestion. The pra= ctice described in section 5.2 is necessary today for dealing with behavior= of deployed networks that conform to existing standards. If 6MAN wants to = clarify or improve the ND6 specification to change the need for the behavio= r documented here, then that would be splendid, but please count me on the = list of people who prefer not to wait for the deliberations in 6MAN to reso= lve successfully before a practical solution to real world problems can be = applied.

Erik, James and I worked on th= is together and I believe we're OK with the following text:
<= br>
=C2=A0 =C2=A01.=C2=A0 Maintaining IPv6 connectivity requ= ires that hosts be able to
=C2=A0 =C2=A0 =C2=A0 =C2=A0receive per= iodic multicast RAs [RFC4861]. Therefore, hosts that
=C2=A0 =C2= =A0 =C2=A0 =C2=A0process unicast packets sent while they are asleep MUST al= so
=C2=A0 =C2=A0 =C2=A0 =C2=A0process multicast RAs sent while th= ey are asleep. Hosts MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0rate-limit id= entical RAs if they are sent too frequently.

=C2= =A0 =C2=A02.=C2=A0 Mobile devices that do not intend to maintain IPv6 conne= ctivity
=C2=A0 =C2=A0 =C2=A0 =C2=A0while asleep SHOULD either dis= connect from the network, abandoning
=C2=A0 =C2=A0 =C2=A0 =C2=A0a= ll IPv6 configuration, or perform DNAv6 procedures [RFC6059]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0when waking up.

Erik= , James, can you confirm?

Cheers,
Lorenz= o
--94eb2c0338d4b12d480523c62155-- From nobody Thu Nov 5 00:01: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 5E67A1B3BDF for ; Thu, 5 Nov 2015 00:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 pIAxjH13rWz3 for ; Thu, 5 Nov 2015 00:01:40 -0800 (PST) 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 C69981B3BDD for ; Thu, 5 Nov 2015 00:01:40 -0800 (PST) Received: by padhx2 with SMTP id hx2so72232795pad.1 for ; Thu, 05 Nov 2015 00:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=j8bisuzloI0BBBpYllHTOuFodvJKX/V0nYGR02LcE4Y=; b=nX59Z0SZTCXC38F+FKeLNAHFWbL1d8xUWqrp+aD/yBIYmhf1F/gO/OyI3xULV7W6kT thIEe6XlvT8EdLdToI9EOe2osNjjf9FAA25surgjgTjBaCfKtQdklrcBGfpQRQy2+iM0 nqIvNG9iU7pOkBOHpIWnXZqI/gXc9PF3TdlJw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=j8bisuzloI0BBBpYllHTOuFodvJKX/V0nYGR02LcE4Y=; b=fK3QQfsSWNVI4afapfcQXzJ65KW8y+Appw0pUaidst3w4dg6J2Yjlou4u1kkY+esw4 pPAPH4C3/DM/6GdjdpsmBCQTIhnOIQj/u4M7AYm+dvSxD9aOzA+7OUNrZNZoIakgB4M0 5rUGkxdx308jtWg9+JdooPIOAk474fVwdD2CpcjCDii740zJNHWyvaKb9VlLNv4IrbGN WnnAQaokAec33W6lmeq/4xXDnVPWkQS/1uIpLbE3GFLBIh5pfJ5JYwd1CwMPt4Sukc0/ xKRCFUomYiyxLoNrgrLWE2DCOl9bAKPPhHRe31K6eLGXzN+iB4O5wXDnaGrzBR4/fYA8 4Dxg== X-Gm-Message-State: ALoCoQnZzG7ds5OFlWu39CpnODyau12cozUYQerd7xYVktaKgk8m335ZCKiK60Fyz8zedBB42zB0FeOfGt9xJDXqkFcy6CLuNwGiEBdsQnHxEVJemg+gWTdgn3ZOIU9n2/YITCLYWTOfN+c83wWOB9bh4baFBHDfTQyZ4UOcZTYOn4EgaWuEJo8= X-Received: by 10.66.102.1 with SMTP id fk1mr7626466pab.111.1446710500410; Thu, 05 Nov 2015 00:01:40 -0800 (PST) Received: from t20010c4000003024841cc17bc3df3e36.v6.meeting.ietf94.jp (t20010c4000003024841cc17bc3df3e36.v6.meeting.ietf94.jp. [2001:c40:0:3024:841c:c17b:c3df:3e36]) by smtp.gmail.com with ESMTPSA id so4sm6191844pbc.72.2015.11.05.00.01.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 00:01:39 -0800 (PST) From: James Woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_B3E12568-05AF-4A07-AF70-890FBFCF6380" Message-Id: <24B2E4C5-6DA4-4266-827B-D5C42EEA575C@nestlabs.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Thu, 5 Nov 2015 17:01:36 +0900 References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> To: "v6ops@ietf.org WG" In-Reply-To: X-Mailer: Apple Mail (2.3096.5) 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, 05 Nov 2015 08:01:42 -0000 --Apple-Mail=_B3E12568-05AF-4A07-AF70-890FBFCF6380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 5, 2015, at 16:32, Lorenzo Colitti wrote: > On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt > wrote: > I=E2=80=99m opposed to that suggestion. The practice described in = section 5.2 is necessary today for dealing with behavior of deployed = networks that conform to existing standards. If 6MAN wants to clarify or = improve the ND6 specification to change the need for the behavior = documented here, then that would be splendid, but please count me on the = list of people who prefer not to wait for the deliberations in 6MAN to = resolve successfully before a practical solution to real world problems = can be applied. >=20 > Erik, James and I worked on this together and I believe we're OK with = the following text: >=20 > 1. Maintaining IPv6 connectivity requires that hosts be able to > receive periodic multicast RAs [RFC4861]. Therefore, hosts that > process unicast packets sent while they are asleep MUST also > process multicast RAs sent while they are asleep. Hosts MAY > rate-limit identical RAs if they are sent too frequently. >=20 > 2. Mobile devices that do not intend to maintain IPv6 connectivity > while asleep SHOULD either disconnect from the network, = abandoning > all IPv6 configuration, or perform DNAv6 procedures [RFC6059] > when waking up. >=20 > Erik, James, can you confirm? I confirm. I=E2=80=99m tempted to suggest that inserting some subclause = indicators in the second paragraph might improve the clarity. Like so: 2. Mobile devices that do not intend to maintain IPv6 connectivity while asleep SHOULD either A) disconnect from the network, = abandoning all IPv6 configuration, or B) perform DNAv6 procedures [RFC6059] when waking up. =E2=80=94james --Apple-Mail=_B3E12568-05AF-4A07-AF70-890FBFCF6380 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Nov 5, 2015, at 16:32, Lorenzo Colitti <lorenzo@google.com> = wrote:
On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt = <jhw@nestlabs.com> = wrote:
I=E2=80=99m opposed to that suggestion. = The practice described in section 5.2 is necessary today for dealing = with behavior of deployed networks that conform to existing standards. = If 6MAN wants to clarify or improve the ND6 specification to change the = need for the behavior documented here, then that would be splendid, but = please count me on the list of people who prefer not to wait for the = deliberations in 6MAN to resolve successfully before a practical = solution to real world problems can be applied.

Erik, James and I worked on this together and I believe we're = OK with the following text:

   1.  Maintaining IPv6 = connectivity requires that hosts be able to
  =      receive periodic multicast RAs [RFC4861]. Therefore, = hosts that
       process = unicast packets sent while they are asleep MUST also
       process multicast RAs sent while = they are asleep. Hosts MAY
      =  rate-limit identical RAs if they are sent too = frequently.

   2.  Mobile devices that do not intend to = maintain IPv6 connectivity
      =  while asleep SHOULD either disconnect from the network, = abandoning
       all IPv6 = configuration, or perform DNAv6 procedures [RFC6059]
       when waking up.

Erik, James, can you = confirm?

I confirm. I=E2=80=99m tempted to suggest that = inserting some subclause indicators in the second paragraph might = improve the clarity. Like so:

  2.  = Mobile devices that do not intend to maintain IPv6 = connectivity
       while = asleep SHOULD either A) disconnect from the network, = abandoning
       all IPv6 = configuration, or B) perform DNAv6 procedures [RFC6059]
       when waking = up.

=E2=80=94james

= --Apple-Mail=_B3E12568-05AF-4A07-AF70-890FBFCF6380-- From nobody Thu Nov 5 00:13: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 4976C1A0378 for ; Thu, 5 Nov 2015 00:13:56 -0800 (PST) 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 e64MfHy2Koxu for ; Thu, 5 Nov 2015 00:13:55 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 1210C1A01BA for ; Thu, 5 Nov 2015 00:13:55 -0800 (PST) Received: by ykba4 with SMTP id a4so118025531ykb.3 for ; Thu, 05 Nov 2015 00:13:54 -0800 (PST) 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=pfbx2ScNNfeOd7ZMF7vXWtyvM4BDoTXnc1VMX95a/ug=; b=VVz8vMqa/F86Ku/5kFtSqQ7IRmUk12yBNH+K8o7tGU9IOyd9P1F2j5+7A+1WXuWuYj OaJd0zTFtYVnyFNbjt6eu4k8PDh1S40ICwT1I/4kxi8IRB+izJD1zyeVnaDPyORN4RL5 55dwqHSwVTAXcDOXI5jYrMsNjQxjiOHX+ckDIbvLrLxV18OTE3NstOqbBOEnD1hVl4rq hTFojh9bdAv/6MOPcW2skTximKWOuWFvHtyZpjt3hS4Hb4nFIdu6xtlLrLtKs7Ben4pL 4g+YAoF33OLi6xgf9PdZbUFbN1iVsJ4R8BqLt1qfSjdn9eFb8OnYAukGCjp9IOXuzeBi Cvcw== 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=pfbx2ScNNfeOd7ZMF7vXWtyvM4BDoTXnc1VMX95a/ug=; b=fKq5t+aRr1jN9OdwEgv7CVIEdXak09g33obLh23pxNGKelbOdDJr2Qy7YXyx9MQxJb +h/lk5H6gVtBT5w6cPawnpnD3Kfr2XrhmYv0xScsSUbyqo+TGFgt6ZRiPhIJTCrEXdLm pW+iDwnjGhBHQ8Zw3K3pfDA0xLJRoFlJZhXswXOdqvvdoO3eBtWxpOla3pmoLHYlsZrD 77QXEV4AIkagXbPAjcLTsZYt7Z6rARGMQdtZagOisyPoOokwsIQ3ZAtCr2/u4D3MSMBQ tNoq+WPtE5W4jlcFqsLPR2CkKd7WnMynJzbeuZX3ZVMZDijLKBKkinw90Ao3TyqPpisl aevg== X-Gm-Message-State: ALoCoQkpwdkvr5EnMxtU26XO7oQj9p2iOCwb5qcPNXGS+HKMjHS/enchnFQ0GRIKXBJQ8gOUbYHE X-Received: by 10.13.206.65 with SMTP id q62mr4847030ywd.160.1446711234237; Thu, 05 Nov 2015 00:13:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Thu, 5 Nov 2015 00:13:34 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 5 Nov 2015 17:13:34 +0900 Message-ID: To: "Howard, Lee" Content-Type: multipart/alternative; boundary=001a114da6f435fdfc0523c6b5d2 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 08:13:56 -0000 --001a114da6f435fdfc0523c6b5d2 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee wrote: > And so on. It seems pretty clear. Is this language insufficiently strong > for you? What words would you use instead? > I would prefer if we used phrasing of the form " is considered harmful" or " is not recommended". --001a114da6f435fdfc0523c6b5d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 3:18 PM, Howard, Lee <lee.howard@twcable.com&g= t; wrote:
And so on. It seems pretty clear. Is this language insufficiently strong= for you? What words would you use instead?
I would prefer if we used phrasing of the form "<xxx&g= t; is considered harmful" or "<xxx> is not recommended"= ;.
--001a114da6f435fdfc0523c6b5d2-- From nobody Thu Nov 5 01:05: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 0D2391A8AF0 for ; Thu, 5 Nov 2015 01:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 sHvihVdMuwqJ for ; Thu, 5 Nov 2015 01:05:06 -0800 (PST) Received: from cdcipgw02.twcable.com (unknown [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0574B1A8AE4 for ; Thu, 5 Nov 2015 01:05:05 -0800 (PST) X-SENDER-IP: 10.64.163.153 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,246,1444708800"; d="scan'208,217";a="402709462" Received: from unknown (HELO exchpapp12.corp.twcable.com) ([10.64.163.153]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 05 Nov 2015 03:35:11 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp12.corp.twcable.com (10.64.163.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 04:05:04 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 04:05:04 -0500 From: "Howard, Lee" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYD//769AIAACpaAgAAHdwCAAItVAIACvqMAgACUfYA= Date: Thu, 5 Nov 2015 09:05:03 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21922.002 x-tm-as-result: No--36.836500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D2614A6ACA099LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 09:05:13 -0000 --_000_D2614A6ACA099LeeHowardtwcablecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Lorenzo Colitti > Date: Thursday, November 5, 2015 at 4:13 AM To: Lee Howard > Cc: "Liubing (Leo)" >= , 'IPv6 Operations' > Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or a= bandon? On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee > wrote: And so on. It seems pretty clear. Is this language insufficiently strong fo= r you? What words would you use instead? I would prefer if we used phrasing of the form " is considered harmful= " or " is not recommended". You deleted a lot of context, including the text: "(NPT66) is not recommended by the IETF." Can we consider your concern addressed? Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D2614A6ACA099LeeHowardtwcablecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Lorenzo Colitti <lorenzo@google.com>
Date: Thursday, November 5, 2015 at= 4:13 AM
To: Lee Howard <lee.howard@twcable.com>
Cc: "Liubing (Leo)" <<= a href=3D"mailto:leo.liubing@huawei.com">leo.liubing@huawei.com>, 'I= Pv6 Operations' <v6ops@ietf.org>= ;
Subject: Re: [v6ops] draft-ietf-v6o= ps-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee <lee.howard@= twcable.com> wrote:
And so on. It seems pretty clear. Is this language insufficiently strong= for you? What words would you use instead?

I would prefer if we used phrasing of the form "<xxx> is co= nsidered harmful" or "<xxx> is not recommended".

You deleted a lot of context, including the text:

“(NPT66) is not recomm=
ended by the IETF.”
Can we consider your concern addressed?

Lee


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
 --_000_D2614A6ACA099LeeHowardtwcablecom_-- From nobody Thu Nov 5 01:53: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 714A11A90CC for ; Thu, 5 Nov 2015 01:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QGTidde3Mrz for ; Thu, 5 Nov 2015 01:53:04 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515151A90E5 for ; Thu, 5 Nov 2015 01:53:01 -0800 (PST) Received: from [133.93.28.217] (dhcp-28-217.meeting.ietf94.jp [133.93.28.217]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tA59qpg2025458 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Nov 2015 01:52:52 -0800 To: "Fred Baker (fred)" References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB457.20302@sonic.net> From: Erik Nordmark Message-ID: <563B26F2.5010701@acm.org> Date: Thu, 5 Nov 2015 18:52:50 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 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 X-Sonic-CAuth: UmFuZG9tSVbucHSsT1CN45LBWuexC6HPMnwKu+y0bGVROJ2o4VhzYzCQgIlsC5pY43VwEhuehLEYTOQjVSt7/ML9IDSc94nd X-Sonic-ID: C;Ojhd+qKD5RGIvr0U9jFv0A== M;AN2/+qKD5RGIvr0U9jFv0A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 05 Nov 2015 09:53:05 -0000 On 11/5/15 1:10 PM, Fred Baker (fred) wrote: >> On Nov 5, 2015, at 10:43 AM, Erik Nordmark wrote: >> >> Thus I think section 5.2 should be removed and that discussion be had in the 6man WG. > Dumb question - is your reservation a charter question or a technical question? If it's a charter question, one possible resolution would be to request a supporting 6man consensus statement. If it's technical, that is a whole different discussion. FWIW It was both as I specified the technically unclear aspects. Erik From nobody Thu Nov 5 01:56: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 5A6B41A9127 for ; Thu, 5 Nov 2015 01:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLkp1mbd7F9n for ; Thu, 5 Nov 2015 01:56:27 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7407F1A9126 for ; Thu, 5 Nov 2015 01:56:27 -0800 (PST) Received: from [133.93.28.217] (dhcp-28-217.meeting.ietf94.jp [133.93.28.217]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tA59uLKl001384 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Nov 2015 01:56:23 -0800 To: Lorenzo Colitti , James Woodyatt , Erik Nordmark References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> From: Erik Nordmark Message-ID: <563B27C5.60405@acm.org> Date: Thu, 5 Nov 2015 18:56:21 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 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 X-Sonic-CAuth: UmFuZG9tSVbszV06A5iNj93f4rkAfQN37lPVcolzMfJn0W7c+ohzUg+GuY1U5YiSk40yZnJQtj6Tfrsp8UgAMUWO+G4ZU8sm X-Sonic-ID: C;ooS8d6OD5RG+r+K7sH9FTg== M;hqXKeKOD5RG+r+K7sH9FTg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 05 Nov 2015 09:56:28 -0000 On 11/5/15 4:32 PM, Lorenzo Colitti wrote: > > > Erik, James and I worked on this together and I believe we're OK with > the following text: > > 1. Maintaining IPv6 connectivity requires that hosts be able to > receive periodic multicast RAs [RFC4861]. Therefore, hosts that > process unicast packets sent while they are asleep MUST also > process multicast RAs sent while they are asleep. Hosts MAY > rate-limit identical RAs if they are sent too frequently. > > 2. Mobile devices that do not intend to maintain IPv6 connectivity > while asleep SHOULD either disconnect from the network, abandoning > all IPv6 configuration, or perform DNAv6 procedures [RFC6059] > when waking up. > > Erik, James, can you confirm? The above text works for me. #1 captures how we've always thought IPv6 works. And #2 captures that we have DNAv6 for the purposes of quickly re-attaching to a network e.g. when waking up. Erik From nobody Thu Nov 5 07:13: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 ABDBA1B2EB0 for ; Thu, 5 Nov 2015 07:13:30 -0800 (PST) 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 IPKbDu-7-sKP for ; Thu, 5 Nov 2015 07:13:24 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 272041B2EC8 for ; Thu, 5 Nov 2015 07:12:46 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 5 Nov 2015 09:12:39 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f170.google.com [209.85.213.170] #+LO+TS+TR X-Umn-Classification: local Received: by igbhv6 with SMTP id hv6so13012540igb.0 for ; Thu, 05 Nov 2015 07:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=nuL7F00bAnU0PzWXcW//W+Et+tBSAD8sN+hBmuBHmp0=; b=Vl2IqhvAfWFczht+DivtUl7tvwzVe9ntomzQcR6InsV4bKN4NWzchk5uaraJmrxVbG 3r05kkyMNAv+JnePY0zVepvyIcPR6DItREAI+jDHwjb3ZTmdJlq9KFkci40I9sHoEhNY o7L+/UU7wMS6wLasNExTaAy3LVJ/nW1QK40Ks= 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-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=nuL7F00bAnU0PzWXcW//W+Et+tBSAD8sN+hBmuBHmp0=; b=QunDm8GDc/TvWLTU+xqSBgaovFvI8qo5noEj6KbSlfK8W8dDI2C4swBH9cZIyhVXqN 3dsmLkHV445oHGXEQZ9JX4McFCMtjdU820c8GFkPS0zCc6SqtUm+uQNnKcVZgKvPuxWu V9xwmDco5IXQpig/kdBhDhQuj97whPXO8lsnl9iuhfCkz0vBWBXptB1pKAH66rBEP6aC Z4B+V+WKgqSf9ofJjbP3hkvnrx+xDtK9LwJYRsZMQSRqwm9vau6VkJ76F8sI2Va0h636 hfS1SEN4AemS4yanVhi9rRrE9OSqqXCTnU+18FHFbcpLtC3odp1ljOudInZIFU1Kpud7 fmJA== X-Gm-Message-State: ALoCoQm1jtXcb6NCd1+I0o7fo8Bbs2YWCqYSLboYrHgWoIXSsUavIO+EdvMMLwAX9qzdVclnkwDecW6e+ie1st060yxGCED48p9aBQv6UeEoA5clsKR7LBjpVbnqNll8GjLX5R5aiLAq X-Received: by 10.50.78.194 with SMTP id d2mr3603330igx.72.1446736358110; Thu, 05 Nov 2015 07:12:38 -0800 (PST) X-Received: by 10.50.78.194 with SMTP id d2mr3603286igx.72.1446736357737; Thu, 05 Nov 2015 07:12:37 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id k62sm3030256ioi.30.2015.11.05.07.12.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 07:12:36 -0800 (PST) References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-88426400-4985-4660-9AFF-462FA4FE7949 Message-Id: <1D37A3AC-68E8-402B-BE1A-51EC3075A2A1@umn.edu> X-Mailer: iPad Mail (13B143) From: David Farmer Date: Thu, 5 Nov 2015 09:12:36 -0600 To: Lorenzo Colitti 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, 05 Nov 2015 15:13:30 -0000 --Apple-Mail-88426400-4985-4660-9AFF-462FA4FE7949 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable --=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 Nov 5, 2015, at 01:32, Lorenzo Colitti wrote: >=20 >> On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt wrote: >> I=E2=80=99m opposed to that suggestion. The practice described in section= 5.2 is necessary today for dealing with behavior of deployed networks that c= onform to existing standards. If 6MAN wants to clarify or improve the ND6 sp= ecification to change the need for the behavior documented here, then that w= ould be splendid, but please count me on the list of people who prefer not t= o wait for the deliberations in 6MAN to resolve successfully before a practi= cal solution to real world problems can be applied. >=20 > Erik, James and I worked on this together and I believe we're OK with the f= ollowing text: >=20 > 1. Maintaining IPv6 connectivity requires that hosts be able to > receive periodic multicast RAs [RFC4861]. Therefore, hosts that > process unicast packets sent while they are asleep MUST also > process multicast RAs sent while they are asleep. Hosts MAY > rate-limit identical RAs if they are sent too frequently. >=20 > 2. Mobile devices that do not intend to maintain IPv6 connectivity > while asleep SHOULD either disconnect from the network, abandoning > all IPv6 configuration, or perform DNAv6 procedures [RFC6059] > when waking up. >=20 > Erik, James, can you confirm? I still don't understand why this is using the term "mobile device", and the= rest of the text uses "battery-powered host". =20 Thanks= --Apple-Mail-88426400-4985-4660-9AFF-462FA4FE7949 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


-- 
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 &= nbsp;                     &= nbsp;  Email: farmer@umn.edu
Office of Information Technology
University of Minnesota &nb= sp;  
2218 University Ave SE         Phon= e: +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 Nov 5, 2015, at 01:32, Lorenzo C= olitti <lorenzo@google.com> w= rote:

On Thu, Nov 5, 2015 at 3:00 PM,= James Woodyatt <jhw@nestlabs.com> wrote:
I=E2=80= =99m opposed to that suggestion. The practice described in section 5.2 is ne= cessary today for dealing with behavior of deployed networks that conform to= existing standards. If 6MAN wants to clarify or improve the ND6 specificati= on to change the need for the behavior documented here, then that would be s= plendid, but please count me on the list of people who prefer not to wait fo= r the deliberations in 6MAN to resolve successfully before a practical solut= ion to real world problems can be applied.

Erik, James and I worked on this together and I believe we're OK with the= following text:

   1.  Maintai= ning IPv6 connectivity requires that hosts be able to
   = ;    receive periodic multicast RAs [RFC4861]. Therefore, hosts th= at
       process unicast packets sent while t= hey are asleep MUST also
       process multic= ast RAs sent while they are asleep. Hosts MAY
     =  rate-limit identical RAs if they are sent too frequently.
<= br>
   2.  Mobile devices that do not intend to mai= ntain IPv6 connectivity
       while asleep SH= OULD either disconnect from the network, abandoning
    &= nbsp;  all IPv6 configuration, or perform DNAv6 procedures [RFC6059]
       when waking up.

Erik, James, can you confirm?

I still don't understand why this is using the term "mobile devic= e", and the rest of the text uses "battery-powered host".  
<= br>
Thanks
= --Apple-Mail-88426400-4985-4660-9AFF-462FA4FE7949-- From nobody Thu Nov 5 08:06: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 266D41B2BA3 for ; Thu, 5 Nov 2015 08:06:13 -0800 (PST) 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 YXVNE3VgtRJf for ; Thu, 5 Nov 2015 08:06:07 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5981A8FD5 for ; Thu, 5 Nov 2015 08:06:02 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 5 Nov 2015 10:05:56 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f176.google.com [209.85.223.176] #+LO+TS+TR X-Umn-Classification: local Received: by ioll68 with SMTP id l68so95560429iol.3 for ; Thu, 05 Nov 2015 08:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=Tksd1AUl5wo+iVCVJOBccvwVlsFtI+k6F9KPnCa9iEk=; b=Dhdlx39XpRinD4MPt/BVMoaZ9AL1hNCQyE6Dy1eVBwx2gxON0ptRbzNEOcQDdfeHfy ChhKmTILy7NSbPnnfU/kMVSXGcSBD0vqbjfWAQSDWMpmM7y3OUHIWbfeheOlLufjcGin gcV7B7WXTlJbN6BHwRmQ+YKwVurrxNyAGIGzY= 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-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=Tksd1AUl5wo+iVCVJOBccvwVlsFtI+k6F9KPnCa9iEk=; b=EEX8Hf7S4h5VEAMxx7xWNkD5B6Lt2hAkzGp6FYiq7z5WB1qEmRul1E/FTzYgVbbf+D vo0xDMBt7Lvhjt9nV0qptnB4HYa4lCY9sC6/1ihMXqaeY8HDc4KB2EIZt1h1reoh6hM9 6Tp73f70fjRqelseQ2+L2vRHdhRCdek9JfyYeGJfij4yMxJnShHsJFIrgdCiH69AXE4u VV0+UUFPtifAgpp3YXaz3dhxeyfvf7+TcgjZ0BDgz0VoodihWflBSl6DEoZAMQ8REJjg iHTzOwhGjyiJpHQU88I69OUFlZL18kLkgwsUyfs1bzRHVrBHN3r1uU/dGmrzRpau3moM cjyw== X-Gm-Message-State: ALoCoQkUwu6A2/p7yYfKTvV6C+uZiUIx3XOH3H/EOVrxx64VtkaeWDBK3iN8HZdpIKI1UIvC+sAmfy3NQXJ+jEguAI0wUJUZi/2edrUDUveGId+HDgoiG9+SZhvwzo00uOyB7Y4HKr0o X-Received: by 10.107.152.2 with SMTP id a2mr10048213ioe.123.1446739555541; Thu, 05 Nov 2015 08:05:55 -0800 (PST) X-Received: by 10.107.152.2 with SMTP id a2mr10048080ioe.123.1446739554341; Thu, 05 Nov 2015 08:05:54 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id rj5sm3095841igc.7.2015.11.05.08.05.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 08:05:53 -0800 (PST) References: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> <8D8A25B4-2E47-4524-9F76-11A0C28DDD39@nestlabs.com> <8AACD6C0-7B3D-44B0-AEF4-1880A5A63FBD@nestlabs.com> <563ADB4B.4070409@umn.edu> <20151105064052.308F23BE9BE0@rock.dv.isc.org> In-Reply-To: <20151105064052.308F23BE9BE0@rock.dv.isc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <09A3CAC8-B3C5-401D-9938-58E4F0485FE9@umn.edu> X-Mailer: iPad Mail (13B143) From: David Farmer Date: Thu, 5 Nov 2015 10:05:53 -0600 To: Mark Andrews Archived-At: Cc: V6OPS Working Group Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.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, 05 Nov 2015 16:06:13 -0000 > On Nov 5, 2015, at 00:40, Mark Andrews wrote: >=20 > In message <563ADB4B.4070409@umn.edu>, David Farmer writes: >>> On 11/4/15 19:41 , James Woodyatt wrote: >>> Everyone- >>>=20 >>> This draft A) uses normative requirements language with RFC 2119 >>> keywords and B) calls for publication in the Informational category. Is >>> the document really intended for the Best Current Practice (BCP) >>> category? If not, could we please either remove the citation of RFC 2119= >>> and all the usage of upper case keywords, or insert an explanation for >>> why the document uses normative requirements language despite being an >>> Informational category document? >>=20 >> The only use of use upper case RFC2119 keywords in the document are in >> quotes from other documents. Such use seem appropriate, even if you >> think upper case RFC2119 keywords are not normally appropriate in an >> Informational category document. Since quotes using upper case RFC2119 >> keywords are included I think the citation of RFC 2119 is also >> appropriate and clarifies their use. >=20 > Then you have to think about all use of "must", "should" etc. in > terms of RFC2119. For reference I've got drafts which quote > documents with RFC2119 semantics but have not cited RFC 2119. Personally, I don't like the inclusion of any capitalized RFC2119 key words= without the inclusion of a RFC2119 reference to clarify their meaning. > There is also nothing preventing the use of RFC 2119 in BCP or INFO > documents. The use of RFC 2119 does not imply standard. I agree, however, I decided not to argue that point. In the document in que= stion the author choose to only capitalize the RFC2119 key words in the quot= es from other documents and therefore included the reference, this seemed re= asonable to me in the context of the document and well within the discretion= of the author. I expect even for those who think Informational documents s= hould not use capitalized RFC2119 key words, they would recognize and except= ion for quotes from other documents.=20 I believe it is reasonable to use use capitalized RFC2119 key words in any d= ocument anywhere and reference RFC2119. For Informational documents, within= reasonable limits, this should be a style question left to the discretion o= f the author. For Standards Track or BCP documents there is an expectation t= o use capitalized RFC2119 key words when make normative statements. But eve= n this isn't an absolute. In my opinion even here, within reason, the autho= r should have discretion, but for clarity I believe it is necessary for an a= uthor to explain any deviation from this expectation.=20 --=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 Thu Nov 5 10:17: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 E8A301A0404 for ; Thu, 5 Nov 2015 10:17:15 -0800 (PST) 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, 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 plfr-rsnk0Yx for ; Thu, 5 Nov 2015 10:17:14 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 630BA1A037F for ; Thu, 5 Nov 2015 10:17:14 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 5 Nov 2015 12:17:08 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f178.google.com [209.85.213.178] #+LO+TS+TR X-Umn-Classification: local Received: by igbhv6 with SMTP id hv6so17136418igb.0 for ; Thu, 05 Nov 2015 10:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Qv0jq2bKoaGbylEJNSc8jrzMy6ZKz6ZTtxD3UxSc/M0=; b=qR6uJdHGr6ZZBgitoXVpk/xqC4LxAr3yFB5PdD9cutEDX7oaxS86DGrzzpCuFZSCxw dYzAXznYWmkgEImUsMhelQ8lLBhh7QMdnP/IEwhym1PhhtgPKGSptM8DgriMiuZsWC55 /Wlzl89Yu2r0G1VcxQOudJMxUnmkj154teiKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=Qv0jq2bKoaGbylEJNSc8jrzMy6ZKz6ZTtxD3UxSc/M0=; b=O2/LCre541eEJjGRyxsSUfJOMmsvj+uhimPbJaoqIkZQnXRwZkaw21CRJeqxpVtdSX 7bZ/C5KClBABde6sD1T+F/i6LO4TvH6ZlmV5zwkRvr/VyHt8xPDQ8RmcJ7UPAhZ+z76J ugxm1vPS21UH75YpUT3WiaqOLXbXFAPrKdO/RZvtT1DxNBLDU6XegUgRQw3ALj8YJOyB dobvURo0YN/8aw1n/6fmUTRHaolZhIt3L3EsjfBfdk64P55fPgYtdz1pSRNiMhIRBQXC gOPuY7S6k5HJUIg6GuPitFmsyXbxNE1ys0TVofEyCvjEFquwsdQJez29mrOq5SRQxkJl YKVw== X-Gm-Message-State: ALoCoQmMdcVwI2kKOacEMvI7xLIpfNGniLugkxAPoyenmam+7bxlngXEJ/Fllq1jY9CzDHzUJiCOS1yUlb9HirhdYdmugKtR0LzOuaYtXBubMpoLdjbPtJFEeBDs8tTvTLixHxUFy3tK X-Received: by 10.50.160.37 with SMTP id xh5mr4903751igb.6.1446747427182; Thu, 05 Nov 2015 10:17:07 -0800 (PST) X-Received: by 10.50.160.37 with SMTP id xh5mr4903724igb.6.1446747426975; Thu, 05 Nov 2015 10:17:06 -0800 (PST) Received: from x-134-84-0-160.vpn.umn.edu ([2607:ea00:103:4801::3c]) by smtp.gmail.com with ESMTPSA id e1sm3291538igx.6.2015.11.05.10.17.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 10:17:05 -0800 (PST) References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> To: "Howard, Lee" , Lorenzo Colitti From: David Farmer Organization: University of Minnesota Message-ID: <563B9D1E.4030606@umn.edu> Date: Thu, 5 Nov 2015 12:17:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 18:17:16 -0000 On 11/5/15 03:05 , Howard, Lee wrote: > > From: Lorenzo Colitti > > > On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee > wrote: > > And so on. It seems pretty clear. Is this language > insufficiently strong for you? What words would you use instead? > > > I would prefer if we used phrasing of the form " is considered > harmful" or " is not recommended". > > > You deleted a lot of context, including the text: > > “(NPT66) is not recommended by the IETF.” For the most part I like this. It takes emotional trigger words out of it. However, I would suggest focusing on Internet connectivity and away from all potential uses of NAT. I believe the primary objection to NAT is in a general-purpose Internet context, and other more specialized uses might be less objectionable to some. So something like; Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in the context of general-purpose Internet connectivity. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Nov 5 11:44: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 EC4971B32EC for ; Thu, 5 Nov 2015 11:44:24 -0800 (PST) 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 JX7I7qvRwp9o for ; Thu, 5 Nov 2015 11:44:23 -0800 (PST) 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 A6E5F1B32EA for ; Thu, 5 Nov 2015 11:44:19 -0800 (PST) Received: by pacdm15 with SMTP id dm15so71984305pac.3 for ; Thu, 05 Nov 2015 11:44:19 -0800 (PST) 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=RhpAMv7Vt3Gb3WvxmimXI8zEQ6IVdYnvVazHFBpALwE=; b=IhGnjTdHnV5NwCmg0vB5woetdly3N+vY2oSczrBtjvdInzcQTBJVhOW6TpqXuabcvl 4QZkji6QqNJtKe+LH6vMjxe10iOosxdS309aMINOgEl7C6sg3/T+L20m82pZTDtS+eiZ 0xIwDVkYiyumWxkUndjDBTvFt1oYTCS7C8KjHl9NG3DLqzY1jhnXrCguJYQfT/Q5bY1Y suzQCwdDathLVyySkIdsN5+lg6Z8W5lwkqv9AZgi0k52XbPuXsjbLUEPEBSClB6/oCKC mg0hzN2dECz3rA4QrP1Z6L4TvkirqH3UyStX8+JD0DTZhkK8oqmM+scjpVEmxponPp/U Ia4A== X-Received: by 10.68.219.40 with SMTP id pl8mr11366725pbc.136.1446752659230; Thu, 05 Nov 2015 11:44:19 -0800 (PST) Received: from ?IPv6:2406:e007:7f30:1:28cc:dc4c:9703:6781? ([2406:e007:7f30:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id qn5sm9356360pac.41.2015.11.05.11.44.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 11:44:17 -0800 (PST) To: David Farmer , "Howard, Lee" , Lorenzo Colitti References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563BB197.8040100@gmail.com> Date: Fri, 6 Nov 2015 08:44:23 +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: <563B9D1E.4030606@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 19:44:25 -0000 On 06/11/2015 07:17, David Farmer wrote: > On 11/5/15 03:05 , Howard, Lee wrote: >> >> From: Lorenzo Colitti >= >> >> On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee > > wrote: >> >> And so on. It seems pretty clear. Is this language >> insufficiently strong for you? What words would you use instea= d? >> >> >> I would prefer if we used phrasing of the form " is considere= d >> harmful" or " is not recommended". >> >> >> You deleted a lot of context, including the text: >> >> =E2=80=9C(NPT66) is not recommended by the IETF.=E2=80=9D >=20 > For the most part I like this. It takes emotional trigger words out of= it. However, I would suggest focusing on Internet > connectivity and away from all potential uses of NAT. I believe the pr= imary objection to NAT is in a general-purpose Internet > context, and other more specialized uses might be less objectionable to= some. So something like; >=20 > Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in= > the context of general-purpose Internet connectivity. If we're not writing a BCP, we don't need to do it that way, even though = it's factually true. We can simply say things like NPTv6 is an experimental technology and network address translation for IPv6 has not been defined by the IETF. Therefore, they do not have a role= to play in general-purpose Internet connectivity. Outside our little world, the effect is much the same. Brian From nobody Thu Nov 5 12:15: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 A39BF1B36D7 for ; Thu, 5 Nov 2015 12:15:05 -0800 (PST) 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 YR4AbV_OTb8L for ; Thu, 5 Nov 2015 12:15:04 -0800 (PST) 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 460D61B36D3 for ; Thu, 5 Nov 2015 12:15:04 -0800 (PST) Received: by ykek133 with SMTP id k133so152201140yke.2 for ; Thu, 05 Nov 2015 12:15:03 -0800 (PST) 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=GfEsuicJplJYBPvNpba+jG2FeIoXVoLj9R7yBcC4Iko=; b=eJXzhYcHNGqsY1/j41bs5LnSFFG00IQbRzmQzm9O/0PWGw0xAV+IBfCCBQASL0AS8p 0gRqHYxN6h1A2FfSLTfqwYA+qxLifNet7GCVCDVecik81DuCpvtIZZkq63KmmTboS/oR B3moz15ZDfAlJkNnpyGcMNzg4oEECntZ8jeYUqkyk0TUbsIlYDySKwM6X9A8XVd7yyAC V7KfE/0M5XIv3QKY7e3da1UCLKv4Hcbq6eqpEPvsOLdvZLla9wp9gZxDcLjBHLP73reY Z/iL6TpQGSSmjQDL+WwV7022Gkyp8vikkejyHvPG187knw2r5NQCG5PQZ5H4Izq1Yx2M DqHw== X-Received: by 10.31.158.198 with SMTP id h189mr9090599vke.102.1446754503369; Thu, 05 Nov 2015 12:15:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.67.194 with HTTP; Thu, 5 Nov 2015 12:14:33 -0800 (PST) In-Reply-To: <563B9D1E.4030606@umn.edu> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> From: Mark Smith Date: Fri, 6 Nov 2015 07:14:33 +1100 Message-ID: To: David Farmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 20:15:05 -0000 On 6 November 2015 at 05:17, David Farmer wrote: > On 11/5/15 03:05 , Howard, Lee wrote: >> >> >> From: Lorenzo Colitti > >> >> On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee > > wrote: >> >> And so on. It seems pretty clear. Is this language >> insufficiently strong for you? What words would you use instead? >> >> >> I would prefer if we used phrasing of the form " is considered >> harmful" or " is not recommended". >> >> >> You deleted a lot of context, including the text: >> >> =E2=80=9C(NPT66) is not recommended by the IETF.=E2=80=9D > > > For the most part I like this. It takes emotional trigger words out of i= t. > However, I would suggest focusing on Internet connectivity and away from = all > potential uses of NAT. I believe the primary objection to NAT is in a > general-purpose Internet context, and other more specialized uses might b= e > less objectionable to some. So something like; > > Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in > the context of general-purpose Internet connectivity. > I think the above simpler statement is better, this text implies that there are no consequences (to anything) of using address translation outside of an Internet context. There clearly are many technical consequences, as have been documented in many RFCs, and we shouldn't effectively be dismissing them by omission or implying they only matter in certain contexts. (I think it would be better describe the thing being recommended against being "address translation", rather than specific methods. Mentioning specific address translation technologies implies that other later ones may be consequence free.), As far as I can see, only one person here is strongly objecting to stating address translation is harmful. One person strongly objecting doesn't mean that consensus hasn't been reached by the IETF (see RFC7282 - "On Consensus and Humming in the IETF") I think there are two types of people we need to address: - people who don't really care as much or have as much time for the details and to know the various benefits and drawbacks. They just want to follow a guide as to what will work best, making minimal value judgements - people who are willing to make value judgements and consider various trade-offs. They will be interested to know, research and consider the topic. The first category of people will mostly accept a simple statement recommending against or for something, with their next question being, "so what do I do instead." (e.g. RFC4864 instead of address translation). The second category will put weight on what is being stated in the recommendation, however they themselves will want to have a much deeper understanding of the why the recommendation has been made, by researching and reading supporting references. In some ways they're effectively making the decision their own. They may even decide against the recommendation. In either case, they'd be able to defend the decision themselves if they're challenged on it. (With many people being only being used to private addressing and NAT in IPv4, I suspect there will be a few people pushed into the second category who are normally first category people.) Since this ID is an advice document, I'd like to see content that would satisfy both types of people. So perhaps: (a) a simple statement recommending against address translation (b) a paragraph or so as to mentioning the sorts of consequences it has, and also that the increasing use of encryption will prevent the ability to address translate addresses in payloads (c) references to RFCs that discuss the consequences of address translation, either specific to IPv6 (i.e., the Implications for Applications section in the NPT66 RFC), or more general ones e.g., RFC2993, RFC1627, with mention that although they were written about IPv4, some or all of the implications will also apply to IPv6 address translation. Regards, Mark. From nobody Thu Nov 5 12:25: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 6AC691B370E for ; Thu, 5 Nov 2015 12:25:21 -0800 (PST) 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 8-UM1MU5GsNm for ; Thu, 5 Nov 2015 12:25:19 -0800 (PST) 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 3B4601B3707 for ; Thu, 5 Nov 2015 12:25:18 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D0C3C62EFF for ; Thu, 5 Nov 2015 21:25:16 +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 95AB660775 for ; Thu, 5 Nov 2015 21:25:16 +0100 (CET) Received: (qmail 46055 invoked by uid 1007); 5 Nov 2015 21:25:16 +0100 Date: Thu, 5 Nov 2015 21:25:16 +0100 From: Gert Doering To: Mark Smith Message-ID: <20151105202516.GN70452@Space.Net> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> 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: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 20:25:21 -0000 Hi, On Fri, Nov 06, 2015 at 07:14:33AM +1100, Mark Smith wrote: > As far as I can see, only one person here is strongly objecting to > stating address translation is harmful. One person strongly objecting > doesn't mean that consensus hasn't been reached by the IETF (see > RFC7282 - "On Consensus and Humming in the IETF") Oh, and 3 persons repeatedly stating something when everyone else has given up and gone home for the evening make consensus? Please. Quite a number of "real world" operators have spoken in favour of having NAT-alikes in their tool box here in the past (and were usually being yelled at for being so stupid and having no idea about True Ivory Tower Networking). So, yes, seems they all have gone away now - but that does not make their prior statements less valid. 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 Nov 5 13:56: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 876D51B3C01 for ; Thu, 5 Nov 2015 13:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 3btk2w5if56H for ; Thu, 5 Nov 2015 13:56:17 -0800 (PST) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4692A1B3C09 for ; Thu, 5 Nov 2015 13:56:16 -0800 (PST) X-SENDER-IP: 10.64.163.160 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,248,1444708800"; d="scan'208";a="860338876" Received: from unknown (HELO exchpapp19.corp.twcable.com) ([10.64.163.160]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 05 Nov 2015 16:48:50 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp19.corp.twcable.com (10.64.163.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 16:56:15 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 16:56:15 -0500 From: "Howard, Lee" To: IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYD//769AIAACpaAgAAHdwCAAItVAIACvqMAgACUfYCAABQfAIAAw1mA Date: Thu, 5 Nov 2015 21:56:14 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> In-Reply-To: <563B9D1E.4030606@umn.edu> 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21924.001 x-tm-as-result: No--34.449900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4E2FDED0F952BC43BAB2F31C646886FA@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 21:56:18 -0000 Would somebody please explain to me exactly what NPT66 breaks? Preferably in a way that could be included in a draft. Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Thu Nov 5 15:24: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 8B40D1B3D52 for ; Thu, 5 Nov 2015 15:24:51 -0800 (PST) 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 mSleMuoCeZsM for ; Thu, 5 Nov 2015 15:24:50 -0800 (PST) Received: from moonbase.nullrouteit.net (moonbase.nullrouteit.net [216.254.64.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC5E1B2DC2 for ; Thu, 5 Nov 2015 15:24:49 -0800 (PST) Received: (qmail 2222 invoked by uid 1000); 5 Nov 2015 09:47:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Nov 2015 09:47:34 -0000 Date: Thu, 5 Nov 2015 04:47:34 -0500 (EST) From: Igor Gashinsky X-X-Sender: igor@moonbase.nullrouteit.net To: "Howard, Lee" In-Reply-To: Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="===============7226308357901497542==" Content-ID: Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 23:24:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============7226308357901497542== Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Thu, 5 Nov 2015, Howard, Lee wrote: :: On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee > wrote: :: And so on. It seems pretty clear. Is this language insufficiently strong for you? What words would you use instead? :: :: I would prefer if we used phrasing of the form " is considered harmful" or " is not recommended". :: :: You deleted a lot of context, including the text: :: :: "(NPT66) is not recommended by the IETF." :: :: Can we consider your concern addressed? That makes it sound like IETF is not "endorsing" NPT66, as opposed to actively recommending that people don't use it. I'm with Lorenzo here - I would prefer very strong language in the form of "deployment of NPT66 is concidered harmful" or "we strongly recommend against the use of NPT66". Thanks! -igor --===============7226308357901497542== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --===============7226308357901497542==-- From nobody Thu Nov 5 15:52: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 AC0EE1B3789 for ; Thu, 5 Nov 2015 15:52:43 -0800 (PST) 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 LNrSXeYITQJM for ; Thu, 5 Nov 2015 15:52:42 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 372711B3788 for ; Thu, 5 Nov 2015 15:52:42 -0800 (PST) Received: by pabfh17 with SMTP id fh17so101874514pab.0 for ; Thu, 05 Nov 2015 15:52:41 -0800 (PST) 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=6B+Y3FVco2UREV+CwSqfwLzI2I1dHNpQc3Vo7XMDMcY=; b=SSPt42k71FEDSVxMnyGR7N8ieVQoi5RDEmU4RJY8V2qWFSZ+4zCsB5HeiHlMp4fYrT R+NhDRfBAEIDUTbF5odI61WZHIxaoV4ooDLjAqFmZyQ2XHmGJGK4vi5fgOILQZ8GI4M9 vyAO8Rr4lvKIA6Xzt/kw8wQgXPsdnH0TaIGesmRRWKswNDj3d2Ij1yIKN9iFFgCoRu6E pwfOEKRyAVp6SqFw80H02xYAnPmOhEZtg6MANvraEpwWwHY46DLCfwGhogxddZbujDTb 7ssGsLf+N3OaNsnwhydxdnqwvdGWWlri8AKOqJfpE+dYIDMk8sHIR1UhAPLM/piFxQ4Y OuMA== X-Received: by 10.68.98.129 with SMTP id ei1mr12632825pbb.7.1446767561800; Thu, 05 Nov 2015 15:52:41 -0800 (PST) Received: from ?IPv6:2406:e007:7f30:1:28cc:dc4c:9703:6781? ([2406:e007:7f30:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id so4sm9909484pbc.72.2015.11.05.15.52.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 15:52:40 -0800 (PST) To: "Howard, Lee" , IPv6 Operations References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <563BEBCE.40204@gmail.com> Date: Fri, 6 Nov 2015 12:52:46 +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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 05 Nov 2015 23:52:43 -0000 That's in the NPTv6 RFC already, I think. Because we certainly had this whole conversation prior to reaching rough consensus to publish NPTv6 as Experimental. Regards Brian On 06/11/2015 10:56, Howard, Lee wrote: > > Would somebody please explain to me exactly what NPT66 breaks? > Preferably in a way that could be included in a draft. > > Thanks, > Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 5 16:21: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 6FCA71A6F81 for ; Thu, 5 Nov 2015 16:21:18 -0800 (PST) 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 Hrz5uOousrvw for ; Thu, 5 Nov 2015 16:21:17 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 1B40A1A6F59 for ; Thu, 5 Nov 2015 16:21:17 -0800 (PST) Received: by ykek133 with SMTP id k133so162746485yke.2 for ; Thu, 05 Nov 2015 16:21:16 -0800 (PST) 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=2GWI7jVn01RLRC6A2m+mFO32XzWIvtRuyFxfvYQDR3A=; b=nHOTQct3mKTBmN4Hw2Yk5RpF6JtEWeC70BKRWmHH2iUClsMJpwd14tG6nOAdOLPVKo w88SBWOo7ZjNkp67x9EX2e0AfxZTg9Fa1kz/ZuC6Nmtz5ffU+yRImw8xR26QGkqFm+br 6mqe6Ch57KGJUGmi3Lhz/qbYp3X+mbef7IZafKaF0OeJMiS+AKSxaRLMlnNpfWx5ycn8 dkI2mZx5UsG++gb9xQCiUllCqmNB+Yr629lb0fYKW56bUPvcqsVxb8PxKrdE4icN9bS5 z2r2l2jXNv+PgIYwKNRW//FAjeaWYsqKEteZfFvOqTYzkHIgFSHNfx43y7pMyyOIflXd b0CA== 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=2GWI7jVn01RLRC6A2m+mFO32XzWIvtRuyFxfvYQDR3A=; b=iC2/sASmWh7gKTkVcL9M0M2FEtptb3hpRYWGfdTcIzwSf17fUHAiHxC68UHsT/zmC7 SJRnbC44YBf2+MhGJeOC7tXkHrPfhu6aOIy5qtSLI/YOaxhbrFt+n/gQQe+WKyYnoZLA gg0wyLykwwbqjlo0b/MMvM+FMIlj/tpXI/T8txY2gkuSAuS39lhyfBVri3osadxot8ff 9miOeY8boBV07aTpvDMcfm52GGKhGEe++H3C8hAoJfWhdEAsQNp5lM1bbC3kxyqzqnc7 08kVF2HA5EPVN8yVeLb/AOXt8Ph3kNONX+GigIlFIpvtYQ/Q3GTmpdmy5JrpDBwUDbmt H10A== X-Gm-Message-State: ALoCoQm8YA3LUg0B+zRuz1R21v+BlTolXwhiSrPUQbj6bxBNavhMhu3ail0u4V7WDZp++S6/fT6n X-Received: by 10.13.246.70 with SMTP id g67mr10405269ywf.116.1446769276311; Thu, 05 Nov 2015 16:21:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Thu, 5 Nov 2015 16:20:56 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> From: Lorenzo Colitti Date: Fri, 6 Nov 2015 09:20:56 +0900 Message-ID: To: "Howard, Lee" Content-Type: multipart/alternative; boundary=94eb2c0338d4c9bde00523d4387f Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 00:21:18 -0000 --94eb2c0338d4c9bde00523d4387f Content-Type: text/plain; charset=UTF-8 It breaks any application that requires that the application know its source address. Examples are SIP, FTP, audio/video chat, etc. On Fri, Nov 6, 2015 at 6:56 AM, Howard, Lee wrote: > > Would somebody please explain to me exactly what NPT66 breaks? > Preferably in a way that could be included in a draft. > > Thanks, > Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0338d4c9bde00523d4387f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It breaks any application that requires that the applicati= on know its source address. Examples are SIP, FTP, audio/video chat, etc.

On Fri, Nov 6= , 2015 at 6:56 AM, Howard, Lee <lee.howard@twcable.com>= wrote:

Would somebody please explain to me exactly what NPT66 breaks?
Preferably in a way that could be included in a draft.

Thanks,
Lee


________________________________

This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.

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

--94eb2c0338d4c9bde00523d4387f-- From nobody Thu Nov 5 16:25: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 F36B61A6F98 for ; Thu, 5 Nov 2015 16:25:20 -0800 (PST) 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 W50oOHiwy1nr for ; Thu, 5 Nov 2015 16:25:19 -0800 (PST) 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 A23621A6F8E for ; Thu, 5 Nov 2015 16:25:19 -0800 (PST) Received: from dhcp-28-39.meeting.ietf94.jp (t20010c4000003024a8b3865066855c4a.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:a8b3:8650:6685:5c4a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA60PGbG006614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Nov 2015 00:25:17 GMT (envelope-from joelja@bogus.com) To: Brian E Carpenter , "Howard, Lee" , IPv6 Operations References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <563BF369.5060308@bogus.com> Date: Fri, 6 Nov 2015 09:25:13 +0900 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: <563BEBCE.40204@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CxbeMK36BMjXCqnIJN92PdODMkEAKA2Hj" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 00:25:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CxbeMK36BMjXCqnIJN92PdODMkEAKA2Hj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/6/15 8:52 AM, Brian E Carpenter wrote: > That's in the NPTv6 RFC already, I think. Because we certainly had this= > whole conversation prior to reaching rough consensus to publish NPTv6 > as Experimental. https://tools.ietf.org/html/rfc6296#section-5 Is quite a reasonable citation. It is resonable to suppose that the deployer of nptv6 exposes the cost associated with the traversal to application developers who in turn externalize that in small ways (additional complexity, lost opportunity, actual cost) to the users of the ntpv6 device. In ipv4 this cost is endogenous due to scarcity. > Regards > Brian >=20 > On 06/11/2015 10:56, Howard, Lee wrote: >> >> Would somebody please explain to me exactly what NPT66 breaks? >> Preferably in a way that could be included in a draft. >> >> Thanks, >> Lee >> >> >> ________________________________ >> >> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to = copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you = are not the intended recipient of this E-mail, you are hereby notified th= at any dissemination, distribution, copying, or action taken in relation = to the contents of and attachments to this E-mail is strictly prohibited = and may be unlawful. If you have received this E-mail in error, please no= tify the sender immediately and permanently delete the original and any c= opy of this E-mail and any printout. >> >> _______________________________________________ >> 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 --CxbeMK36BMjXCqnIJN92PdODMkEAKA2Hj 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 iEYEARECAAYFAlY782oACgkQ8AA1q7Z/VrLXCgCfTj4PTxhRaG4ZBeIO9pvIJf8V 5M8An18EfVkVVci3672v9zVy+hVNYHah =yHDS -----END PGP SIGNATURE----- --CxbeMK36BMjXCqnIJN92PdODMkEAKA2Hj-- From nobody Thu Nov 5 17:31: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 6822F1A1A16 for ; Thu, 5 Nov 2015 17:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 V-MSIh-50Kzt for ; Thu, 5 Nov 2015 17:31:05 -0800 (PST) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 89F991A0123 for ; Thu, 5 Nov 2015 17:31:05 -0800 (PST) X-SENDER-IP: 10.136.163.146 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,249,1444708800"; d="scan'208";a="454350062" Received: from unknown (HELO exchpapp05dr.corp.twcable.com) ([10.136.163.146]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 05 Nov 2015 20:22:27 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp05dr.corp.twcable.com (10.136.163.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 20:31:03 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 20:31:03 -0500 From: "Howard, Lee" To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYD//769AIAACpaAgAAHdwCAAItVAIACvqMAgACUfYCAABQfAIAAw1mA//+adACAAKGQgA== Date: Fri, 6 Nov 2015 01:31:02 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> In-Reply-To: <563BEBCE.40204@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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21924.001 x-tm-as-result: No--50.231700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 01:31:07 -0000 On 11/6/15, 8:52 AM, "Brian E Carpenter" wrote: >That's in the NPTv6 RFC already, I think. Because we certainly had this >whole conversation prior to reaching rough consensus to publish NPTv6 >as Experimental. Yes, exactly, which is why I have a hard time understanding what new information has arisen that makes us not recommend it. But fine, let=B9s cite the considerations section from the original document as the problem. Current text: Although NPTv6 works differently from traditional stateful NAT/NAPT (which is discouraged in [RFC5902 ]), it introduces similar additional complexity to applications, which may cause applications to break. Thus this document does not recommend the use of ULA+NPTv6. Proposed text: ... it does have significant implications to applications, as documented in [RFC6296] Section 5, which may cause some applications to break. Thus this document does not recommend the use of ULA+NPTv6. Current text: Although NPTv6 is a mechanism that has fewer architectural problems than a traditional stateful Network Address Translator in an IPv6 environment [RFC6296 ], it still breaks end-to-end transparency and hence in general is not recommended by the IETF. Proposed text: ... and hence is not recommended. Are we there yet? Lee > >Regards > Brian > >On 06/11/2015 10:56, Howard, Lee wrote: >> >> Would somebody please explain to me exactly what NPT66 breaks? >> Preferably in a way that could be included in a draft. >> >> Thanks, >> Lee >> >> >> ________________________________ >> >> This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Thu Nov 5 17:54: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 A6E921B2AEE for ; Thu, 5 Nov 2015 17:54:28 -0800 (PST) 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 ePDe1odEiLR6 for ; Thu, 5 Nov 2015 17:54:26 -0800 (PST) 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 428E41B2AF2 for ; Thu, 5 Nov 2015 17:54:26 -0800 (PST) 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 tA61sOXU024457 for ; Fri, 6 Nov 2015 02:54:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C7A43201004 for ; Fri, 6 Nov 2015 03:00:25 +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 BF6DC200FE1 for ; Fri, 6 Nov 2015 03:00:25 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.7]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tA61sK6I002647 for ; Fri, 6 Nov 2015 02:54:23 +0100 To: v6ops@ietf.org References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> <1D37A3AC-68E8-402B-BE1A-51EC3075A2A1@umn.edu> From: Alexandre Petrescu Message-ID: <563C084C.90305@gmail.com> Date: Fri, 6 Nov 2015 10:54:20 +0900 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: <1D37A3AC-68E8-402B-BE1A-51EC3075A2A1@umn.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 06 Nov 2015 01:54:28 -0000 Le 06/11/2015 00:12, David Farmer a écrit : > > > -- > =============================================== > David Farmer Email: farmer@umn.edu > > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: +1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 > =============================================== > > > On Nov 5, 2015, at 01:32, Lorenzo Colitti > wrote: > >> On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt > > wrote: >> >> I’m opposed to that suggestion. The practice described in section >> 5.2 is necessary today for dealing with behavior of deployed >> networks that conform to existing standards. If 6MAN wants to >> clarify or improve the ND6 specification to change the need for >> the behavior documented here, then that would be splendid, but >> please count me on the list of people who prefer not to wait for >> the deliberations in 6MAN to resolve successfully before a >> practical solution to real world problems can be applied. >> >> >> Erik, James and I worked on this together and I believe we're OK with >> the following text: >> >> 1. Maintaining IPv6 connectivity requires that hosts be able to >> receive periodic multicast RAs [RFC4861]. Therefore, hosts that >> process unicast packets sent while they are asleep MUST also >> process multicast RAs sent while they are asleep. Hosts MAY >> rate-limit identical RAs if they are sent too frequently. >> >> 2. Mobile devices that do not intend to maintain IPv6 connectivity >> while asleep SHOULD either disconnect from the network, abandoning >> all IPv6 configuration, or perform DNAv6 procedures [RFC6059] >> when waking up. >> >> Erik, James, can you confirm? > > I still don't understand why this is using the term "mobile device", and > the rest of the text uses "battery-powered host". If one needs to say mobile device, it would be ok to follow the terminology in the Mobility Terminology RFC - a Mobile Node. Alex > > Thanks > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 5 18: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 9EC251B2A43 for ; Thu, 5 Nov 2015 18:00:39 -0800 (PST) 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 44Q5_NBbJQU0 for ; Thu, 5 Nov 2015 18:00:38 -0800 (PST) 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 17EB51A87D7 for ; Thu, 5 Nov 2015 18:00:38 -0800 (PST) Received: by ykba4 with SMTP id a4so165710321ykb.3 for ; Thu, 05 Nov 2015 18:00:37 -0800 (PST) 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=VwAM6c8vpgCQ8ihJFJTOFZ8teF9QMgIIAi8quY1+PrA=; b=VxinhDSefaHCOzsTp5AWlud480Dd3dAofr0qgwQVNsiK2PJ56GG3tfU8yPTLLiCVNa QgHDYcUhynRDO5PyORYnjfpgUa0AFII+C4AMRFMzeOzOy3PwwbrUdI7YUpsYDVQCQeGi 34uEG8+hqAOZ5Oo70XUXzK5o3JxyAl+pLZkgvraPYzqOBndOGjV3JZnUFFGal9uEY317 B5R1GlE6gnAxUSJTwN48vMgqlbjx/yQB+Tr1c7SsDge+bw+0ll6E1qDMbKqa6kCkv1mk 472vFN6reG9q5hHCKleKzy5shEgQZ+XpS+jCHBqhN7v8pnGElEAVgQaylUhual16JqRm ERuA== 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=VwAM6c8vpgCQ8ihJFJTOFZ8teF9QMgIIAi8quY1+PrA=; b=gP9PjIPfgxUUVv4GS8Yj55QLJuhFOc346hLz0OY5tsJ4uCHudQkRhjyBFPnJVMp3+1 myaPXGMQ1Ge4QZqeVbbr43Q+VwE8ScrlSng4UvY9JoYYqJx31M6V435C1F2O/TAXIxNZ bVgnWba/nt5eJKNQlqW8OLdn8k2HkW6bXPeLfUa+JKJ4SKmTDDzzsKzVwt+ELGobqq9r Di3MZjuKqWzh3aIfjwvVKnJbph+5yIBmcL7lRs9+DgdJTlzF8XGXn+Av4UuHKZWa/V9D 4IZyXc8e2vjNueR8dUSZh/NNx/MaPRVNfMLZgt6q029aq8T0i7SZiNQ6UHP79+qc/h+L /P4w== X-Gm-Message-State: ALoCoQlr5OFQ9c4kCkFdWKk+JwLFefB6mEQpU/1z+xjQFJemYXCwFXl7wmZaWATwj82s6C7+jVxL X-Received: by 10.129.136.5 with SMTP id y5mr10340034ywf.35.1446775237358; Thu, 05 Nov 2015 18:00:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Thu, 5 Nov 2015 18:00:17 -0800 (PST) In-Reply-To: <1D37A3AC-68E8-402B-BE1A-51EC3075A2A1@umn.edu> References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <563AB521.8000309@acm.org> <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com> <1D37A3AC-68E8-402B-BE1A-51EC3075A2A1@umn.edu> From: Lorenzo Colitti Date: Fri, 6 Nov 2015 11:00:17 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a114effba1832190523d59c5a 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, 06 Nov 2015 02:00:40 -0000 --001a114effba1832190523d59c5a Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 12:12 AM, David Farmer wrote: > I still don't understand why this is using the term "mobile device", and > the rest of the text uses "battery-powered host". > Fix queued up for -03. --001a114effba1832190523d59c5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 6, 2015 at 12:12 AM, David Farmer <farmer@umn.edu> wrot= e:
I still d= on't understand why this is using the term "mobile device", a= nd the rest of the text uses "battery-powered host". =C2=A0
=

Fix queued up for -03.
<= /div>
--001a114effba1832190523d59c5a-- From nobody Thu Nov 5 18:09: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 393F21B2BBC for ; Thu, 5 Nov 2015 18:09:16 -0800 (PST) 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 BdcS37igeBBJ for ; Thu, 5 Nov 2015 18:09:14 -0800 (PST) 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 5B25C1B2BB3 for ; Thu, 5 Nov 2015 18:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5100; q=dns/txt; s=iport; t=1446775754; x=1447985354; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=St7rlvz9/4ScKOGctiFlnyNrv9No+u1S2bn+69mhgDI=; b=Xg8ipTHRiIXeq7NxACPztJ0VTSDWGScXOW0fpteQpcm2eOaJINhUJ1DC y0OCjBW6QGjiylx1pYeFihbf8LDMjrqibX+sxpOJSutoGKXE+RT20qaF+ YK443kaI5krlW7b3YB7KwKPK4+G1JTzx3hFyhpT0V2xd6dEe2k1QzgoWd A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DVAgDoCjxW/5ldJa1eDoMtU28GvgMOgWAXCoVvAoE9OBQBAQEBAQEBgQqENQEBAQMBAQEBIEsEBwULAgEIGCoCAicLJQIEAQ0FDogYCA2wCpB1AQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEiGSCboQqEQFLgm4vgRUFh0CHDYd7AYJRgWFqiAaBWoQ/ligBHwFDg0Y+coNTOoEHAQEB X-IronPort-AV: E=Sophos;i="5.20,250,1444694400"; d="asc'?scan'208";a="47267213" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2015 02:09:13 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA629CTN012095 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 02:09:13 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 21:09:06 -0500 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, 5 Nov 2015 21:09:06 -0500 From: "Fred Baker (fred)" To: Victor Kuarsingh , David Farmer , Alexandre Petrescu , Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRGDgdTKsHy6HG/k++P1vGitm6Ag== Date: Fri, 6 Nov 2015 02:09:06 +0000 Message-ID: <288FF5B0-4E98-445C-A3CD-4AC9A466DF95@cisco.com> References: <5637FDD0.70300@jvknet.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.3.85] Content-Type: multipart/signed; boundary="Apple-Mail=_EA42D00C-5E7D-4AA4-A5B5-4ADE48CEE59B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 02:09:16 -0000 --Apple-Mail=_EA42D00C-5E7D-4AA4-A5B5-4ADE48CEE59B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That would be = https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations; = it just expired and therefore might not show up through the usual search = mechanisms. > On Nov 3, 2015, at 9:49 AM, Howard, Lee = wrote: >=20 > I see interest from Victor Kuarsingh, David Farmer, Alexandre = Petrescu, and > Brian Carpenter. Can I ask each of you to do a review of the current > document, and send comments to the mailing list? That will give the > authors > and the WG something to work from. >=20 > Following that, we can discuss whether we need additional discussion = at a > meeting, or WGLC. >=20 > Thanks, >=20 > Lee >=20 >=20 > On 11/3/15, 9:20 AM, "Victor Kuarsingh" wrote: >=20 >> WG, >>=20 >> My input is that we should continue this work. Given ULAs are = already >> in use, having a document which outlines those use cases is, in my = mind, >> operationally beneficial. >>=20 >> Perhaps we should be more clear that we would not be recommending the >> use of ULAs, but keep to a unbiased document which outlines how they >> have been used (just a use case discussion). We can also include >> objective technical points as to the pros/cons related to each use = case. >>=20 >> It was also noted in another email (based on WG v6ops discussion >> yesterday), that one such valid example was Cable Modem management = IPs >> assigned ULA based addressing. This is a valid technical use case. >>=20 >> I am willing to help if required on this document. >>=20 >> regards, >>=20 >> Victor K >>=20 >> On 2015-11-02 6:17 PM, Howard, Lee wrote: >>> This document hasn=C2=B9t had any revisions or discussion in a = while. >>> Is there anyone interested in working on it? >>>=20 >>> If we do not hear any interest, we will abandon this draft. >>>=20 >>> Thanks, >>> Lee >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or = subject >>> to copyright belonging to Time Warner Cable. This E-mail is intended >>> solely for the use of the individual or entity to which it is = addressed. >>> If you are not the intended recipient of this E-mail, you are hereby >>> notified that any dissemination, distribution, copying, or action = taken >>> in relation to the contents of and attachments to this E-mail is >>> strictly prohibited and may be unlawful. If you have received this >>> E-mail in error, please notify the sender immediately and = permanently >>> delete the original and any copy of this E-mail and any printout. >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_EA42D00C-5E7D-4AA4-A5B5-4ADE48CEE59B 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 iQIVAwUBVjwLxEayAOS/EQ8MAQJd5w/+KS6pWzQO/AOQs4Z+99/gZB/d4C9Y7N6o 38dzS2EkE7wZiHfGIMfKFX2r4UTJvzzb8m1GkkwZQ9eWQzLkNxobd45IxduRUYPB mMPRKOeTKQFm2FB/77De94hRCSP45uTQlzCuejo6hVV09N0RUoH3XwB6p9LRVnF1 Wgra6y0JTFAjarQr9ER3WpRUhbA5lTF5rFxYXuIiwcNcNbOKrBCsreJa8QBIjlAG GT9F6iXGd0DZloDzeYnF/xpA/fi3U0lpqUvQKJoOIjdypFh9jZKQCsCVs8A3G4v/ 2LAeY6AZLYVP+PlXNm0tIbpJCYD4wrZSS1DMM8rNcu1DkWRTkQTDybZ1+YJrZhVu SgtjAREwfvS2eySHltDZX1+GfN684OocDVYdYcVLXYRNTR+Op3f8Xkp99kmm4GOj w7doe09ElcTUP9LzD3LeWxo/yIwD17PUpaOLTBkOCaxI13zhv6son9bXyuFMUVDz GOP+GOkzvX0Zsnm0aGBNWBuIevuLvLMqa21FFqvLyOnh7OuFKuAJPB+jJymUahtn 988xujO1DsIAaSxgs0Q2LPBRnMlxZP+zRfd62nkJ7rRZD314JxHzG53y9u1ECafn drhA3DirGhHcfCGm/wFFEV5re1rn6EKE5wXnlI6gj0Jb2m/hsKgF/8SKvn49sM8h l9xroDHt0FE= =uUPq -----END PGP SIGNATURE----- --Apple-Mail=_EA42D00C-5E7D-4AA4-A5B5-4ADE48CEE59B-- From nobody Thu Nov 5 18:22: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 EFE301B2D32 for ; Thu, 5 Nov 2015 18:21:59 -0800 (PST) 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 FBifZ9EJ685s for ; Thu, 5 Nov 2015 18:21:58 -0800 (PST) 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 481821B2C18 for ; Thu, 5 Nov 2015 18:21:58 -0800 (PST) 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 tA62M0aA005215; Thu, 5 Nov 2015 18:22:00 -0800 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA62LsnI005176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Nov 2015 18:21:54 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.189]) with mapi id 14.03.0235.001; Thu, 5 Nov 2015 18:21:50 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , Alexandre Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD Thread-Index: AQHRGDnkXS8DHtEXC0+TTTxd8LA5Gg== Date: Fri, 6 Nov 2015 02:21:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3CC44@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <5638223E.5090404@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 WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD 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, 06 Nov 2015 02:22:00 -0000 SGkgTG9yZW56bywNCg0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAwMiwgMjAxNSA3OjA0IFBNDQo+IFRvOiBBbGV4YW5kcmUgUGV0cmVzY3UNCj4gQ2M6IHY2b3Bz QGlldGYub3JnIFdHDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtaG9z dC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uIC0gYWRkcmVzcyBvdXQgb2YgdGhlIGRlbGVn YXRlZCBwcmVmaXgsIG9uIHRoZSBlZ3Jlc3MgLSBubyBEQUQNCj4gDQo+IE9uIFR1ZSwgTm92IDMs IDIwMTUgYXQgMTE6NTUgQU0sIEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1 QGdtYWlsLmNvbT4gd3JvdGU6DQo+IExlIDAzLzExLzIwMTUgMTA6MzEsIFRlbXBsaW4sIEZyZWQg TCBhIMOpY3JpdCA6DQo+IEJ1bXBpbmcgdXAgb25lIGxldmVsIOKAkyBpcyBpdCBjbGVhciB0byBl dmVyeW9uZSB0aGF0IGl0IGlzIE9LIHRvDQo+IGFzc2lnbiBhZGRyZXNzZXMgdGFrZW4gZnJvbSBh IERIQ1B2NiBkZWxlZ2F0ZWQgcHJlZml4IHRvIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUN Cj4gcHJlZml4IHdhcyByZWNlaXZlZD8gQW5kLCB0aGF0IERBRCBpcyBub3QgcmVxdWlyZWQgZm9y IHRob3NlIGFkZHJlc3Nlcz8NCj4gDQo+IElzIHRoaXMgYSBzdGF0ZW1lbnQgd2UgbmVlZCB0byBt YWtlIGluIHRoaXMgZHJhZnQsIHRob3VnaD8NCg0KSW4gb3JkZXIgdG8gYWRkcmVzcyB0aGVzZSBw b2ludHMsIGFuZCB0byBnZXQgb3V0IG9mIHRoZSB3YXkgb2YgdGhlIHdvcmsNCnlvdSBhcmUgZG9p bmcsIEkgd3JvdGUgdXAgYSBkcmFmdCB0aGF0IGRpc2N1c3NlcyB0aGUgREFEIGltcGxpY2F0aW9u cyBvZiBtdXRsaQ0KYWRkcmVzc2luZy4gUGxlYXNlIGhhdmUgYSBsb29rIGFuZCBzZW5kICBjb21t ZW50cy4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQotLS0N CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IERl bGVnYXRpbmcgYSBQcmVmaXggdG8gYSBIb3N0IGZvciBNdWx0aS1hZGRyZXNzaW5nIFB1cnBvc2Vz DQogICAgICAgIEF1dGhvciAgICAgICAgICA6IEZyZWQgTC4gVGVtcGxpbg0KCUZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAwLnR4dA0KCVBhZ2VzICAgICAgICAg ICA6IDYNCglEYXRlICAgICAgICAgICAgOiAyMDE1LTExLTA1DQoNCkFic3RyYWN0Og0KICAgSVB2 NiBwcmVmaXhlcyBhcmUgdHlwaWNhbGx5IGRlbGVnYXRlZCB0byByZXF1ZXN0aW5nIHJvdXRlcnMg d2hpY2gNCiAgIHRoZW4gdXNlIHRoZW0gdG8gbnVtYmVyIHRoZWlyIGRvd25zdHJlYW0tYXR0YWNo ZWQgbGlua3MgYW5kIG5ldHdvcmtzLg0KICAgVGhlIHJlcXVlc3Rpbmcgcm91dGVyIHRoZW4gYWN0 cyBhcyBhIHJvdXRlciBiZXR3ZWVuIHRoZSBkb3duc3RyZWFtLQ0KICAgYXR0YWNoZWQgaG9zdHMg YW5kIHRoZSB1cHN0cmVhbSBwcm92aWRlciBuZXR3b3JrLiAgVGhlIHJvdXRlciBjb3VsZA0KICAg YWxzbyBhY3QgYXMgYSBob3N0IHVuZGVyIHRoZSB3ZWFrIGVuZCBzeXN0ZW0gbW9kZWwsIGFuZCBv dGhlcndpc2UNCiAgIGJlaGF2ZXMgYXMgYSBzdGFuZGFyZCByb3V0ZXIuICBUaGlzIGRvY3VtZW50 IGNvbnNpZGVycyB0aGUgY2FzZSB3aGVuDQogICB0aGUgInJlcXVlc3Rpbmcgcm91dGVyIiBpcyBh Y3R1YWxseSBhIGhvc3QsIGFuZCByZWNlaXZlcyBhIHByZWZpeA0KICAgdGhhdCBpdCBjYW4gdXNl IGZvciBtdWx0aS1hZGRyZXNzaW5nIHB1cnBvc2VzLiAgVGhlIGhvc3QgZG9lcyBub3QNCiAgIGNv bm5lY3QgYW55IGRvd25zdHJlYW0tYXR0YWNoZWQgbmV0d29ya3MsIGFuZCB1c2VzIHRoZSBwcmVm aXggc29sZWx5DQogICBmb3IgaXRzIG93biBtdWx0aS1hZGRyZXNzaW5nIHB1cnBvc2VzLg0KDQoN ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3Qv DQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAwDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCklu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K From nobody Thu Nov 5 18:29:04 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 9986B1B2E8A; Thu, 5 Nov 2015 18:29:03 -0800 (PST) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106022903.28750.4113.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 18:29:03 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-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: Fri, 06 Nov 2015 02:29:03 -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-03.txt Pages : 6 Date : 2015-11-05 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-reducing-ra-energy-consumption-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 Thu Nov 5 18:32: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 1F5931B3052 for ; Thu, 5 Nov 2015 18:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlyON63zPB26 for ; Thu, 5 Nov 2015 18:32:47 -0800 (PST) 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 AB7331B2FC6 for ; Thu, 5 Nov 2015 18:32:47 -0800 (PST) Received: by pasz6 with SMTP id z6so110252787pas.2 for ; Thu, 05 Nov 2015 18:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ldhOgnAH/Ebz6aOIDGbYbuYrumCZGegX1t+bxme0Xzk=; b=LT910wqJXNa0bJ1TsLSG9DRL2COuD6aPpFuLS+VSVq6S9s5n9zROCX6GY1zmuQ5B6Q CLfFvIBwjy15AK5ruwgtkmEzaLlkUfdO+d9hdbnUQpljMJtBHUkWPNJbUtRw6vXnhU72 UgZULfapB5nOqJtMuNFlminlbTUIWoHtZlJ/o= 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=ldhOgnAH/Ebz6aOIDGbYbuYrumCZGegX1t+bxme0Xzk=; b=ixgXM3renQCpI+nVHypG/O15meYg/YBdZbnHAq2elbDfZLB8jaqbtTuQfxRmtOjakP uQIV0ZMRsuQjViI3vg2Au4id/7hqdaOupHLXr8qsLC7EjYsZWFBx1j9+0ybNrC8k0l6C jz+S7NUrihNyqM3G9vq11+TWTlB5xqH6hWqRzAQ8LBOqN4pGVuDTH3upBFwtR3tXK2d5 ApW3ZyU82cka+GYSXf7CWZCLGXiJIwWW7ImOpZbb9r/Bih2bLEWeOAONxTL1+9hL3VCu 4NzpOGKRmvAxyrP1pJma5uEzH1RbZOVe7M46REyPmtXCryV/T544y/0fjL2nwcA+cnmM Ltgw== X-Gm-Message-State: ALoCoQlOJWsycAqZvtFWzqvVVRCaA4FuRiNRYwD+sGKNa7yHWho/bN82rMOV/nDddrWCyFBNf8lf X-Received: by 10.66.102.1 with SMTP id fk1mr13719038pab.111.1446777167231; Thu, 05 Nov 2015 18:32:47 -0800 (PST) Received: from t20010c400000302410534dd7129f08bf.v6.meeting.ietf94.jp (t20010c400000302410534dd7129f08bf.v6.meeting.ietf94.jp. [2001:c40:0:3024:1053:4dd7:129f:8bf]) by smtp.gmail.com with ESMTPSA id ko11sm10383951pbd.23.2015.11.05.18.32.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 18:32:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: James Woodyatt In-Reply-To: Date: Fri, 6 Nov 2015 11:32:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9C067C3D-E7EA-4FEF-975E-46A2D32317EC@nestlabs.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> To: "Howard, Lee" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 02:32:49 -0000 On Nov 6, 2015, at 06:56, Howard, Lee wrote: >=20 > Would somebody please explain to me exactly what NPT66 breaks? > Preferably in a way that could be included in a draft. Short answer: address referral is broken by NPTv6, which leads to = unilateral self-address fixing (UNSAF) services, which are themselves = fundamentally broken (see sections 2 and 3 of RFC 3424). =E2=80=94james.= From nobody Thu Nov 5 21:31: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 11C361A0203 for ; Thu, 5 Nov 2015 21:31:14 -0800 (PST) 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 SuBDv7gbYEdP for ; Thu, 5 Nov 2015 21:31:10 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7BF721A0193 for ; Thu, 5 Nov 2015 21:31:09 -0800 (PST) Received: (qmail 94937 invoked from network); 6 Nov 2015 05:31:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Nov 2015 05:31:07 -0000 Date: Fri, 06 Nov 2015 06:31:06 +0100 (CET) Message-Id: <20151106.063106.74659839.sthaug@nethelp.no> To: igor@gashinsky.net From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 05:31:14 -0000 > That makes it sound like IETF is not "endorsing" NPT66, as opposed to > actively recommending that people don't use it. I'm with Lorenzo here - > I would prefer very strong language in the form of "deployment of NPT66 is > concidered harmful" or "we strongly recommend against the use of NPT66". Okay, one more operator then. I want to have NPT66 (and ULA) available in the toolbox. Steinar Haug, AS 2116 From nobody Thu Nov 5 22:51: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 D258B1A916F for ; Thu, 5 Nov 2015 22:51:13 -0800 (PST) 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 a-0zbq3kwXpp for ; Thu, 5 Nov 2015 22:51:12 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 202321A9132 for ; Thu, 5 Nov 2015 22:51:12 -0800 (PST) Received: by ykdv3 with SMTP id v3so84365868ykd.0 for ; Thu, 05 Nov 2015 22:51:11 -0800 (PST) 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=K+O9zgjCj1cCyeqEOFCRrnCCDVm3g+Fzf36sTY20bwI=; b=Oh75DqCpISLVNaPvpvlSfLBG/FIO5ItbQAi5/CGraPTFHRQMQjRMsY12VSPRNVDeSj 78jh/F3UC2dlaSAS0XsHfS8c9VtG1cgWa+fynSVd2yNVHEG0zy4uTPWXdSQzqjvzECGk DCPxkqaa58n3wIBG7CEMa3TPA1qS/h6svIpFLKhZWoxSl9GsjClLOm58GYTceS92Qjbn 5OVfAoXQPBf2JwsU3vYJm+7R0I0scSGkgxqgDvMeYCiKNszhV2fejAdPfAkl7W8yy4mJ PT+wMaZb3z6EvWPYjvJPGuMTGxP45jLa1c8UUf0oK2TA8EZHQRY4HtPEAF3tpnao58TN rEqA== MIME-Version: 1.0 X-Received: by 10.31.162.148 with SMTP id l142mr11181510vke.40.1446792671410; Thu, 05 Nov 2015 22:51:11 -0800 (PST) Received: by 10.103.67.194 with HTTP; Thu, 5 Nov 2015 22:51:11 -0800 (PST) Received: by 10.103.67.194 with HTTP; Thu, 5 Nov 2015 22:51:11 -0800 (PST) In-Reply-To: <20151106.063106.74659839.sthaug@nethelp.no> References: <20151106.063106.74659839.sthaug@nethelp.no> Date: Fri, 6 Nov 2015 17:51:11 +1100 Message-ID: From: Mark Smith To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a114333d63e47300523d9ab23 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 06:51:14 -0000 --001a114333d63e47300523d9ab23 Content-Type: text/plain; charset=UTF-8 On 6 Nov 2015 4:31 PM, wrote: > > > That makes it sound like IETF is not "endorsing" NPT66, as opposed to > > actively recommending that people don't use it. I'm with Lorenzo here - > > I would prefer very strong language in the form of "deployment of NPT66 is > > concidered harmful" or "we strongly recommend against the use of NPT66". > > Okay, one more operator then. I want to have NPT66 (and ULA) available > in the toolbox. > Why would a recommendation against it prevent you using it on your network if you wanted to? How is the IETF recommending against it stopping you from using it? A recommendation not to do something is for people who fundamentally don't know better. If you know better, meaning you understand the costs and consequences, and the owners of the network are willing to pay those costs and deal with the consequences, then there is nothing stopping you. Nobody is and can force you to follow the recommendation in your own network. (Having directly and indirectly paid those costs and having dealt with the consequences of NAT in IPv4, I don't want to pay them in IPv6, and I don't think those who don't know better should inadvertently have to end up paying them either. I personally see the lack of reason for NAT, due to plenty of addresses, and mechanisms to help smoothly renumber, to be the most important properly if IPv6.) Regards, Mark. > Steinar Haug, AS 2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114333d63e47300523d9ab23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 Nov 2015 4:31 PM, <sthaug@neth= elp.no> wrote:
>
> > That makes it sound like IETF is not "endorsing" NPT66,= as opposed to
> > actively recommending that people don't use it. I'm with = Lorenzo here -
> > I would prefer very strong language in the form of "deployme= nt of NPT66 is
> > concidered harmful" or "we strongly recommend against t= he use of NPT66".
>
> Okay, one more operator then. I want to have NPT66 (and ULA) available=
> in the toolbox.
>

Why would a recommendation against it prevent you using it o= n your network if you wanted to? How is the IETF recommending against it st= opping you from using it?

A recommendation not to do something is for people who funda= mentally don't know better.

If you know better, meaning you understand the costs and con= sequences, and the owners of the network are willing to pay those costs and= deal with the consequences, then there is nothing stopping you. Nobody is = and can force you to follow the recommendation in your own network.

(Having directly and indirectly paid those costs and having = dealt with the consequences of NAT in IPv4, I don't want to pay them in= IPv6, and I don't think those who don't know better should inadver= tently have to end up paying them either. I personally see the lack of reas= on for NAT, due to plenty of addresses, and mechanisms to help smoothly ren= umber, to be the most important properly if IPv6.)

Regards,
Mark.

> Steinar Haug, AS 2116
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a114333d63e47300523d9ab23-- From nobody Thu Nov 5 23:14: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 342E61B30D5 for ; Thu, 5 Nov 2015 23:14:29 -0800 (PST) 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 iPZbN5tf7ugP for ; Thu, 5 Nov 2015 23:14:27 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id CD3F11B3109 for ; Thu, 5 Nov 2015 23:14:26 -0800 (PST) Received: (qmail 10110 invoked from network); 6 Nov 2015 07:14:25 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Nov 2015 07:14:25 -0000 Date: Fri, 06 Nov 2015 08:14:25 +0100 (CET) Message-Id: <20151106.081425.74651560.sthaug@nethelp.no> To: markzzzsmith@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20151106.063106.74659839.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 07:14:29 -0000 > > Okay, one more operator then. I want to have NPT66 (and ULA) available > > in the toolbox. > > > > Why would a recommendation against it prevent you using it on your network > if you wanted to? How is the IETF recommending against it stopping you from > using it? I would of course carefully consider the alternatives. But you're right that it probably wouldn't stop me if I concluded that NPT66 was the best solution. > A recommendation not to do something is for people who fundamentally don't > know better. Which leaves the people who would like to be provider independent in a slightly difficult situation. Recommend /48 PI for everybody? Still too difficult to acquire for many companies, and with significant scaling problems if enough people start using it. NPT66? "Harmful", as some people here would like the documents to say. Steinar Haug, AS 2116 From nobody Thu Nov 5 23:26: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 432E51A9175 for ; Thu, 5 Nov 2015 23:26:22 -0800 (PST) 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 dKBUSSYvuN8t for ; Thu, 5 Nov 2015 23:26:20 -0800 (PST) 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 3604A1A8B84 for ; Thu, 5 Nov 2015 23:26:19 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2999060AA4 for ; Fri, 6 Nov 2015 08:26:17 +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 E680360760 for ; Fri, 6 Nov 2015 08:26:16 +0100 (CET) Received: (qmail 78466 invoked by uid 1007); 6 Nov 2015 08:26:16 +0100 Date: Fri, 6 Nov 2015 08:26:16 +0100 From: Gert Doering To: "Howard, Lee" Message-ID: <20151106072616.GS70452@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 07:26:22 -0000 Hi, On Fri, Nov 06, 2015 at 01:31:02AM +0000, Howard, Lee wrote: > Proposed text: > ... it does have significant implications to applications, as documented > in [RFC6296] Section 5, which may cause some applications to break. > > Thus this document does not recommend the use of ULA+NPTv6. This I can perfectly agree to - it's a different message ("understand well what you do if you insist on going there"), and clear enough. 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 Nov 6 02:08: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 53C871B3879 for ; Fri, 6 Nov 2015 02:08:18 -0800 (PST) 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 DepfMIU066EO for ; Fri, 6 Nov 2015 02:08:14 -0800 (PST) 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 ADF571B3876 for ; Fri, 6 Nov 2015 02:08:13 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tA6A81H9040050 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 10:08:01 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local To: Lorenzo Colitti , "Howard, Lee" References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> From: Nick Hilliard X-Enigmail-Draft-Status: N1110 Message-ID: <563C7C01.6010703@foobar.org> Date: Fri, 6 Nov 2015 10:08:01 +0000 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="------------080301020707040301080103" Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 10:08:18 -0000 This is a multi-part message in MIME format. --------------080301020707040301080103 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/11/2015 00:20, Lorenzo Colitti wrote: > It breaks any application that requires that the application know its > source address. Examples are SIP, FTP, audio/video chat, etc. your argument is the wrong way around: some protocols deliberately introduce layering violations by demanding that transport identifier information is encoded at the application layer. Transport identifier translation merely shows up this brokenness. The brokenness is not with the translation mechanism but with the higher level protocols. You could argue that this is an angels-on-the-head-of-a-pin style argumen= t and that it doesn't matter which bit is broken because at the end of the day, breakage happens and users get hurt. The point is that is IETF working groups like to get up on their collective high horses about identifier translation but apparently don't bat an eyelid when people create entirely new protocols with glaring layering violations. I'd happy to see disapproval notices for NPTv6 appearing in this draft if= the IETF first issues explicit recommendations against using SIP, FTP, audio/video chat and all other protocols which mandate layering violation= s. I.e. at least the IETF should be even handed about this and not pretend that the root cause of the problem is somewhere where in fact it isn't. Nick --------------080301020707040301080103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 06/11/2015 00:20, Lorenzo Colitti wrote:
It breaks any application that requires that the application know its source address. Examples are SIP, FTP, audio/video chat, etc.
your argument is the wrong way around: some protocols deliberately introduce layering violations by demanding that transport identifier information is encoded at the application layer.  Transport identifier translation merely shows up this brokenness.  The brokenness is not with the translation mechanism but with the higher level protocols.

You could argue that this is an angels-on-the-head-of-a-pin style argument and that it doesn't matter which bit is broken because at the end of the day, breakage happens and users get hurt.  The point is that is IETF working groups like to get up on their collective high horses about identifier translation but apparently don't bat an eyelid when people create entirely new protocols with glaring layering violations.

I'd happy to see disapproval notices for NPTv6 appearing in this draft if the IETF first issues explicit recommendations against using SIP, FTP, audio/video chat and all other protocols which mandate layering violations.

I.e. at least the IETF should be even handed about this and not pretend that the root cause of the problem is somewhere where in fact it isn't.

Nick
--------------080301020707040301080103-- From nobody Fri Nov 6 02:15: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 043BF1B38A4 for ; Fri, 6 Nov 2015 02:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOrKehquM6TP for ; Fri, 6 Nov 2015 02:15:45 -0800 (PST) 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 AFC191B38A6 for ; Fri, 6 Nov 2015 02:15:32 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tA6AFUxY040258 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 10:15:30 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local To: Gert Doering , "Howard, Lee" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> <20151106072616.GS70452@Space.Net> From: Nick Hilliard Message-ID: <563C7DC2.3010704@foobar.org> Date: Fri, 6 Nov 2015 10:15:30 +0000 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: <20151106072616.GS70452@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 06 Nov 2015 10:15:47 -0000 On 06/11/2015 07:26, Gert Doering wrote: > On Fri, Nov 06, 2015 at 01:31:02AM +0000, Howard, Lee wrote: >> Proposed text: >> ... it does have significant implications to applications, as documented >> in [RFC6296] Section 5, which may cause some applications to break. >> >> Thus this document does not recommend the use of ULA+NPTv6. > > This I can perfectly agree to - it's a different message ("understand > well what you do if you insist on going there"), and clear enough. this is verging on "delenda est carthago" territory. Nick From nobody Fri Nov 6 04:47: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 D35B81A0210 for ; Fri, 6 Nov 2015 04:47:04 -0800 (PST) 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 lMsB7iWGd5IW for ; Fri, 6 Nov 2015 04:47:03 -0800 (PST) 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 B65211A0181 for ; Fri, 6 Nov 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1446814023; x=1448023623; h=date:from:message-id:to:subject:cc; bh=JzzrWpcDSuaSV11rLXbZK3jSRHmNItTkFE8QhwcP/Ug=; b=Sid0pnAvxFE01E0oPO7FV2fI3q1pZTVOBGBqmivmj23iooHYI2n/N/Rl r+eclOtlLd6EaSrcyNDARJWBaLbj2gIsU2oGFoC4oH7vbGtbveZrnT8NY gvuHTToBYSliG+/0XA75su7siNBsJ2zVeuFRYj66aKSTxMQNJPcmpjfQB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHBgDpnzxW/5tdJa1egztTcK8EAY8tgWAhhWYJgTs6EgEBAQEBAQGBCoQ4fTw0iQ4BDcE8AQEBBwEBAQEBHotShSeEEgWOEYg3hR2JYkmDd5YpKAwvhCWFZQEBAQ X-IronPort-AV: E=Sophos;i="5.20,252,1444694400"; d="scan'208";a="42547954" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Nov 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA6Cl28u002066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id tA6Cl2rE030379; Fri, 6 Nov 2015 04:47:02 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id tA6Cl2jH030359; Fri, 6 Nov 2015 04:47:02 -0800 Date: Fri, 6 Nov 2015 04:47:02 -0800 From: fred@cisco.com Message-Id: <201511061247.tA6Cl2jH030359@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-templin-v6ops-pdhost@tools.ietf.org Subject: [v6ops] new draft: draft-templin-v6ops-pdhost 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, 06 Nov 2015 12:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-templin-v6ops-pdhost. Please take a look at it and comment. From nobody Fri Nov 6 17:17: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 2E10F1AD1EE for ; Fri, 6 Nov 2015 17:17:16 -0800 (PST) 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 6rTrZ8wEwhse for ; Fri, 6 Nov 2015 17:17:14 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241091A854B for ; Fri, 6 Nov 2015 17:17:14 -0800 (PST) Received: by vkbk63 with SMTP id k63so14566495vkb.0 for ; Fri, 06 Nov 2015 17:17:13 -0800 (PST) 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=8G2Y9eNYv7AEUg4H0m7cdubYm8aPAl90nuKhafPZou8=; b=uAU5wP6KM3qnnOYdRySJFyc8BBKtPP3d94mItkhj3c7jf5LvBTh7+tNLjxAdSmN1/R CU0JLoHS7KL57vd+DG3kmRtAkDZozs5sxyFR+LPLFrlZ9nfaaTOj3KORCzZ8eo6pCoSd jQFKcGj/4rWq8R4TJtsz2MWgoc9DnvK/DzjjNwdtI5M2TIWRxvtx5+dGNIrjSqLFEv+Q Mmxv87YTCWkyNEWzflP0AXKCPCVEQImpjUNKQ5jEcQrPPpP5DD1thhzd4RmEuHOBly58 RJfzpVeKg6v7HMTlIBqUizNT2SDQbH8YfrfgEsTaGQwGmK6lpy5FcXmvnt3HK/2TOOpF kP8g== X-Received: by 10.31.54.145 with SMTP id d139mr13465371vka.132.1446859033307; Fri, 06 Nov 2015 17:17:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.67.194 with HTTP; Fri, 6 Nov 2015 17:16:43 -0800 (PST) In-Reply-To: <563C7C01.6010703@foobar.org> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> From: Mark Smith Date: Sat, 7 Nov 2015 12:16:43 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 07 Nov 2015 01:17:16 -0000 On 6 November 2015 at 21:08, Nick Hilliard wrote: > On 06/11/2015 00:20, Lorenzo Colitti wrote: > > It breaks any application that requires that the application know its source > address. Examples are SIP, FTP, audio/video chat, etc. > > your argument is the wrong way around: some protocols deliberately introduce > layering violations by demanding that transport identifier information is > encoded at the application layer. Transport identifier translation merely > shows up this brokenness. The brokenness is not with the translation > mechanism but with the higher level protocols. > > You could argue that this is an angels-on-the-head-of-a-pin style argument > and that it doesn't matter which bit is broken because at the end of the > day, breakage happens and users get hurt. The point is that is IETF working > groups like to get up on their collective high horses about identifier > translation but apparently don't bat an eyelid when people create entirely > new protocols with glaring layering violations. > > I'd happy to see disapproval notices for NPTv6 appearing in this draft if > the IETF first issues explicit recommendations against using SIP, FTP, > audio/video chat and all other protocols which mandate layering violations. > So this draft is advice about what should and shouldn't be done in the network. Networks need to aim to best facilitate applications, because supporting applications is the *sole* reason for networks (a network without applications has no reason to exist). Network shouldn't be imposing limitations on applications that don't need to be there, because it creates a cost and causes cost shifting - the cost of those network limitations ends up being borne by the applications, as they then have to implement mechanisms to work around those limitations, and they will, hence STUN, TURN, UDP or HTTP encapsulation of other protocols. We know that some applications use IP addresses as identifiers, and we should be recommending IPv6 network deployments that best support applications our networks' customers want to use, not telling them "don't use that application because it stops me using a type of device/function in the network I might want to use.". Doing so is forgetting who's creating the need and reason for network operators existence. Regards, Mark. From nobody Sat Nov 7 09:45: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 1A03A1AC40A for ; Sat, 7 Nov 2015 09:45:14 -0800 (PST) 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 YBSeexYo_ZkC for ; Sat, 7 Nov 2015 09:45:12 -0800 (PST) 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 8DE9E1A9236 for ; Sat, 7 Nov 2015 09:45:12 -0800 (PST) Received: by vkfw189 with SMTP id w189so34125576vkf.2 for ; Sat, 07 Nov 2015 09:45:11 -0800 (PST) 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=R0XjdOp6Z7GDkgazJwA3YgtY0/RizGtpTr+EZSlUsqE=; b=zUnoyPsiqMx9YrLZweOzRxR1dFK0uPqvYofN5pmPUO7MiX2kHQMQiQMvhP9Y6tjOEp 78j8wvlobmzddd4/wV6O9mZ1qLURmcIzZxRgQGFUuZHKktzPV2sqZtOL15rEXRR+s5gv 3VOYgwKLeGd2rJp5QUkbfbfhO51uSFI2fB04M+bN3kgbtzoQgv7AnvaTFpWs9cOsxnu9 JRxSR3k2nDZCjD6qJjy5g/dIoIyi4KADiML2Gy81Mq+KKtmI77EnZt+7ZDXzm83GQi6O 6KGVTYIfl+L3eDFYj0yFPXglw33SzpDh5vlFk1Tq3xmk3188GgeF63axCjWwzjS8JYFT R5cg== X-Received: by 10.31.107.81 with SMTP id g78mr15205187vkc.6.1446918311650; Sat, 07 Nov 2015 09:45:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.140.74 with HTTP; Sat, 7 Nov 2015 09:44:52 -0800 (PST) In-Reply-To: <201511061247.tA6Cl2jH030359@irp-lnx1.cisco.com> References: <201511061247.tA6Cl2jH030359@irp-lnx1.cisco.com> From: Naveen Kottapalli Date: Sat, 7 Nov 2015 23:14:52 +0530 Message-ID: To: fred@cisco.com Content-Type: multipart/alternative; boundary=001a11479326fc29fd0523f6ebdd Archived-At: Cc: v6ops@ietf.org, draft-templin-v6ops-pdhost@tools.ietf.org Subject: Re: [v6ops] new draft: draft-templin-v6ops-pdhost 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, 07 Nov 2015 17:45:14 -0000 --001a11479326fc29fd0523f6ebdd Content-Type: text/plain; charset=UTF-8 One typo error in the below paragraph. In that case, the default router can send a Redirect to inform the node of a better first hop. The Redirect populates an entery in the node's neighbor cache for the WAN interface, and future packets can take the more direct route without disturbing the default router. The Redirect can apply either to a singleton destination address, or to an entire destination prefix as described in AERO Yours, Naveen. On 6 November 2015 at 18:17, wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-templin-v6ops-pdhost. Please take a look > at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11479326fc29fd0523f6ebdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One typo error in the below paragraph.

= 
In that case,
   the default router can send a Redirect to inform the node of a better
   first hop.  The Redirect populates an ent=
ery in the node's neighbor
   cache for the WAN interface, and future packets can take the more
   direct route without disturbing the default router.  The Redirect can
   apply either to a singleton destination address, or to an entire
   destination prefix as described in AERO

Yours,Naveen.

On 6 November 2015 at 18:17, <fred@cisco.com<= /a>> wrote:
A new draft has bee= n posted, at http://tools.ietf.org/html/draft-t= emplin-v6ops-pdhost. Please take a look at it and comment.

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

--001a11479326fc29fd0523f6ebdd-- From nobody Sat Nov 7 10:29: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 54E541AD0AF for ; Sat, 7 Nov 2015 10:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dNbTryKvoWF for ; Sat, 7 Nov 2015 10:29:04 -0800 (PST) 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 290471AD0AA for ; Sat, 7 Nov 2015 10:29:03 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tA7ISlQ4095360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2015 18:28:47 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local To: Mark Smith References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> From: Nick Hilliard X-Enigmail-Draft-Status: N1110 Message-ID: <563E42DE.4090708@foobar.org> Date: Sat, 7 Nov 2015 18:28:46 +0000 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 07 Nov 2015 18:29:06 -0000 On 07/11/2015 01:16, Mark Smith wrote: > Networks need to aim to best facilitate applications, because > supporting applications is the *sole* reason for networks (a network > without applications has no reason to exist). Network shouldn't be > imposing limitations on applications that don't need to be there, > because it creates a cost and causes cost shifting - the cost of those > network limitations ends up being borne by the applications, as they > then have to implement mechanisms to work around those limitations, > and they will, hence STUN, TURN, UDP or HTTP encapsulation of other > protocols. What you probably mean is: - "end users", not "applications" - "networks and protocols", not "networks" If you make those replacements in what you wrote, you end up with something which is not just more accurate, but also a lot more balanced. > We know that some applications use IP addresses as identifiers, and we > should be recommending IPv6 network deployments that best support > applications our networks' customers want to use, not telling them > "don't use that application because it stops me using a type of > device/function in the network I might want to use.". Doing so is > forgetting who's creating the need and reason for network operators > existence. The relevant warnings, with clear identification about causes and effects, are already present in rfc6296 and rfc5902. Both these rfcs are already referenced in this ID, although I note sadly that 5902 omits any mention of layering violations by higher level protocols being one of the primary contributory factors to end-user breakage. This particular horse has been flogged to death already and there's no need to flog it any more in this draft. Nick From nobody Sat Nov 7 14:56: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 B64381A21C1 for ; Sat, 7 Nov 2015 14:56:25 -0800 (PST) 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 dCRJ4jeXV0Kv for ; Sat, 7 Nov 2015 14:56:24 -0800 (PST) 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 5BB6B1A21BB for ; Sat, 7 Nov 2015 14:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2199; q=dns/txt; s=iport; t=1446936984; x=1448146584; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VcmnOCSEwFC+o+KOjPTV9JLpFpchpXiDmiUCTPAttnY=; b=F+kRuWj5pGfdoV4eptikrnLko8yPxLg3RDc/wzUJ/8aaVX2ZZZ/kmk8b 2J2hLGVZt7UTRYbgi8KeAbenCAvi99MZRAVTDfJ3z9IbrQZo7aldzgfu7 VhQMHpEMfPq6Ux8r9rPvFsSDtt+KTB/RtLwD2yoJ+FUW39wtNjhVk8D31 E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuAgASgT5W/5xdJa1dgzuBQga+JQ6BYYYQAoEbOBQBAQEBAQEBgQqENgEBBHkQAgEIGC4yJQIEDgUOiCDBGgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8JiGSCbogkgRUFlkgBglKBYYhznEQBHwFDhARyhF+BBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,258,1444694400"; d="asc'?scan'208";a="48386680" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2015 22:56:21 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA7MuL1H028780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2015 22:56:21 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; Sat, 7 Nov 2015 17:56:20 -0500 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, 7 Nov 2015 17:56:20 -0500 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRGa+EhFq8vQENcEGKjk9klBS37w== Date: Sat, 7 Nov 2015 22:56:20 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> In-Reply-To: <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> 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.156] Content-Type: multipart/signed; boundary="Apple-Mail=_1DA79DED-D7EC-4436-A40C-ECEB4F714D2E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 07 Nov 2015 22:56:25 -0000 --Apple-Mail=_1DA79DED-D7EC-4436-A40C-ECEB4F714D2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2015, at 3:17 PM, Mark Andrews wrote: > We should also demonstrate that ULA in conjuction with other GUA is = not harmful. I think the point that has to be shown is that it *is* harmful. We = didn't have to prove link-local, multicast, unicast, 6to4, or any other = address non-toxic; what makes ULA special? On this list, several operators have stated that they use ULAs in = addressing things like cable modems and mobile network infrastructure. = If the issue with ULA is NAT, those are examples of devices that need no = NAT - for the simple reason that they don't speak outside their domains. = However, they are indeed local to a network and their prefix SHOULD NOT = be advertised to neighboring networks, nor accepted by those networks if = inadvertently advertised. That really doesn't sound very toxic. --Apple-Mail=_1DA79DED-D7EC-4436-A40C-ECEB4F714D2E 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 iQIUAwUBVj6BkUayAOS/EQ8MAQJ1UQ/3eCI3ommcUkgGn5AOgdQKdG44kFTY0q5v Ji2j2vsw2TUBcFC1P0dcKaPafxioPJwHUl1NGs/f3AasChyyI2pbU9cHPgEfQTbB RPQ1QVTEVCipaL8eX/RTBSUQntuLGHpystBGrFKvAo7dfa7OgLgcidzqydXDoxHa zLBeAcPuOmAIfSnSsVVxSDU1pyZzL+45YT7wEUyRineXkGIVBa0nSQNuFCK5Z3s9 MHA0AJXpj2uXiq+yGXwVwN/fwoeGK2Ht1JJaJstFntP+zu6BiR8CTlPNlpXtwKwR AJgvdOYjA9JZqCm6uOjqlocFedyYD+kzFehIDU+SP9zgL7V8jO+layQcnLrvmTiY vTtBa//lUAVeo2Knvw2ZqaNnxrb5aQLPPLD7ijlsAHnh3dwapSxY2f0S1l5IpcQx PNxRJ75PZSkqnE/NRVIOMPc7siIsxPkGRGXtz3vUYilI97uRgHDJiFJGqRe3W739 zUkVHp0V5iI1Q3aUQ0lV1/1B6xrxtq+mPsiPkyzPcjlHVV3dxeWK5abdg/kUcG24 sy35iDV8AcXF4Nb4u7StBV6vME2ocPbuQAQIqucXSp56g6fO3kO9v2SD1nHrZa57 U52lMrp38o1FKk1JgD/4b5DvCfIihQSIm53EdHBQA0mgfw4N319l8mBoTnPk6HTw V//O/PFadg== =VqOb -----END PGP SIGNATURE----- --Apple-Mail=_1DA79DED-D7EC-4436-A40C-ECEB4F714D2E-- From nobody Sat Nov 7 15:45: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 957851B363D for ; Wed, 4 Nov 2015 17:44:04 -0800 (PST) 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 eniKvWf3omGm for ; Wed, 4 Nov 2015 17:44:03 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195F31B363C for ; Wed, 4 Nov 2015 17:44:03 -0800 (PST) Received: from [133.93.28.217] (dhcp-28-217.meeting.ietf94.jp [133.93.28.217]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tA51hqp7005352 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2015 17:43:53 -0800 To: "Fred Baker (fred)" , "v6ops@ietf.org WG" References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> From: Erik Nordmark Message-ID: <563AB457.20302@sonic.net> Date: Thu, 5 Nov 2015 10:43:51 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 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 X-Sonic-CAuth: UmFuZG9tSVYLGYgVUsZRhZ6dCnmo54Z2R2R18M5dBfGwVCBc+pyWENosZZDh9d0wK7EFoIZXaJqrhpJTCEoxiGI4WaU7Mhzv X-Sonic-ID: C;YuPXql6D5RGXreK7sH9FTg== M;Ynhgq16D5RGXreK7sH9FTg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Sat, 07 Nov 2015 15:45:30 -0800 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, 05 Nov 2015 01:44:04 -0000 On 10/2/15 3:39 AM, 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 > > > 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. Fred, I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and fully agreed with the the recommendations in section 4 about implementation and configuration of routers. However, in 01 there was a section added (4.2 - now 5.2) with device side recommendations/requirements, with with I have serious reservations at several levels: 1. The text uses terms like "maintain IPv6 connectivity" and "disconnect from the IPv6 network" which are not defined. I would not know what impact this has on an implementation with those terms being defined. E.g., does "disconnect" mean to discard all IPv6 addresses and prefixes and release all DHCPv6 leases? Kill all connections? What? 2. Section 5.2 changes (or at least clarifies) the IPv6 standards which seems to not be in scope in the v6ops charter. Thus I think section 5.2 should be removed and that discussion be had in the 6man WG. Sorry for not catching the scope expansion in -01 earlier. Regards, Erik > >> 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: >> >> 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Nov 7 15:45: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 565D71B2CD1 for ; Thu, 5 Nov 2015 05:53:58 -0800 (PST) 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 TFXmfjDLTDvI for ; Thu, 5 Nov 2015 05:53:56 -0800 (PST) Received: from prime.conjury.org (prime.conjury.org [IPv6:2607:f2f8:a938::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878721B2CD5 for ; Thu, 5 Nov 2015 05:53:55 -0800 (PST) Received: from [10.71.13.83] (122x216x24x202.ap122.ftth.ucom.ne.jp [122.216.24.202]) by prime.conjury.org (Postfix) with ESMTPSA id 8733486E5E; Thu, 5 Nov 2015 05:53:54 -0800 (PST) References: <7B3C244B-8B06-4DD6-A8FD-B4B1A64D66A0@gmail.com> <9130A0EE-04F3-4B99-B675-AE4DC5B5BBBC@gmail.com> <8FC43AD9-F854-4763-AA8B-EF1F64493AB7@nestlabs.com> <5626D56C.4090706@umn.edu> <56297ACF.4000701@umn.edu> <33751EAE-1F00-4A54-9D74-6CD1839F86AB@gmail.com> <562AC9B0.4020409@umn.edu> <0A008CF4-86EE-470C-9C87-241ACC812D28@gmail.com> <5FD4B50E-9481-445F-BD10-7200C919BE60@nestlabs.com> <537F1DC8-DE42-4BD3-986A-C6C89493827D@nestlabs.com> <9F630BB6-55E8-420A-A3F1-955A274B19AF@gmail.com> From: james woodyatt Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (12H321) In-Reply-To: <9F630BB6-55E8-420A-A3F1-955A274B19AF@gmail.com> Message-Id: <08128F4B-4352-46E1-B346-6CB2E4B01219@conjury.org> Date: Thu, 5 Nov 2015 22:53:53 +0900 To: Bob Hinden , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: X-Mailman-Approved-At: Sat, 07 Nov 2015 15:45:30 -0800 Subject: Re: [v6ops] RFC2119 Upper Case Syntax for rfc2460bis 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, 05 Nov 2015 13:53:58 -0000 Sigh. Of course it doesn't. It merely says the keywords are "often" capitali= zed. It then proceeds to use the keywords itself, and always capitalizes the= m. I stand corrected. I give up. There is no winning here. =E2=80=94sent from my phone > On Nov 5, 2015, at 18:55, Bob Hinden wrote: >=20 > James, >=20 >> That=E2=80=99s why having a note right there in RFC 2460bis that explains= the divergence from the recommended capitalization strategy is an acceptabl= e compromise to me. >=20 > While I am not against adding text to clarify how the language is used in t= hese drafts, but please show where it says that capitalization is required o= r even recommended? It doesn=E2=80=99t say that in RFC2119. >=20 > Bob >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Nov 7 17:38: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 B3E5B1A1A6D for ; Sat, 7 Nov 2015 17:38:00 -0800 (PST) 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 mSgogeqBIXNw for ; Sat, 7 Nov 2015 17:37:59 -0800 (PST) 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 974DE1A1A62 for ; Sat, 7 Nov 2015 17:37:59 -0800 (PST) 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 2F9E9349315; Sun, 8 Nov 2015 01:37:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 63AAE160044; Sun, 8 Nov 2015 01:38:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 503AE160059; Sun, 8 Nov 2015 01:38:05 +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 g1vG8T70uOYc; Sun, 8 Nov 2015 01:38:05 +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 072E6160044; Sun, 8 Nov 2015 01:38:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A3C9D3C120BF; Sun, 8 Nov 2015 12:37:50 +1100 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <5637FDD0.70300@jvknet.com> <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> In-reply-to: Your message of "Sat, 07 Nov 2015 22:56:20 -0000." Date: Sun, 08 Nov 2015 12:37:50 +1100 Message-Id: <20151108013750.A3C9D3C120BF@rock.dv.isc.org> Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 01:38:00 -0000 In message , "Fred Baker (fred) " writes: > > On Nov 3, 2015, at 3:17 PM, Mark Andrews wrote: > > We should also demonstrate that ULA in conjuction with other GUA is not > harmful. > > > > I think the point that has to be shown is that it *is* harmful. We didn't > have to prove link-local, multicast, unicast, 6to4, or any other address > non-toxic; what makes ULA special? We have also had people argue that using ULA w/ GUA is harmful as they are worried about connections timing out and address selection rules from various points in time. We know ULA + NAT is harmful. Practical demonstrations of the alternatives working will eliminate some of the fears people have for using ULA + GUA (PA). > On this list, several operators have stated that they use ULAs in > addressing things like cable modems and mobile network infrastructure. If > the issue with ULA is NAT, those are examples of devices that need no NAT > - for the simple reason that they don't speak outside their domains. > However, they are indeed local to a network and their prefix SHOULD NOT > be advertised to neighboring networks, nor accepted by those networks if > inadvertently advertised. > > That really doesn't sound very toxic. It isn't. > k > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Nov 7 17:51: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 777B61A70FE for ; Sat, 7 Nov 2015 17:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 qWU9tPumAZ6i for ; Sat, 7 Nov 2015 17:51:08 -0800 (PST) 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 3CB5D1A70FD for ; Sat, 7 Nov 2015 17:51:08 -0800 (PST) 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 AE39B349315; Sun, 8 Nov 2015 01:51:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EE332160044; Sun, 8 Nov 2015 01:51:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DFC2F160059; Sun, 8 Nov 2015 01:51: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 yYzKZEMIvAus; Sun, 8 Nov 2015 01:51: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 9ED35160044; Sun, 8 Nov 2015 01:51:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E16F33C121F8; Sun, 8 Nov 2015 12:50:59 +1100 (EST) From: Mark Andrews References: <5637FDD0.70300@jvknet.com> <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> <20151108013750.A3C9D3C120BF@rock.dv.isc.org> In-reply-to: Your message of "Sun, 08 Nov 2015 12:37:50 +1100." <20151108013750.A3C9D3C120BF@rock.dv.isc.org> Date: Sun, 08 Nov 2015 12:50:59 +1100 Message-Id: <20151108015059.E16F33C121F8@rock.dv.isc.org> Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 01:51:09 -0000 The IETF network has been traditionally configured as a PI multi-homed network. Most of the vendors that turn up have PI multi-homed networks (Cisco, Juniper, Apple, Microsoft, ISC). This leaves gaps in practical experience. It would be useful for the IETF network to altenate from PI model to PA model, along with all the workarounds for the limitations that come with the PA model, periodically. To test renumbering. We are wanting smaller sites to move from PA + NAT (IPv4) to PA + ULA (IPv6). We should be subjecting ourselves to that configuration. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Nov 7 18:53: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 20E011B29ED for ; Sat, 7 Nov 2015 18:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.511 X-Spam-Level: X-Spam-Status: No, score=-116.511 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, 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 nYPqD6JVbWIK for ; Sat, 7 Nov 2015 18:53:08 -0800 (PST) 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 B03831B2A01 for ; Sat, 7 Nov 2015 18:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2008; q=dns/txt; s=iport; t=1446951188; x=1448160788; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hh6Kg8Q4cYf2LESydsF4kmwy8U3EK5iZoa5pYoaOsgI=; b=FWArBAdnj6iShDz16I2U72gDPza8GyX1oIJ949lNTF5+urjSZqGNYgcH yMovl6CkNylRF8kCerQ6qS1NBYIrRbZSag7lkb5U+DhnRA5hwrxePg6uJ bWujYnHh+6h9CrSC0QabfLHrGaO8TGuNhX+4cTjpzj9hKwsz0z6NTzcjE g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAgD1tz5W/5RdJa1egzuBQga+JA6BY?= =?us-ascii?q?YYQAoEbOBQBAQEBAQEBgQqENQEBAQMBeQULAgEIGC4yJQIEDgUOiBgIwREBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEPCYhkgm6IJIEVBZZIAYJSgWGIc5xEAR8BQ4QEc?= =?us-ascii?q?oRfgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,260,1444694400"; d="asc'?scan'208";a="205611478" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2015 02:53:08 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA82r7ZC002238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2015 02:53:07 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 7 Nov 2015 21:53:06 -0500 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, 7 Nov 2015 21:53:06 -0500 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRGdCYYRKmLLsK4kOhvs9CJLWv9g== Date: Sun, 8 Nov 2015 02:53:06 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <20151103061723.3C7DA3BBB9D8@rock.dv.isc.org> <20151108013750.A3C9D3C120BF@rock.dv.isc.org> <20151108015059.E16F33C121F8@rock.dv.isc.org> In-Reply-To: <20151108015059.E16F33C121F8@rock.dv.isc.org> 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.100.235] Content-Type: multipart/signed; boundary="Apple-Mail=_4358CBD6-1F26-44C4-987D-639B05CDE4B3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 02:53:10 -0000 --Apple-Mail=_4358CBD6-1F26-44C4-987D-639B05CDE4B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 8, 2015, at 10:50 AM, Mark Andrews wrote: >=20 > We are wanting smaller sites to move from PA + NAT (IPv4) to PA + > ULA (IPv6). We should be subjecting ourselves to that configuration. I commented to the authors of draft-ietf-v6ops-design-choices that they = would do well to mention PA and PA+ULA as separate choices, to help the = conversation to not rathole on the subject of ULA. They didn't choose to = do so, but I would commend the thought to the working group. If you don't like ULAs, don't use them. I would encourage discussion of the draft to find another three letter = acronym to focus on. The recurrent theme gets boring. --Apple-Mail=_4358CBD6-1F26-44C4-987D-639B05CDE4B3 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 iQIVAwUBVj65EUayAOS/EQ8MAQLPaw//QGgIRlaVPfKM1fQq0kJBFwPoY0772+wx cVhBmwO1gze/Qz+lmXjRKGEp5o3DpMjk7JTGbNjwLAMxI/62Icct47FHO3JF2HO5 iRTDnQQ5fE3GcTSZWAwX1w9IKplJzGQojzyWEOK9zz/Uizxbodn9/Nj7BggQtyma jDz9ij76X3EctlhgwtASXAP4G/8m/h6CAYMoRTzLNjimsSRxmAbWla2B2Vvb5Kku HGR2h45mIuA9k2ezyHpUAJV0ucEr2dmAVgp/G9PSeVkc87Iuz1qymHW0gYk2aZyR yJ6S6/jPSiZLYhadsDyoRGp3FwNkeXmvC/170LGB3DwNt81ilkTVKQFNRsXniGd3 czc2aU2IpT5QhpNCfP3nYxQuOpcues51kSP5YhEPGscZYTdii30GT/KZRi/BrM3k YihMeS8CsA+0Jw4e7q7rpifkiuEeTWhZOHKVfU4ktjH95KgpZI7GjlSEJd9UpsJv rWCiFoAYVtBrwjDZvr9DQlCTR+9eKsb4moJ1uIHmEFTacfFyiLpNZfY1iEZtx1TW irbNNauc39VBgSgjURJ6dvZQ5xspOQOLIDANYjQ9k2ThBaiePfzLBEWPyP4mOLPf zzqZ+Wj/SdZrg5P3HcnilPuQGUg4xGD59IBK9tRgQ4ApmDevJVS6/Jmhl+AcaGLK YnW6ggiOiMY= =O/Oh -----END PGP SIGNATURE----- --Apple-Mail=_4358CBD6-1F26-44C4-987D-639B05CDE4B3-- From nobody Sat Nov 7 21:25: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 219CC1AD49D for ; Sat, 7 Nov 2015 21:25:56 -0800 (PST) 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 LYScoFtEC4Qp for ; Sat, 7 Nov 2015 21:25:55 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 D09FA1B396C for ; Sat, 7 Nov 2015 21:25:54 -0800 (PST) Received: by ykdr3 with SMTP id r3so223794500ykd.1 for ; Sat, 07 Nov 2015 21:25:54 -0800 (PST) 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=ny1s6Pu4jelufa+L9kC3+pX/HcQSxsYbNwiKvDCye94=; b=HJkp4FNayc2KSNdFXoKeuCmutofdxfO/iaOAnQpMKDtaliBytbsQfZVqn8pmS0hpp6 Q62ISBOQtdbdOvd24LQLhnblsdUIuDYT7YuSmG9R0M+QK67rJq0VgEVM++JEDAmpj8uh 0LEe6aFbf6aDOUkEii1Yr7KEroch2I6MuSSAPqqrfEOuuLR9WOdTL00lMoMcIYoFzgCR YTjBmT5vh/OPS/pHRY7o86LwT0MKGsHvkrK18mSLInoYg+RPmm3w7juGj//0br55T6Bm WotHlRe5iHHLfmlNeC5tn6CnBxv1Atl+KIg8D2Dg6GUHLJYhgOItV0tX0JgAq43XqDZ5 XRsw== 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=ny1s6Pu4jelufa+L9kC3+pX/HcQSxsYbNwiKvDCye94=; b=LK+zsZrL6X3s0NdThLauLFYbvx5moyxBFWT+hZLHqkhTkP+MOLnD5nJ3dFkJYLIdXI MZ8gK42fQ4bZd5nMNEMt2iI9WVD9sfX0NW7QyhJDoJ2IM4FssF4d3aC+gqfV7hS2EnBP ILH7eeIAUDOPe2x1vKSCC4M39a35LzbdRSektBKj7VlaKY8nY1CqHa/k/tFLfd62erH7 NBgFU0PSWbWXZxG0eVY/rX0Y84owJ1ytV6oBLl3qbAjHIQkT9UMcnSGKbhLco/N75TZc IAIlbEd+WpcJUYM2hClBYoHIAIGai8wTakSQ7eftVzjmxtpu9QG7LUKPkTPzkrNGjv+l Asqg== X-Gm-Message-State: ALoCoQn1cD0nj1lGK9A+RwZemf2nTYS56TRJqtDBMcsnncOdIGxO0QSMo5mWfzFlPsIBLJ/7vPlr X-Received: by 10.129.90.193 with SMTP id o184mr20317538ywb.123.1446960354060; Sat, 07 Nov 2015 21:25:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Sat, 7 Nov 2015 21:25:34 -0800 (PST) In-Reply-To: <563C7C01.6010703@foobar.org> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> From: Lorenzo Colitti Date: Sun, 8 Nov 2015 14:25:34 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a11491634e8d979052400b512 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 05:25:56 -0000 --001a11491634e8d979052400b512 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard wrote: > On 06/11/2015 00:20, Lorenzo Colitti wrote: > > It breaks any application that requires that the application know its > source address. Examples are SIP, FTP, audio/video chat, etc. > > your argument is the wrong way around: some protocols deliberately > introduce layering violations by demanding that transport identifier > information is encoded at the application layer. Transport identifier > translation merely shows up this brokenness. The brokenness is not with > the translation mechanism but with the higher level protocols. > Nope. Those protocols aren't broken, they worked fine for years until NAT arrived and broke them. They still work fine on networks that operate the way the Internet was originally designed with end-to-end connectivity. --001a11491634e8d979052400b512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 6, 2015 at 7:08 PM, Nick Hilliard <nick@foobar.org> wr= ote:
=20 =20 =20
On 06/11/2015 00:20, Lorenzo Colitti wrote:
It breaks any application that requires that the application know its source address. Examples are SIP, FTP, audio/video chat, etc.
 your argument is the wrong way around: some protocols deliberately introduce layering violations by demanding that transport identifier information is encoded at the application layer.=C2=A0 Transport identifier translation merely shows up this brokenness.=C2=A0 The brokenness is not with the translation mechanism but with the higher level protocols.

Nope. Those = protocols aren't broken, they worked fine for years until NAT arrived a= nd broke them.=C2=A0They still work fine on networks that operate the way t= he Internet was originally designed with end-to-end connectivity.
--001a11491634e8d979052400b512-- From nobody Sat Nov 7 21:28: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 3F1D51B397E for ; Sat, 7 Nov 2015 21:28:00 -0800 (PST) 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 2WPi9zEpDNpD for ; Sat, 7 Nov 2015 21:27:59 -0800 (PST) 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 34C8B1B3971 for ; Sat, 7 Nov 2015 21:27:59 -0800 (PST) Received: by ykek133 with SMTP id k133so224076637yke.2 for ; Sat, 07 Nov 2015 21:27:58 -0800 (PST) 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=JiRMIlis5cP2hZb4Yiy/INBBe4iFNBk5wC6ynGlo4RU=; b=dhhQuV9Tafmnlt2uvcm9m7deBKy+y0EBRkECERNlzkf3Z/K95lwHKVm35fj05LNK4c sRZj1/Or47aF0xALzCUVXqRWUzZt1wX+uK6oZ2Rfz3CsnYMQKS9QVb3yVd/OACjsqBRr SMqfxlfXPmLie9nWACAZm0Z2pYXAi7H1TH4RN8GYh9LJ5h7lBwFWBkpD8gyuE4NW75iI TbPA8sSbIocmpzGu9Ro0YxwifExXCJI3PizyBq3XYsBNArjv2/BbKGF+qHCaXO8VDvb+ +daY0A9HT4M1w4rQ+FzAjChYe6poRJ4Dua+sspgyTC8C4SjAd3gFp8NRqxwKl8S6aKCp GtTQ== 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=JiRMIlis5cP2hZb4Yiy/INBBe4iFNBk5wC6ynGlo4RU=; b=BLq9heaST7PEPHVG/8DsfG9wFJBk7xHpqGk6RkUYqgNFeQi5E2VxeOSCShe05Rf2Vn 4t79kBUkxx1Tc/x/cYc9pxG4DA+vOhluU4ijfpqq80Vp+Gc9aLcyfvSiJyoenVTb03um 2J24gAK0BxcHrx63MEiI1I2wY48OIRJfBVTfxoiphqE0QdCB9I/hKL/TBvsmQVm4KHS8 EcqRpGGPQQkjBiXpgOB1Zx3AzWbD7XImZJ9+KMCVlzRFOEBFSZh4QqvLXYF+XN6ZT7PQ E36q0rCjxoNxi/m0VCTI1Q46hmPIicM8GNEK8iarYRzU8i02r+RQ+f9pHptatUwkJIbG FtJg== X-Gm-Message-State: ALoCoQnbS/W0HmfHaD/OvSRGi4g0hhMtASNx/eXEOEyxffbRhHHVWRrSCW/wDQp/vwkxAXRcy/oG X-Received: by 10.13.204.73 with SMTP id o70mr19767910ywd.337.1446960478490; Sat, 07 Nov 2015 21:27:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Sat, 7 Nov 2015 21:27:38 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> From: Lorenzo Colitti Date: Sun, 8 Nov 2015 14:27:38 +0900 Message-ID: To: "Howard, Lee" Content-Type: multipart/alternative; boundary=001a11481d4a5381cd052400bd4f Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 05:28:00 -0000 --001a11481d4a5381cd052400bd4f Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 10:31 AM, Howard, Lee wrote: > Are we there yet? > I don't think we ever will be. --001a11481d4a5381cd052400bd4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 6, 2015 at 10:31 AM, Howard, Lee <lee.howard@twcable.com&= gt; wrote:
Are we there yet?

I don't think we ever will be.=C2=A0
--001a11481d4a5381cd052400bd4f-- From nobody Sat Nov 7 22:21: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 E3F1F1A6F82 for ; Sat, 7 Nov 2015 22:21:51 -0800 (PST) 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 ur2TdUYgP-An for ; Sat, 7 Nov 2015 22:21:46 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 203C21A6F42 for ; Sat, 7 Nov 2015 22:21:46 -0800 (PST) Received: by obctp1 with SMTP id tp1so120339070obc.2 for ; Sat, 07 Nov 2015 22:21:45 -0800 (PST) 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=QK7RvY+sYZJ9uY5I8MgFyMZbU3ReI9OCl8FikK+mZUw=; b=MaM8xDqsbYCbbjYDTVTY7/A4NJK4qnVDvm/hhTuzw++ji0tU6ZKg2n5gIeIGRTlHC0 fAspKSUMw6eKaKlTvBNU5c7oEDLIqoylpTP1ixb6+C2gYYX9vuLJYtZ05xDsVd8N9M2b UHIk8ifIWoaKUnx3aTeaAOxO9ccnmeavXDBBoZk70+168dgT6MFq22Ty15K2iqrTRs6h 8WMWQMQR6yk+sFLfK/SlWa3WpDsMHURm9kzVZAPRlX0s19o7d/pCHYWW6D6beycb4+p/ CyElrRoK3pWcRDI9Gh+xPXez//WC3dl29YdbgkYSJn3LT/j3i7WIv1KV+AfefKeDrggF WBBg== X-Received: by 10.182.181.65 with SMTP id du1mr12952269obc.71.1446963705227; Sat, 07 Nov 2015 22:21:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.84.197 with HTTP; Sat, 7 Nov 2015 22:21:05 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> From: "Mukom Akong T." Date: Sun, 8 Nov 2015 10:21:05 +0400 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=089e0158b49ea7317b0524017db3 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 08 Nov 2015 06:21:52 -0000 --089e0158b49ea7317b0524017db3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 November 2015 at 03:30, Templin, Fred L wrote: > Hi - let's lay this out fully so we can clearly understand the DAD > implications. > > Let's say a node 'N' has a WAN interface (the one that connects to the > provider > network), a loopback interface, and a LAN interface (the one that connect= s > to > tethered hosts/networks). If N is a node on a LAN, then it's 'WAN' interface is simply its Ethernet or Wireless link and the it's 'provider' could be the subnet router. It's 'LAN' interfaces will be some virtual interfaces belonging to VMs for example. > 'N' sends a DHCPv6 PD Solicit over the WAN interface > and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to > either the > loopback interface or the LAN interface, but MUST NOT assign 'P' to the W= AN > interface. This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means. The host would then be requesting a PD only for other interfaces apart from the WAN interface. > Now let's look at three cases: > > 1) 'N' assigns 'P' to the LAN interface and configures an address 'A' fro= m > 'P' that > it also assigns to the LAN interface. 'N' MUST do DAD on the LAN > interface for > address 'A', but does not do DAD on the WAN interface because 'P' is n= ot > assigned to that interface. > Isn't DAD done on addresses rather than prefixes? DAD will be done on A because it is a full address (128 bits) that will be binded to the LAN interface. The language of 'assigning' a prefix to an interface is a bit confusing. The current mechanisms for doing this today (creating a ND PIO for prefix P or having P as some DHCPv6 scope) should not trigger DAD. > > 2) 'N' assigns 'A' and 'P' to the loopback interface. 'N' does not do DAD > on either the LAN or the WAN interface. > Correct, DAD is triggered per address per interface of N. Only one address is being given to an interface (the loopback) and DAD will be done for that. Again the use of 'assign' as applied to a prefix here is confusing . One doesn't 'assign' a prefix to an interface and especially not loopback interface AFAIK. There's no reason to do DAD on LAN/WAN interfaces because no address is being assigned to them. > > 3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN > interface. > Again, 'N' does not do DAD on the WAN interface because (again) 'P' i= s > not > assigned to that interface. > I don't think this is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses). If my understanding of your use of 'assigning' P is correct, then it could take the form of P being sent in a PIO of a RA with A =3D 1. That act has no bearing on whether DAD is perform= ed until a host takes P, generates an IID and tries to assign it to an interface. > > Now, stepping back, outside observers (e.g., neighbors on the WAN link) > are completely oblivious to the way 'N' provisions 'P' and 'A' internally= . Correct. > All an > outside observer can tell is that 'N' emanates packets with source addres= s > 'A', and that 'P' is not on link. Therefore, there is no DAD required on > the > WAN interface. > If N is a host on a LAN (which requests a PD for VMS), then its WAN interface is actually a LAN interface. Assuming it already provisioned an address for that WAN interface, it doesn't need to provision A from the delegated prefix. However I don't see any reason why it cannot provision an address A from a sub-prefix (P') where P' is a sub prefix of P (e.g. it gets a /60 P via PD, provisions a /64 P' and assigns address A out of P'). DAD must be done for that address A. > > Thanks - Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred = L > > Sent: Tuesday, November 03, 2015 2:37 PM > > To: Brian E Carpenter; Lorenzo Colitti > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] DAD again [was: > draft-ietf-v6ops-host-addr-availability discussion] > > > > Hi Brian, > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > Sent: Tuesday, November 03, 2015 1:47 PM > > > To: Templin, Fred L; Lorenzo Colitti > > > Cc: v6ops@ietf.org > > > Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability > discussion] > > > > > > Hello Fred, > > > > > > On 03/11/2015 20:10, Templin, Fred L wrote: > > > > Hi Brian, > > > > > > > >> -----Original Message----- > > > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > >> Sent: Monday, November 02, 2015 6:55 PM > > > >> To: Templin, Fred L; Lorenzo Colitti > > > >> Cc: v6ops@ietf.org > > > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability > discussion > > > >> > > > >> Hi Fred, > > > >> On 03/11/2015 14:59, Templin, Fred L wrote: > > > >>> Hi Brian, > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > >>>> Sent: Monday, November 02, 2015 5:46 PM > > > >>>> To: Templin, Fred L; Lorenzo Colitti > > > >>>> Cc: v6ops@ietf.org > > > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability > discussion > > > >>>> > > > >>>> On 03/11/2015 14:31, Templin, Fred L wrote: > > > >>>>> Bumping up one level =E2=80=93 is it clear to everyone that it = is OK to > assign addresses > > > >>>>> taken from a DHCPv6 delegated prefix to the interface over whic= h > the prefix > > > >>>>> was received? > > > >>>> > > > >>>> If it was legitimately received, I can't see why it wouldn't be > OK. > > > >>> > > > >>> OK. When the DHCPv6 server grants a prefix delegation to the > client, > > > >>> the server is asserting that that prefix is unique and is now the > sole > > > >>> property of the client. So, when you say legitimately received I > > > >>> agree and that is actually a core requirement of DHCPv6 PD. > > > >>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the > > > >>> routing system would become hopelessly corrupted and address > > > >>> duplication would be the least of our worries. > > > >>> > > > >>>>> And, that DAD is not required for those addresses? > > > >>>> > > > >>>> How is that safe? What is to stop a host running SLAAC once it > > > >>>> sees that prefix in an RA, and hitting the same IID by chance? > > > >>>> At least you need to specify that the A bit must not be set. > > > >>> > > > >>> I am talking about DAD on interface "A" being the interface over > > > >>> which the client receives the prefix delegation. No other node on > > > >>> interface "A" may use the delegated prefix, and no router on > > > >>> interface "A" may advertise the prefix in an RA. The prefix is th= e > > > >>> sole property of the client that received the PD, so the client i= s > > > >>> free to assign addresses without needing DAD. > > > >> > > > >> That usage of "may" might confuse some people, so let's pretend > > > >> you used a "MUST NOT" construct instead. I could still construct > > > >> a host stack that would ignore the issue: its logic would be > > > >> "I sent an RS and got no RA/PIO with A=3D1; but I see traffic from > > > >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that > prefix." > > > > > > > > The malicious (or otherwise broken) host 'A' could configure any > number > > > > of addresses it likes, but it would do so in a vacuum because ingre= ss > > > > filtering will prevent a packet with a source address from a prefix > > > > belonging to host B from being accepted. So, node B has no reason > > > > to fear address duplication by node A. > > > > > > I'm not sure how an ingress filter somewhere upstream would know that > > > the packet came from the "wrong" host. But I don't think that's enoug= h; > > > a duplicate address on the LAN is already a problem in itself. > > > > > > > Also, what if node B in fact did do DAD and A heard it? What is to > stop > > > > A from configuring a duplicate address and trying to use it just to > mess > > > > up the legitimate operation of node B? > > > > > > Nothing. That, I think, is why the RFCs make DAD mandatory. > > > > > > > > > > > What you are describing is a broken implementation that could only > > > > be employed by a malicious host, and not something that honors > > > > the standards. > > > > > > I don't think it's malicious; it's just trying to get IPv6 connectivi= ty > > > in the face of what it sees as a broken router that isn't responding > > > to RS. But that isn't really my point - my point is that whatever we > > > do, it's impossible to assert that a duplicate address will never > arise. > > > > > > > Doing DAD is not going to guard against malicious > > > > hosts. > > > > > > No, but it might allow you to detect the resulting anomaly. > > > > > > Actually, the simpler answer to your question is that the node would > > act as a host internally, but appear to be a router on the link from an > > outside observer's perspective. And, routers do not do DAD for the > > source addresses of packets that pass through them. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Brian > > > > > > > > > > > Thanks - Fred > > > > fred.l.templin@beoing.com > > > > > > > >>>> Come to that, a manual address might collide. > > > >>> > > > >>> The client itself is the only node that is permitted to assign > addresses > > > >>> from the delegated prefix to an interface, so there is no risk of > > > >>> collision unless the client itself is somehow corrupt. > > > >> > > > >> Or another client on the same LAN gets too clever. > > > >> > > > >> Brian > > > >> > > > >>> > > > >>> Thanks - Fred > > > >>> fred.l.templin@boeing.com > > > >>> > > > >>>> Brian > > > >>>> > > > >>>>> > > > >>>>> Thanks - Fred > > > >>>>> > > > >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > > > >>>>> Sent: Monday, November 02, 2015 5:24 PM > > > >>>>> To: Lorenzo Colitti > > > >>>>> Cc: v6ops@ietf.org > > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability > discussion > > > >>>>> > > > >>>>> Hi Lorenzo, > > > >>>>> > > > >>>>> Responses below in =E2=80=9Cgreen=E2=80=9D: > > > >>>>> > > > >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com] > > > >>>>> Sent: Monday, November 02, 2015 5:04 PM > > > >>>>> To: Templin, Fred L > > > >>>>> Cc: Fred Baker (fred); v6ops@ietf.org > > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability > discussion > > > >>>>> > > > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > > >>>>> I have one text addition suggestion and one question. On P. 7, > in Table 1, > > > >>>>> suggest adding a new final row as follows: > > > >>>>> > > > >>>>> requires DAD Yes Yes > No N/A > > > >>>>> > > > >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 > IA_NA/IA_TA > > > >>>>> must use DAD to check for duplicates on the link they were > obtained. In a > > > >>>>> multi-addressing environment where millions of addresses are > required, > > > >>>>> this could amount to a substantial amount of DAD multicast > traffic. On the > > > >>>>> other hand, DAD is not needed for DHCPv6 PD because the network > has > > > >>>>> unambiguously delegated the prefix for the node's exclusive use= . > > > >>>>> > > > >>>>> I don't think "Requires DAD: No" is correct. Even if the device > gets a /64 prefix entirely for its own use, it still needs to do DAD > > > with > > > >>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.= ). > > > >>>>> > > > >>>>> I'm not opposed to adding a line to the table, though I don't > think it provides much value - if we put our mind to it, I'm sure > > we > > > >> could > > > >>>> come up with lots of things we could add to the table that aren'= t > there at the moment. My main concern is that if we add > > > >> something to > > > >>>> the table it needs to be correct. > > > >>>>> > > > >>>>> What I mean is =E2=80=9CRequires DAD on the interface over whic= h the > prefix was received=E2=80=9D, > > > >>>>> but that was too long to fit in the table. Let=E2=80=99s call t= he > interface =E2=80=9CA=E2=80=9D. If the node gets > > > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface > =E2=80=9CA=E2=80=9D, then it needs > > > >>>>> to do DAD on interface =E2=80=9CA=E2=80=9D for each such addres= s. If the node > gets a DHCPv6 PD > > > >>>>> over interface =E2=80=9CA=E2=80=9D, however, it does not need t= o do DAD over > interface =E2=80=9CA=E2=80=9D at all. > > > >>>>> > > > >>>>> If the node assigns the delegated prefix to interface =E2=80=9C= B=E2=80=9D, then > you are right that > > > >>>>> that DAD will be required among all tethered devices, VMs, etc. > on interface =E2=80=9CB=E2=80=9D. > > > >>>>> But, there will still be no need for DAD on interface =E2=80=9C= A=E2=80=9D. Does > that clarify? > > > >>>>> > > > >>>>> I have a question also on table 1. Under ""Unlimited" > endpoints", why does > > > >>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, > since a prefix > > > >>>>> obtained by DHCPv6 PD can be used to configure an unlimited > number of > > > >>>>> addresses on the link over which the prefix was received. > > > >>>>> > > > >>>>> The table is written from the perspective of the network > assigning addresses to devices that connect to it. Therefore, it says > > > "no" > > > >>>> because if you use DHCPv6 PD you can't assign address space to a= n > unlimited number of endpoints - you are limited to > > however > > > >> many > > > >>>> /64s you have available. > > > >>>>> > > > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, a= t > least in theory, an "unlimited" number of addresses to > > assign > > > to > > > >>>> clients. Of course, that's only true in theory. In practice, > there's going to be a limit due to scaling reasons. > > > >>>>> > > > >>>>> I don=E2=80=99t understand this. True that SLAAC and DHCPv6 IA_= NA/IA_TA > can be used > > > >>>>> to assign an unlimited number of addresses to interface =E2=80= =9CA=E2=80=9D. > But, so can DHCPv6 > > > >>>>> PD. When the node receives the delegated prefix (e.g., a /64), > it can assign as > > > >>>>> many unique IPv6 addresses as it likes to interface =E2=80=9CA= =E2=80=9D. And > again, it need not > > > >>>>> do DAD for any of them. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> v6ops mailing list > > > >>>>> v6ops@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/v6ops > > > >>>>> > > > >>> > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --089e0158b49ea7317b0524017db3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 November 2015 at 03:30, Templin, Fred L <Fred.L.Templin@b= oeing.com> wrote:
Hi - let= 's lay this out fully so we can clearly understand the DAD implications= .

Let's say a node 'N' has a WAN interface (the one that connects= to the provider
network), a loopback interface, and a LAN interface (the one that connects = to
tethered hosts/networks).


If= N is a node on a LAN, then it's 'WAN' interface is simply its = Ethernet or Wireless link and the it's 'provider' could be the = subnet router. It's 'LAN' interfaces will be some virtual inter= faces belonging to VMs for example.

=C2=A0
'N' sends a DHCPv6 PD Solicit over th= e WAN interface
and receives a prefix delegation 'P'. 'N' can now assign pr= efix 'P' to either the
loopback interface or the LAN interface, but MUST NOT assign 'P' to= the WAN
interface.


This is correct, = since this WAN interface would have already gotten legitimate non-link-loca= l addresses by other means. The host would then be requesting a PD only for= other interfaces apart from the WAN interface.=C2=A0

<= div>
=C2=A0
Now let'= s look at three cases:

1) 'N' assigns 'P' to the LAN interface and configures an a= ddress 'A' from 'P' that
=C2=A0 =C2=A0it also assigns to the LAN interface. 'N' MUST do DAD = on the LAN interface for
=C2=A0 =C2=A0address 'A', but does not do DAD on the WAN interface = because 'P' is not
=C2=A0 =C2=A0assigned to that interface.


Isn't DAD done on addresses rather than prefixes? DAD = will be done on A because it is a full address (128 bits) that will be bind= ed to the LAN interface.=C2=A0

The language of = 9;assigning' a prefix to an interface is a bit confusing. The current m= echanisms for doing this today (creating a ND PIO for prefix P or having P = as some DHCPv6 scope) should not trigger DAD.=C2=A0

=C2=A0

2) 'N' assigns 'A' and 'P' to the loopback interfac= e. 'N' does not do DAD
=C2=A0 =C2=A0 on either the LAN or the WAN interface.
=

Correct, DAD is triggered per address per int= erface of N. Only one address is being given to an interface (the loopback)= and DAD will be done for that. Again the use of 'assign' as applie= d to a prefix here is confusing . One doesn't 'assign' a prefix= to an interface and especially not loopback interface AFAIK. There's n= o reason to do DAD on LAN/WAN interfaces because no address is being assign= ed to them.

=C2=A0

3) 'N' assigns 'P' to the loopback interface and assigns &#= 39;A' to the WAN interface.
=C2=A0 =C2=A0 Again, 'N' does not do DAD on the WAN interface becau= se (again) 'P' is not
=C2=A0 =C2=A0 assigned to that interface.


I don't think this =C2=A0is correct. DAD will be done= for the WAN interface for address A irrespective of whether P is 'assi= gned' to it (just as DAD is performed for Link Local Addresses). If my = understanding of your use of 'assigning' P is correct, then it coul= d take the form of P being sent in a PIO of a RA with A =3D 1. That act has= no bearing on whether DAD is performed until a host takes P, generates an = IID and tries to assign it to an interface.
=C2=A0

Now, stepping back, outside observers (e.g., neighbors on the WAN link)
are completely oblivious to the way 'N' provisions 'P' and = 'A' internally.

Correct.
= =C2=A0
All an
outside observer can tell is that 'N' emanates packets with source = address
'A', and that 'P' is not on link. Therefore, there is no DA= D required on the
WAN interface.


If N is a= host on a LAN (which requests a PD for VMS), then its WAN interface is act= ually a LAN interface. Assuming it already provisioned an address for that = WAN interface, it doesn't need to provision A from the delegated prefix= . However I don't see any reason why it cannot provision an address A f= rom a sub-prefix (P') where P' is a sub prefix of P (e.g. it gets a= /60 P via PD, provisions a /64 P' and assigns address A out of P')= . DAD must be done for that address A.=C2=A0


<= /div>
=C2=A0

Thanks - Fred
fred.l.templin@boeing.com<= br>
> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Tuesday, November 03, 2015 2:37= PM
> To: Brian E Carpenter; Lorenzo Colitti
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] DA= D again [was: draft-ietf-v6ops-host-addr-availability discussion]
>
> Hi Brian,
>
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > Sent: Tuesday, November 03, 2015 1:47 PM
> > To: Templin, Fred L; Lorenzo Colitti
> > Cc: v6ops@ietf.org
> > Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability = discussion]
> >
> > Hello Fred,
> >
> > On 03/11/2015 20:10, Templin, Fred L wrote:
> > > Hi Brian,
> > >
> > >> -----Original Message-----
> > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > >> Sent: Monday, November 02, 2015 6:55 PM
> > >> To: Templin, Fred L; Lorenzo Colitti
> > >> Cc: v6ops@ietf.org=
> > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availabi= lity discussion
> > >>
> > >> Hi Fred,
> > >> On 03/11/2015 14:59, Templin, Fred L wrote:
> > >>> Hi Brian,
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > >>>> Sent: Monday, November 02, 2015 5:46 PM
> > >>>> To: Templin, Fred L; Lorenzo Colitti
> > >>>> Cc: v6ops@ietf= .org
> > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-= availability discussion
> > >>>>
> > >>>> On 03/11/2015 14:31, Templin, Fred L wrote:
> > >>>>> Bumping up one level =E2=80=93 is it clear t= o everyone that it is OK to assign addresses
> > >>>>> taken from a DHCPv6 delegated prefix to the = interface over which the prefix
> > >>>>> was received?
> > >>>>
> > >>>> If it was legitimately received, I can't see= why it wouldn't be OK.
> > >>>
> > >>> OK. When the DHCPv6 server grants a prefix delegatio= n to the client,
> > >>> the server is asserting that that prefix is unique a= nd is now the sole
> > >>> property of the client. So, when you say legitimatel= y received I
> > >>> agree and that is actually a core requirement of DHC= Pv6 PD.
> > >>> Otherwise, if the DHCPv6 server gave out duplicate p= refixes, the
> > >>> routing system would become hopelessly corrupted and= address
> > >>> duplication would be the least of our worries.
> > >>>
> > >>>>> And, that DAD is not required for those addr= esses?
> > >>>>
> > >>>> How is that safe? What is to stop a host running= SLAAC once it
> > >>>> sees that prefix in an RA, and hitting the same = IID by chance?
> > >>>> At least you need to specify that the A bit must= not be set.
> > >>>
> > >>> I am talking about DAD on interface "A" be= ing the interface over
> > >>> which the client receives the prefix delegation. No = other node on
> > >>> interface "A" may use the delegated prefix= , and no router on
> > >>> interface "A" may advertise the prefix in = an RA. The prefix is the
> > >>> sole property of the client that received the PD, so= the client is
> > >>> free to assign addresses without needing DAD.
> > >>
> > >> That usage of "may" might confuse some people,= so let's pretend
> > >> you used a "MUST NOT" construct instead. I cou= ld still construct
> > >> a host stack that would ignore the issue: its logic woul= d be
> > >> "I sent an RS and got no RA/PIO with A=3D1; but I s= ee traffic from
> > >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD= in that prefix."
> > >
> > > The malicious (or otherwise broken) host 'A' could c= onfigure any number
> > > of addresses it likes, but it would do so in a vacuum becaus= e ingress
> > > filtering will prevent a packet with a source address from a= prefix
> > > belonging to host B from being accepted. So, node B has no r= eason
> > > to fear address duplication by node A.
> >
> > I'm not sure how an ingress filter somewhere upstream would k= now that
> > the packet came from the "wrong" host. But I don't = think that's enough;
> > a duplicate address on the LAN is already a problem in itself. > >
> > > Also, what if node B in fact did do DAD and A heard it? What= is to stop
> > > A from configuring a duplicate address and trying to use it = just to mess
> > > up the legitimate operation of node B?
> >
> > Nothing. That, I think, is why the RFCs make DAD mandatory.
> >
> > >
> > > What you are describing is a broken implementation that coul= d only
> > > be employed by a malicious host, and not something that hono= rs
> > > the standards.
> >
> > I don't think it's malicious; it's just trying to get= IPv6 connectivity
> > in the face of what it sees as a broken router that isn't res= ponding
> > to RS. But that isn't really my point - my point is that what= ever we
> > do, it's impossible to assert that a duplicate address will n= ever arise.
> >
> > > Doing DAD is not going to guard against malicious
> > > hosts.
> >
> > No, but it might allow you to detect the resulting anomaly.
>
>
> Actually, the simpler answer to your question is that the node would > act as a host internally, but appear to be a router on the link from a= n
> outside observer's perspective. And, routers do not do DAD for the=
> source addresses of packets that pass through them.
>
> Thanks - Fred
> fred.l.templin@boeing.com=
>
> >=C2=A0 =C2=A0 Brian
> >
> > >
> > > Thanks - Fred
> > > fred.l.templin@= beoing.com
> > >
> > >>>> Come to that, a manual address might collide. > > >>>
> > >>> The client itself is the only node that is permitted= to assign addresses
> > >>> from the delegated prefix to an interface, so there = is no risk of
> > >>> collision unless the client itself is somehow corrup= t.
> > >>
> > >> Or another client on the same LAN gets too clever.
> > >>
> > >>=C2=A0 =C2=A0 Brian
> > >>
> > >>>
> > >>> Thanks - Fred
> > >>> fred.l.= templin@boeing.com
> > >>>
> > >>>>=C2=A0 =C2=A0 =C2=A0Brian
> > >>>>
> > >>>>>
> > >>>>> Thanks - Fred
> > >>>>>
> > >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L<= br> > > >>>>> Sent: Monday, November 02, 2015 5:24 PM
> > >>>>> To: Lorenzo Colitti
> > >>>>> Cc: v6ops@= ietf.org
> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-a= ddr-availability discussion
> > >>>>>
> > >>>>> Hi Lorenzo,
> > >>>>>
> > >>>>> Responses below in =E2=80=9Cgreen=E2=80=9D:<= br> > > >>>>>
> > >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com]
> > >>>>> Sent: Monday, November 02, 2015 5:04 PM
> > >>>>> To: Templin, Fred L
> > >>>>> Cc: Fred Baker (fred); v6ops@ietf.org<mailto:v6ops@ietf.org>
> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-a= ddr-availability discussion
> > >>>>>
> > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fre= d L <Fred.L.Templin@boeing.= com<mailto:Fred.L.Templ= in@boeing.com>> wrote:
> > >>>>> I have one text addition suggestion and one = question. On P. 7, in Table 1,
> > >>>>> suggest adding a new final row as follows: > > >>>>>
> > >>>>>=C2=A0 =C2=A0requires DAD=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0N/A
> > >>>>>
> > >>>>> Meaning that multi-addresses configured by S= LAAC or DHCPv6 IA_NA/IA_TA
> > >>>>> must use DAD to check for duplicates on the = link they were obtained. In a
> > >>>>> multi-addressing environment where millions = of addresses are required,
> > >>>>> this could amount to a substantial amount of= DAD multicast traffic. On the
> > >>>>> other hand, DAD is not needed for DHCPv6 PD = because the network has
> > >>>>> unambiguously delegated the prefix for the n= ode's exclusive use.
> > >>>>>
> > >>>>> I don't think "Requires DAD: No&quo= t; is correct. Even if the device gets a /64 prefix entirely for its own us= e, it still needs to do DAD
> > with
> > >>>> any other devices on that /64 (e.g., tethered de= vices, VMs, etc.).
> > >>>>>
> > >>>>> I'm not opposed to adding a line to the = table, though I don't think it provides much value - if we put our mind= to it, I'm sure
> we
> > >> could
> > >>>> come up with lots of things we could add to the = table that aren't there at the moment. My main concern is that if we ad= d
> > >> something to
> > >>>> the table it needs to be correct.
> > >>>>>
> > >>>>> What I mean is =E2=80=9CRequires DAD on the = interface over which the prefix was received=E2=80=9D,
> > >>>>> but that was too long to fit in the table. L= et=E2=80=99s call the interface =E2=80=9CA=E2=80=9D. If the node gets
> > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresse= s over interface =E2=80=9CA=E2=80=9D, then it needs
> > >>>>> to do DAD on interface =E2=80=9CA=E2=80=9D f= or each such address. If the node gets a DHCPv6 PD
> > >>>>> over interface =E2=80=9CA=E2=80=9D, however,= it does not need to do DAD over interface =E2=80=9CA=E2=80=9D at all.
> > >>>>>
> > >>>>> If the node assigns the delegated prefix to = interface =E2=80=9CB=E2=80=9D, then you are right that
> > >>>>> that DAD will be required among all tethered= devices, VMs, etc. on interface =E2=80=9CB=E2=80=9D.
> > >>>>> But, there will still be no need for DAD on = interface =E2=80=9CA=E2=80=9D. Does that clarify?
> > >>>>>
> > >>>>> I have a question also on table 1. Under &qu= ot;"Unlimited" endpoints", why does
> > >>>>> it say "no" for DHCPv6 PD? I think= it should say "yes" instead, since a prefix
> > >>>>> obtained by DHCPv6 PD can be used to configu= re an unlimited number of
> > >>>>> addresses on the link over which the prefix = was received.
> > >>>>>
> > >>>>> The table is written from the perspective of= the network assigning addresses to devices that connect to it. Therefore, = it says
> > "no"
> > >>>> because if you use DHCPv6 PD you can't assig= n address space to an unlimited number of endpoints - you are limited to > however
> > >> many
> > >>>> /64s you have available.
> > >>>>>
> > >>>>> If you use IA_NA or SLAAC, any network with = a /64 subnet has, at least in theory, an "unlimited" number of ad= dresses to
> assign
> > to
> > >>>> clients. Of course, that's only true in theo= ry. In practice, there's going to be a limit due to scaling reasons. > > >>>>>
> > >>>>> I don=E2=80=99t understand this. True that S= LAAC and DHCPv6 IA_NA/IA_TA can be used
> > >>>>> to assign an unlimited number of addresses t= o interface =E2=80=9CA=E2=80=9D. But, so can DHCPv6
> > >>>>> PD. When the node receives the delegated pre= fix (e.g., a /64), it can assign as
> > >>>>> many unique IPv6 addresses as it likes to in= terface =E2=80=9CA=E2=80=9D. And again, it need not
> > >>>>> do DAD for any of them.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> ____________________________________________= ___
> > >>>>> v6ops mailing list
> > >>>>> v6ops@ietf= .org
> > >>>>> https://www.ietf.org/mailm= an/listinfo/v6ops
> > >>>>>
> > >>>
> > >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--
=

Mukom Akong T.
=
LinkedIn:Mukom=C2=A0=C2=A0| =C2=A0twitter: @per= fexcellent =C2=A0
    -------------------------= ---------------------------------------------------------------------------= --------------------------------------
    =E2=80=9CWhen you work, you are t= he FLUTE through whose lungs the whispering of the hours turns to MUSIC&quo= t; - Kahlil Gibran
    -----------------------------------------------------= ---------------------------------------------------------------------------= -----------
    --089e0158b49ea7317b0524017db3-- From nobody Sat Nov 7 22:33: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 AC8061A702E for ; Sat, 7 Nov 2015 22:33:46 -0800 (PST) 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 X-HZBzr-iEkS for ; Sat, 7 Nov 2015 22:33:44 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278D81A702D for ; Sat, 7 Nov 2015 22:33:44 -0800 (PST) Received: by wmec201 with SMTP id c201so46074635wme.1 for ; Sat, 07 Nov 2015 22:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=Rp1wwR92PITJb/NFLG5vzVb9k/xg5OFqhnvbCA/JQHQ=; b=tA5odOEerTxH1Ws7rx/AWQ6xYeWfBzblVOBY7D5ueF8JRCiVepMeSO0SBMgkM7+hBi 9xHHoH8YMnQM13c4GynLZ9ou+nnuLD9katE1U7FgEq7s8WcptDkob5AJaAUmFiZkU2md ssNsZ4LjQoDsFI9lDWuw/LGgHcZGMZeaBYABEvF/5vXOV5wz7psn2FPBJfFILcPSBBBG mBo3wB75/7hfJcnO13f/UHnpbh+fOd0jsMa0KtvyKFwwjroSnodFqx3k4MOxi1mWwogn WBwUQ8AEw8FMDMGuO+QBKsZXVuwOkKAELLhw7riCaVClG1g88Xk6XFqdGRlQ45gm3f1g m5BA== X-Received: by 10.28.137.211 with SMTP id l202mr17750665wmd.18.1446964422672; Sat, 07 Nov 2015 22:33:42 -0800 (PST) Received: from Ivans-MacBook-Pro.local ([88.128.82.57]) by smtp.gmail.com with ESMTPSA id l1sm7394915wmg.21.2015.11.07.22.33.40 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Nov 2015 22:33:41 -0800 (PST) Date: Sun, 8 Nov 2015 07:33:41 +0100 From: Ivan Pepelnjak To: Lorenzo Colitti , Nick Hilliard Message-ID: In-Reply-To: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> X-Mailer: Airmail (335) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="563eecc5_6b4cdbd0_e02a" Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 08 Nov 2015 06:33:46 -0000 --563eecc5_6b4cdbd0_e02a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just because I was driving without a seat belt for years doesn=E2=80=99t = mean that it=E2=80=99s safe to do so. Just because you COULD doesn=E2=80=99= t mean that you SHOULD. When will we finally grow up (as a community) and get to a point where ev= eryone would consider sending network layer addresses in application mess= ages a bad practice regardless of whether it works or not=3F Ivan Pepelnjak www.ipSpace.net=C2=A0/=C2=A0blog.ipSpace.net On 8 Nov 2015 at 06:26:10, Lorenzo Colitti (lorenzo=40google.com) wrote: On =46ri, Nov 6, 2015 at 7:08 PM, Nick Hilliard wrote= : On 06/11/2015 00:20, Lorenzo Colitti wrote: It breaks any application that requires that the application know its sou= rce address. Examples are SIP, =46TP, audio/video chat, etc. your argument is the wrong way around: some protocols deliberately introd= uce layering violations by demanding that transport identifier informatio= n is encoded at the application layer.=C2=A0 Transport identifier transla= tion merely shows up this brokenness.=C2=A0 The brokenness is not with th= e translation mechanism but with the higher level protocols. Nope. Those protocols aren't broken, they worked fine for years until NAT= arrived and broke them.=C2=A0They still work fine on networks that opera= te the way the Internet was originally designed with end-to-end connectiv= ity. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 v6ops mailing list =20 v6ops=40ietf.org =20 https://www.ietf.org/mailman/listinfo/v6ops =20 --563eecc5_6b4cdbd0_e02a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

    Hello Mukom,

     

    See below for my responses.

     

    Fred

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

     

    From: Mukom Akong T. [mailto:mukom.t= amon@gmail.com]
    Sent: Saturday, November 07, 2015 10:21 PM
    To: Templin, Fred L
    Cc: Brian E Carpenter; Lorenzo Colitti; v6ops@ietf.org
    Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-avai= lability discussion]

     

     

     

    On 4 November 2015 at 03:30, Templin, Fred L <Fred.L.Templin@= boeing.com> wrote:

    Hi - let's lay this out fully so we can clearly unde= rstand the DAD implications.

    Let's say a node 'N' has a WAN interface (the one that connects to the prov= ider
    network), a loopback interface, and a LAN interface (the one that connects = to
    tethered hosts/networks).

     

     

    If N is a node on a LAN, then it's 'WAN' interface i= s simply its Ethernet or Wireless link and the it's 'provider' could be the= subnet router. It's 'LAN' interfaces will be some virtual interfaces belon= ging to VMs for example.

     

    FLT >>> Let’s use as example an ente= rprise mobile device such as a tablet. The

    FLT>>> tablet has a WiFi interface, and le= t’s say it has some virtual interfaces

    FLT>>> belonging to VMs using the example = you provided. In that case, what

    FLT>>> I am calling “WAN” is a= ctually the “WiFI” interface, and what I am

    FLT>>> calling “LAN” is the in= ternal virtual interfaces, yes.

     

    'N' sends a DHCPv6 PD Solicit over the WAN interface=
    and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to eith= er the
    loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN=
    interface.

     

     

    This is correct, since this WAN interface would have= already gotten legitimate non-link-local addresses by other means.

     

    FLT>>> Not necessarily; the WAN interface = could be on a link that provides

    FLT>>> link-local-only addressing, for exa= mple.

     

    The host would then be requesting a PD only for othe= r interfaces apart from the WAN interface. 

     

    FLT>>> Correct.

     

    Now let's look at three cases:

    1) 'N' assigns 'P' to the LAN interface and configures an address 'A' from = 'P' that
       it also assigns to the LAN interface. 'N' MUST do DAD on the L= AN interface for
       address 'A', but does not do DAD on the WAN interface because = 'P' is not
       assigned to that interface.

     

     

    Isn't DAD done on addresses rather than prefixes? DA= D will be done on A because it is a full address (128 bits) that will be bi= nded to the LAN interface. 

     

    FLT>>> Yes, DAD is done when an address &#= 8216;A’ is assigned to an interface over which

    FLT>>> DAD is required – for every s= uch address ‘A’.

     

    The language of 'assigning' a prefix to an interface= is a bit confusing. The current mechanisms for doing this today (creating = a ND PIO for prefix P or having P as some DHCPv6 scope) should not trigger = DAD.

     

    FLT>>> Assigning a prefix to an interface = does not invoke DAD; only assigning

    FLT>>> addresses to an interface over whic= h DAD is required invokes DAD.

     


    2) 'N' assigns 'A' and 'P' to the loopback interface. 'N' does not do DAD     on either the LAN or the WAN interface.

     

     

    Correct, DAD is triggered per address per interface = of N. Only one address is being given to an interface (the loopback) and DA= D will be done for that.

     

    FLT>>> No, loopback is an example of an in= terface where DAD is not required.

     

    Again the use of 'assign' as applied to a prefix her= e is confusing . One doesn't 'assign' a prefix to an interface and especial= ly not loopback interface AFAIK.

     

    FLT>>> The correct language per RFC4861 is= to “[add the prefix] to the Prefix List” of the

    FLT>>> interface to which the prefix is be= ing applied. So, yes, my terminology was loose

    FLT>>> but “add the prefix to the Pr= efix List” is what I intended.

     

    There's no reason to do DAD on LAN/WAN interfaces be= cause no address is being assigned to them.

     

    FLT>>> Right.


    3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN int= erface.
        Again, 'N' does not do DAD on the WAN interface because (agai= n) 'P' is not
        assigned to that interface.

     

     

    I don't think this  is correct. DAD will be don= e for the WAN interface for address A irrespective of whether P is 'assigne= d' to it (just as DAD is performed for Link Local Addresses).

     

    FLT>>> RFC4862 says:

    FLT>>>    -  An interf= ace whose DupAddrDetectTransmits variable is set to zero<= /p>

    FLT>>>       = ;does not perform Duplicate Address Detection.

    FLT>>> This shows that the node has latitu= de in when it can deem DAD as unnecessary

    FLT>>> for a given interface. In this case= , the address A is not matched by a prefix in the

    FLT>>> Prefix List for the WAN interface a= nd it is known that the prefix will never

    FLT>>> never be added to the Prefix List f= or the WAN interface by node N nor any

    FLT>>> node on the WAN link.

     

    If my understanding of your use of 'assigning' P is = correct, then it could take the form of P being sent in a PIO of a RA with = A =3D 1. That act has no bearing on whether DAD is performed until a host t= akes P, generates an IID and tries to assign it to an interface.

     

    FLT>>> The P that I am talking about is on= e which has been delegated to node N

    FLT>>> for that node’s exclusive use= , and MUST NOT be considered on-link on

    FLT>>> the WAN interface. Details of the d= elegation (whether it be DHCPv6 PD,

    FLT>>> manual configuration, or something = else) are irrelevant.

     
    Now, stepping back, outside observers (e.g., neighbors on the WAN link)
    are completely oblivious to the way 'N' provisions 'P' and 'A' internally.<= o:p>

     

    Correct.

     

    All an
    outside observer can tell is that 'N' emanates packets with source address<= br> 'A', and that 'P' is not on link. Therefore, there is no DAD required on th= e
    WAN interface.

     

     

    If N is a host on a LAN (which requests a PD for VMS= ), then its WAN interface is actually a LAN interface. Assuming it already = provisioned an address for that WAN interface, it doesn't need to provision= A from the delegated prefix. However I don't see any reason why it cannot provision an address A from a sub-pre= fix (P') where P' is a sub prefix of P (e.g. it gets a /60 P via PD, provis= ions a /64 P' and assigns address A out of P').

     

    FLT>>> Yes, there is ambiguity in the term= s “WAN” and “LAN”. What is intended in

    FLT>>> this discussion however is that = 220;WAN” means the upstream interface attached

    FLT>>> to the provider network and “= LAN” means the downstream-attached virtual or

    FLT>>> physical interfaces of node N.=

     

    DAD must be done for that address A.

     

    FLT>>> No; not at all. A is derived from a= prefix P hat is delegated for N’s exclusive

    FLT>>> use and is guaranteed to not be on-= link on the WAN interface. DAD is

    FLT>>> therefore not required on the WAN i= nterface

     

     


    Thanks - Fred
    fred.l.templin@boeing.com<= br>
    > -----Original Message-----
    > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L<= br> > Sent: Tuesday, November 03, 2015 2:37 PM
    > To: Brian E Carpenter; Lorenzo Colitti
    > Cc: v6ops@ietf.or= g

    > Subject: Re: [v6ops] DAD again [was: draft-ietf= -v6ops-host-addr-availability discussion]
    >
    > Hi Brian,
    >
    > > -----Original Message-----
    > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
    > > Sent: Tuesday, November 03, 2015 1:47 PM
    > > To: Templin, Fred L; Lorenzo Colitti
    > > Cc: v6ops@ietf.org
    > > Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability = discussion]
    > >
    > > Hello Fred,
    > >
    > > On 03/11/2015 20:10, Templin, Fred L wrote:
    > > > Hi Brian,
    > > >
    > > >> -----Original Message-----
    > > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
    > > >> Sent: Monday, November 02, 2015 6:55 PM
    > > >> To: Templin, Fred L; Lorenzo Colitti
    > > >> Cc: v6ops@ietf.org=
    > > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availabi= lity discussion
    > > >>
    > > >> Hi Fred,
    > > >> On 03/11/2015 14:59, Templin, Fred L wrote:
    > > >>> Hi Brian,
    > > >>>
    > > >>>> -----Original Message-----
    > > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
    > > >>>> Sent: Monday, November 02, 2015 5:46 PM
    > > >>>> To: Templin, Fred L; Lorenzo Colitti
    > > >>>> Cc: v6ops@ietf= .org
    > > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-= availability discussion
    > > >>>>
    > > >>>> On 03/11/2015 14:31, Templin, Fred L wrote:
    > > >>>>> Bumping up one level – is it clear to = everyone that it is OK to assign addresses
    > > >>>>> taken from a DHCPv6 delegated prefix to the = interface over which the prefix
    > > >>>>> was received?
    > > >>>>
    > > >>>> If it was legitimately received, I can't see why= it wouldn't be OK.
    > > >>>
    > > >>> OK. When the DHCPv6 server grants a prefix delegatio= n to the client,
    > > >>> the server is asserting that that prefix is unique a= nd is now the sole
    > > >>> property of the client. So, when you say legitimatel= y received I
    > > >>> agree and that is actually a core requirement of DHC= Pv6 PD.
    > > >>> Otherwise, if the DHCPv6 server gave out duplicate p= refixes, the
    > > >>> routing system would become hopelessly corrupted and= address
    > > >>> duplication would be the least of our worries.
    > > >>>
    > > >>>>> And, that DAD is not required for those addr= esses?
    > > >>>>
    > > >>>> How is that safe? What is to stop a host running= SLAAC once it
    > > >>>> sees that prefix in an RA, and hitting the same = IID by chance?
    > > >>>> At least you need to specify that the A bit must= not be set.
    > > >>>
    > > >>> I am talking about DAD on interface "A" be= ing the interface over
    > > >>> which the client receives the prefix delegation. No = other node on
    > > >>> interface "A" may use the delegated prefix= , and no router on
    > > >>> interface "A" may advertise the prefix in = an RA. The prefix is the
    > > >>> sole property of the client that received the PD, so= the client is
    > > >>> free to assign addresses without needing DAD.
    > > >>
    > > >> That usage of "may" might confuse some people,= so let's pretend
    > > >> you used a "MUST NOT" construct instead. I cou= ld still construct
    > > >> a host stack that would ignore the issue: its logic woul= d be
    > > >> "I sent an RS and got no RA/PIO with A=3D1; but I s= ee traffic from
    > > >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in = that prefix."
    > > >
    > > > The malicious (or otherwise broken) host 'A' could configure= any number
    > > > of addresses it likes, but it would do so in a vacuum becaus= e ingress
    > > > filtering will prevent a packet with a source address from a= prefix
    > > > belonging to host B from being accepted. So, node B has no r= eason
    > > > to fear address duplication by node A.
    > >
    > > I'm not sure how an ingress filter somewhere upstream would know = that
    > > the packet came from the "wrong" host. But I don't thin= k that's enough;
    > > a duplicate address on the LAN is already a problem in itself. > >
    > > > Also, what if node B in fact did do DAD and A heard it? What= is to stop
    > > > A from configuring a duplicate address and trying to use it = just to mess
    > > > up the legitimate operation of node B?
    > >
    > > Nothing. That, I think, is why the RFCs make DAD mandatory.
    > >
    > > >
    > > > What you are describing is a broken implementation that coul= d only
    > > > be employed by a malicious host, and not something that hono= rs
    > > > the standards.
    > >
    > > I don't think it's malicious; it's just trying to get IPv6 connec= tivity
    > > in the face of what it sees as a broken router that isn't respond= ing
    > > to RS. But that isn't really my point - my point is that whatever= we
    > > do, it's impossible to assert that a duplicate address will never= arise.
    > >
    > > > Doing DAD is not going to guard against malicious
    > > > hosts.
    > >
    > > No, but it might allow you to detect the resulting anomaly.
    >
    >
    > Actually, the simpler answer to your question is that the node would > act as a host internally, but appear to be a router on the link from a= n
    > outside observer's perspective. And, routers do not do DAD for the
    > source addresses of packets that pass through them.
    >
    > Thanks - Fred
    > fred.l.templin@boeing.com=
    >
    > >    Brian
    > >
    > > >
    > > > Thanks - Fred
    > > > fred.l.templin@= beoing.com
    > > >
    > > >>>> Come to that, a manual address might collide. > > >>>
    > > >>> The client itself is the only node that is permitted= to assign addresses
    > > >>> from the delegated prefix to an interface, so there = is no risk of
    > > >>> collision unless the client itself is somehow corrup= t.
    > > >>
    > > >> Or another client on the same LAN gets too clever.
    > > >>
    > > >>    Brian
    > > >>
    > > >>>
    > > >>> Thanks - Fred
    > > >>> fred.l.= templin@boeing.com
    > > >>>
    > > >>>>     Brian
    > > >>>>
    > > >>>>>
    > > >>>>> Thanks - Fred
    > > >>>>>
    > > >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L<= br> > > >>>>> Sent: Monday, November 02, 2015 5:24 PM
    > > >>>>> To: Lorenzo Colitti
    > > >>>>> Cc: v6ops@= ietf.org
    > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-a= ddr-availability discussion
    > > >>>>>
    > > >>>>> Hi Lorenzo,
    > > >>>>>
    > > >>>>> Responses below in “green”:
    > > >>>>>
    > > >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com]
    > > >>>>> Sent: Monday, November 02, 2015 5:04 PM
    > > >>>>> To: Templin, Fred L
    > > >>>>> Cc: Fred Baker (fred); v6ops@ietf.org<mailto:v6ops@ietf.org>
    > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-a= ddr-availability discussion
    > > >>>>>
    > > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fre= d L <Fred.L.Templin@boeing.= com<mailto:Fred.L.Templ= in@boeing.com>> wrote:
    > > >>>>> I have one text addition suggestion and one = question. On P. 7, in Table 1,
    > > >>>>> suggest adding a new final row as follows: > > >>>>>
    > > >>>>>   requires DAD     =          Yes          &n= bsp;       Yes            &nbs= p;      No              &= nbsp;  N/A
    > > >>>>>
    > > >>>>> Meaning that multi-addresses configured by S= LAAC or DHCPv6 IA_NA/IA_TA
    > > >>>>> must use DAD to check for duplicates on the = link they were obtained. In a
    > > >>>>> multi-addressing environment where millions = of addresses are required,
    > > >>>>> this could amount to a substantial amount of= DAD multicast traffic. On the
    > > >>>>> other hand, DAD is not needed for DHCPv6 PD = because the network has
    > > >>>>> unambiguously delegated the prefix for the n= ode's exclusive use.
    > > >>>>>
    > > >>>>> I don't think "Requires DAD: No" i= s correct. Even if the device gets a /64 prefix entirely for its own use, i= t still needs to do DAD
    > > with
    > > >>>> any other devices on that /64 (e.g., tethered de= vices, VMs, etc.).
    > > >>>>>
    > > >>>>> I'm not opposed to adding a line to the tabl= e, though I don't think it provides much value - if we put our mind to it, = I'm sure
    > we
    > > >> could
    > > >>>> come up with lots of things we could add to the = table that aren't there at the moment. My main concern is that if we add > > >> something to
    > > >>>> the table it needs to be correct.
    > > >>>>>
    > > >>>>> What I mean is “Requires DAD on the in= terface over which the prefix was received”,
    > > >>>>> but that was too long to fit in the table. L= et’s call the interface “A”. If the node gets
    > > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresse= s over interface “A”, then it needs
    > > >>>>> to do DAD on interface “A” for e= ach such address. If the node gets a DHCPv6 PD
    > > >>>>> over interface “A”, however, it = does not need to do DAD over interface “A” at all.
    > > >>>>>
    > > >>>>> If the node assigns the delegated prefix to = interface “B”, then you are right that
    > > >>>>> that DAD will be required among all tethered= devices, VMs, etc. on interface “B”.
    > > >>>>> But, there will still be no need for DAD on = interface “A”. Does that clarify?
    > > >>>>>
    > > >>>>> I have a question also on table 1. Under &qu= ot;"Unlimited" endpoints", why does
    > > >>>>> it say "no" for DHCPv6 PD? I think= it should say "yes" instead, since a prefix
    > > >>>>> obtained by DHCPv6 PD can be used to configu= re an unlimited number of
    > > >>>>> addresses on the link over which the prefix = was received.
    > > >>>>>
    > > >>>>> The table is written from the perspective of= the network assigning addresses to devices that connect to it. Therefore, = it says
    > > "no"
    > > >>>> because if you use DHCPv6 PD you can't assign ad= dress space to an unlimited number of endpoints - you are limited to
    > however
    > > >> many
    > > >>>> /64s you have available.
    > > >>>>>
    > > >>>>> If you use IA_NA or SLAAC, any network with = a /64 subnet has, at least in theory, an "unlimited" number of ad= dresses to
    > assign
    > > to
    > > >>>> clients. Of course, that's only true in theory. = In practice, there's going to be a limit due to scaling reasons.
    > > >>>>>
    > > >>>>> I don’t understand this. True that SLA= AC and DHCPv6 IA_NA/IA_TA can be used
    > > >>>>> to assign an unlimited number of addresses t= o interface “A”. But, so can DHCPv6
    > > >>>>> PD. When the node receives the delegated pre= fix (e.g., a /64), it can assign as
    > > >>>>> many unique IPv6 addresses as it likes to in= terface “A”. And again, it need not
    > > >>>>> do DAD for any of them.
    > > >>>>>
    > > >>>>>
    > > >>>>>
    > > >>>>> ____________________________________________= ___
    > > >>>>> v6ops mailing list
    > > >>>>> v6ops@ietf= .org
    > > >>>>> https://www.ietf.org/mailman/listinfo/v6ops
    > > >>>>>
    > > >>>
    > > >
    >
    > _______________________________________________
    > v6ops mailing list
    >     v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops



     

    --


    Mukom Akong T.

    LinkedIn:Mukom  |  twitter= : @perfexcellent  

    ----------------------------------------------------= ---------------------------------------------------------------------------= -----------
    “When you work, you are the FLUTE through whose lungs the whispering = of the hours turns to MUSIC" - Kahlil Gibran
    ---------------------------------------------------------------------------= ----------------------------------------------------------------=

    --_000_2134F8430051B64F815C691A62D9831832F3E8B0XCHBLV504nwnosb_-- From nobody Mon Nov 9 13:02: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 55F9F1B8476 for ; Mon, 9 Nov 2015 13:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 J_ueYJmzOYvj for ; Mon, 9 Nov 2015 13:02:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0251B8473 for ; Mon, 9 Nov 2015 13:02:27 -0800 (PST) Received: from [128.9.184.108] ([128.9.184.108]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tA9L24Hv009852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2015 13:02:05 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> From: Joe Touch Message-ID: <564109CA.7020505@isi.edu> Date: Mon, 9 Nov 2015 13:02:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 09 Nov 2015 21:02:29 -0000 On 11/8/2015 11:47 AM, Philip Homburg wrote: > Call me old fashioned, but what NAT breaks is not what is traditionally > called a protocol layering violation. (The TCP checksum is one of the classical > layering violations in the IP protocol stack) Given that a NAT breaks the TCP checksum (which depends on the IP pseudoheader and TCP header) and thus has to recalculate it, wouldn't that be proof that a NAT breaks what you consider protocol layer violation? Joe From nobody Mon Nov 9 13:05: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 19E6C1B848B for ; Mon, 9 Nov 2015 13:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o5gtO28ZESHp for ; Mon, 9 Nov 2015 13:05:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266F21B8489 for ; Mon, 9 Nov 2015 13:05:52 -0800 (PST) Received: from [128.9.184.108] ([128.9.184.108]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tA9L5SK7012532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2015 13:05:29 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> <563FC756.5090906@foobar.org> From: Joe Touch Message-ID: <56410A97.7050508@isi.edu> Date: Mon, 9 Nov 2015 13:05:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 09 Nov 2015 21:05:53 -0000 On 11/8/2015 3:08 PM, Philip Homburg wrote: >> ddns is also a layering violation because it makes an assumption at layer 7 >> >about what's going on in layer 3. > > Again, we have to use transport layer identifiers, because the IP stack > doesn't define anything else. Note that some protocols do define other identifiers, e.g., HTTP uses URNs. We often use L4 identifiers when there are no other upper layer end-to-end identifiers available, e.g., the app uses 128.9.160.161:80 because that's what the user provided. The fact that these are L4 (or L3) identifiers is true only because the addresses got passed down through the stack - which is definitely not layer violation. Joe From nobody Mon Nov 9 13:10: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 CD8F31B84A0 for ; Mon, 9 Nov 2015 13:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xteOC5O3oQHm for ; Mon, 9 Nov 2015 13:10:19 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09411B849F for ; Mon, 9 Nov 2015 13:10:18 -0800 (PST) Received: from [128.9.184.108] ([128.9.184.108]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tA9LA4tk010692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2015 13:10:04 -0800 (PST) To: Lorenzo Colitti , Fernando Gont References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> From: Joe Touch Message-ID: <56410BAA.3070604@isi.edu> Date: Mon, 9 Nov 2015 13:10:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 09 Nov 2015 21:10:20 -0000 On 11/8/2015 6:04 PM, Lorenzo Colitti wrote: > The main reason you wouldn't design it like that today is that NAT has > broken the original architecture of IPv4. NATs actually provide a very sensible model, just not the one most designers think. >From the private side, a NAT acts like a router. >From the public side, a NAT is (not just "acts like") the endpoint. So it's not surprising that running an application that isn't on the NAT box causes problems. The NAT is the problem - it wants to act like an endpoint (sourcing/sinking packets from/to a public IP address) but doesn't want (or have enough information) to run the app correctly. The IP achitecture is fine, and NATs can be a valid part of that architecture, but only to the extent of what they are. They ARE hosts on the public side. E.g., we would expect that it's hard to run 6 web servers on port 80 on a single host with a single IP address; why is it so surpising that a NAT can't support that? Joe From nobody Tue Nov 10 03:51: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 27CDA1A87BD for ; Tue, 10 Nov 2015 03:51:03 -0800 (PST) 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 NveNMAemyqio for ; Tue, 10 Nov 2015 03:51:01 -0800 (PST) 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 7B4841A1A8C for ; Tue, 10 Nov 2015 03:50:59 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Zw7Rx-0000CoC; Tue, 10 Nov 2015 12:50:57 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> <563FC756.5090906@foobar.org> <56410A97.7050508@isi.edu> In-reply-to: Your message of "Mon, 9 Nov 2015 13:05:27 -0800 ." <56410A97.7050508@isi.edu> Date: Tue, 10 Nov 2015 12:50:55 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 10 Nov 2015 11:51:03 -0000 >> Call me old fashioned, but what NAT breaks is not what is traditionally >> called a protocol layering violation. (The TCP checksum is one of the classical >> layering violations in the IP protocol stack) >Given that a NAT breaks the TCP checksum (which depends on the IP >pseudoheader and TCP header) and thus has to recalculate it, wouldn't >that be proof that a NAT breaks what you consider protocol layer violation? If a layering violation like in TCP gets broken by NAT, then I consider that fair game. I.e., such layering violations should not exist in the first place, so it is TCP that is broken. >On 11/8/2015 3:08 PM, Philip Homburg wrote: >>> ddns is also a layering violation because it makes an assumption at layer 7 >>> >about what's going on in layer 3. >> >> Again, we have to use transport layer identifiers, because the IP stack >> doesn't define anything else. > >Note that some protocols do define other identifiers, e.g., HTTP uses URNs. > >We often use L4 identifiers when there are no other upper layer >end-to-end identifiers available, e.g., the app uses 128.9.160.161:80 >because that's what the user provided. The fact that these are L4 (or >L3) identifiers is true only because the addresses got passed down >through the stack - which is definitely not layer violation. Commonly used URNs rely on transport layer addresses (which are broken by NAT) or DNS, which is also broken by NAT (in some cases). One way of looking at NAT is that it deals with a failure of IP addressing. In the case of IPv4, with the fact that 32 bits is just not enough. And in IPv6 most likely in cases where the locator/identifier split is not in the architecture. I.e. NAT breaks the model because it is a fix where the model is broken. From nobody Tue Nov 10 06:13: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 E22831B2ABF for ; Tue, 10 Nov 2015 06:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.01 X-Spam-Level: X-Spam-Status: No, score=-13.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IXHASH_X1=1.5, 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 gP3rO35GpAiw for ; Tue, 10 Nov 2015 06:13:27 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD7A1B2ABC for ; Tue, 10 Nov 2015 06:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3826; q=dns/txt; s=iport; t=1447164806; x=1448374406; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cCYObl7O00n95zi6Farx4otHrq2rOHeXpUciGFm3ugs=; b=X6ApzKOdCgQtfdrHIyU9ljeQkka9f4EDKGgpzvLSs6q8rkP4Jq8ZOb9e Jo/NzNnOtXiEQ6EUhG/EHpkarMMm7O50ITw1RmsTssE5oEhtBvRlWl5wh R3WVuSauX/c3exwlomIyOMpzMA6K7j268KXXfIDNtr4ZZtIpki3iyfcdc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBACb+kFW/xbLJq1egm6CFcAxhhACH?= =?us-ascii?q?IFpAQEBAQEBgQuENgEBBCNWEAIBCAQ+AgICMCUCBAENiDOyKZBTAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBGIZUAYR9h3WBRAWWSAGNJYFblniDcQFjhASFGYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,270,1444694400"; d="scan'208,217";a="606231940" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Nov 2015 14:13:24 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tAAEDNJn002231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2015 14:13:24 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 Nov 2015 09:13:22 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Tue, 10 Nov 2015 09:13:22 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFc2C6yTSpbG0CEaWKhsc8ktyjJ6JyxQAgABE1wCAAAqWgIAAB3cAgAAFO4CAA0S+AIAADmKAgACaOQCAAD0+AIAAKG4AgACkCICAAtW/AIAA8pUAgABauwCAAAhoAIAAATOAgAACYwCAAADjAIAABnIAgAADo4CAAApXAIAAAVmAgAJY7YA= Date: Tue, 10 Nov 2015 14:13:22 +0000 Message-ID: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> In-Reply-To: Accept-Language: fr-FR, 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.138.46] Content-Type: multipart/alternative; boundary="_000_D267B9E35DB8Cevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 10 Nov 2015 14:13:33 -0000 --_000_D267B9E35DB8Cevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpXaGF0IHlvdSByZWZlciB0byBoYXMgdG8gZG8gd2l0aCB0aGUgZGlvZGUtZmlyZXdhbGwgdGhp bmcgKHdoaWNoIGlzIGEgc2lkZSBlZmZlY3QgaW4gbmF0LCBhbmQgdGhhdCBmb2xrcyBhcmUgcmVw bGljYXRpbmcgaW4gaXB2NiBieSBkZXBsb3lpbmcgYSBkaW9kZSBmaXJld2FsbCB3aGVyZSB5b3Ug Y3VycmVudGx5IGhhdmUgYSBuYXQgYm94KS4gT2J2aW91c2x5LCBpZiB5b3VyIHBvbGljeSBpcyB0 aGF0IHlvdSBkb24ndCB3YW50IGluY29taW5nIGNvbm5lY3Rpb25zLCBhbmQgaSBoYXZlIHRoZSBz YW1lIHBvbGljeSB0aGVuLCB1bmZvcnR1bmF0ZWx5LCB3ZSBoYXZlIHRvIHRhbGsgdG8gYSB0aGly ZCBwYXJ0eS4NCg0KTm9wZS4gSXQgaXMgbXVjaCBlYXNpZXIgdG8gZXN0YWJsaXNoIGEgY29ubmVj dGlvbiBhY3Jvc3MgYSBkaW9kZSBmaXJld2FsbCB0aGFuIHRvIGVzdGFibGlzaCBvbmUgYWNyb3Nz IGEgTkFULiBJbiB0aGUgZm9ybWVyIGNhc2UsIGFsbCB0aGUgZW5kcG9pbnRzIG5lZWQgdG8gZG8g aXMgc2VuZCBlYWNoIG90aGVyIHBhY2tldHMgYXQgYWJvdXQgdGhlIHNhbWUgdGltZS4gSW4gdGhl IGxhdHRlciwgdGhleSBuZWVkIHRvIGltcGxlbWVudCBOQVQgdHJhdmVyc2FsIHZpYSByZWxheXMu DQoNCkl0IGlzIG9ubHkgJ3NsaWdodGx5JyBlYXNpZXIuLi4gQmVjYXVzZSBndWVzc2luZyB0aGUg VENQIHNlcXVlbmNlIG51bWJlciBvZiB0aGUgb3RoZXIgcGFydHkuLi4gV2VsbCBnb29kIGx1Y2sg Oi0pDQoNCi3DqXJpYw0KDQo= --_000_D267B9E35DB8Cevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8 ZGl2IGNsYXNzPSJoNSI+DQo8cCBkaXI9Imx0ciI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzNCwz NCwzNCkiPjxicj4NCldoYXQgeW91IHJlZmVyIHRvIGhhcyB0byBkbyB3aXRoIHRoZSBkaW9kZS1m aXJld2FsbCB0aGluZyAod2hpY2ggaXMgYSBzaWRlIGVmZmVjdCBpbiBuYXQsIGFuZCB0aGF0IGZv bGtzIGFyZSByZXBsaWNhdGluZyBpbiBpcHY2IGJ5IGRlcGxveWluZyBhIGRpb2RlIGZpcmV3YWxs IHdoZXJlIHlvdSBjdXJyZW50bHkgaGF2ZSBhIG5hdCBib3gpLiBPYnZpb3VzbHksIGlmIHlvdXIg cG9saWN5IGlzIHRoYXQgeW91IGRvbid0IHdhbnQgaW5jb21pbmcgY29ubmVjdGlvbnMsDQogYW5k IGkgaGF2ZSB0aGUgc2FtZSBwb2xpY3kgdGhlbiwgdW5mb3J0dW5hdGVseSwgd2UgaGF2ZSB0byB0 YWxrIHRvIGEgdGhpcmQgcGFydHkuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pk5vcGUuIEl0IGlzIG11Y2ggZWFzaWVyIHRvIGVzdGFibGlzaCBhIGNvbm5l Y3Rpb24gYWNyb3NzIGEgZGlvZGUgZmlyZXdhbGwgdGhhbiB0byBlc3RhYmxpc2ggb25lIGFjcm9z cyBhIE5BVC4gSW4gdGhlIGZvcm1lciBjYXNlLCBhbGwgdGhlIGVuZHBvaW50cyBuZWVkIHRvIGRv IGlzIHNlbmQgZWFjaCBvdGhlciBwYWNrZXRzIGF0IGFib3V0IHRoZSBzYW1lIHRpbWUuIEluIHRo ZSBsYXR0ZXIsIHRoZXkgbmVlZCB0byBpbXBsZW1lbnQgTkFUDQogdHJhdmVyc2FsIHZpYSByZWxh eXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBpcyBvbmx5ICdzbGlnaHRseScgZWFzaWVyLi4u IEJlY2F1c2UgZ3Vlc3NpbmcgdGhlIFRDUCBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIG90aGVyIHBh cnR5Li4uIFdlbGwgZ29vZCBsdWNrIDotKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LcOpcmljPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D267B9E35DB8Cevynckeciscocom_-- From nobody Tue Nov 10 06:51: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 4550D1B2CA9 for ; Tue, 10 Nov 2015 06:51:42 -0800 (PST) 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 pJBLR5GKKgBZ for ; Tue, 10 Nov 2015 06:51:41 -0800 (PST) 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 DA47E1B2CA4 for ; Tue, 10 Nov 2015 06:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1447167100; x=1448376700; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Cr5oaaCsPbBFv2za2Q375n07YRyRhCCZpNbTtMEyMRE=; b=bpWHpuHeKM91s7qW0emQ/aNO2AjcFvo8TE7IIr38R2EwaOvaCkx6tjpn kWVDd5Iq+enecxwefs6vOnNZZ4JUdhoVUHnwNujjs8j1EEwCbT5sUdzkV Q9QuJ6IFJPc0K10tlsaMgVVkGbKkJ2gcySIy0hlS6xl4xt8nn46UoKLDy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEAgDpA0JW/4UNJK1egztTbwa+PwENgWQXCoVvAhyBHzgUAQEBAQEBAYEKhDYBAQQBAQEgETobAgEIGgImAgICJQsVEAIEARKILg2yMpBZAQEBAQEBAQEBAQEBAQEBAQEBG4EBhVMBhH2EWYMcgUQFlkgBhRyICYFbSYN3gyWPE4NxAR8BAUKEBHKEJ4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,270,1444694400"; d="scan'208";a="48381182" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 10 Nov 2015 14:51:39 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAAEpdiP013339 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Nov 2015 14:51:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 Nov 2015 09:51:38 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Tue, 10 Nov 2015 09:51:38 -0500 From: "Eric Vyncke (evyncke)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world WGLC Thread-Index: AQHRGle4KJiHTNZSP0+RcjmtWDx6DZ6Vvn+A Date: Tue, 10 Nov 2015 14:51:38 +0000 Message-ID: References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> In-Reply-To: <201511081900.tA8J02iD007338@irp-lnx1.cisco.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.7.151005 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: <5376BC323A3DAB44A30A260E73A0858A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Tue, 10 Nov 2015 14:51:42 -0000 RnJlZCwgRmVybmFuZG8sIEplbiBhbmQgVGltLA0KDQpBcyB5b3Uga25vdyB0aGlzIHRvcGljIGlz IG9mIGhpZ2ggaW50ZXJlc3QgdG8gbWUsIHNvLCBwbGVhc2UgYWNjZXB0IG15DQpjb21tZW50cyBh cyB0b2tlbiBvZiBhcHByZWNpYXRpb24gb2YgeW91ciB3b3JrIGZvciBpbXByb3ZlbWVudDoNCg0K LSBkYXRhIGRhdGVzIGJhY2sgdG8gQXVndXN0IDIwMTQuLi4gV291bGQgaXQgYmUgcG9zc2libGUg dG8gaGF2ZSBhIHJlZnJlc2gNCmRhdGVkIGxhdGUgMjAxNT8gU29tZSBvcGVyYXRvcnMgaGF2ZSBy ZWFjdGVkIHRvIHlvdXIgSS1EIGFuZCB0aGUgc2l0dWF0aW9uDQoocGVyIG15IG93biBtZWFzdXJl bWVudHMpIGhhcyBpbXByb3ZlZA0KLSBzZWN0aW9uIDIgc2hvdWxkIHN0YXRlIHRoZSBUQ1AgZmxh Z3MgdXNlZCAocHJvYmFibHkganVzdCBTWU4pDQotIChjb3NtZXRpYykgSSB3b3VsZCByZW1vdmUg dGFibGUgMiBhcyBpdCBpcyBhIGR1cGxpY2F0ZSBvZiB0YWJsZSAxIChhbmQNCnNhbWUgZm9yIHRh YmxlIDMvNCkNCi0gc29tZXdoZXJlIHlvdSBzaG91bGQgbWVudGlvbiB0aGF0IHVzaW5nIEFsZXhh IGlzIHNvbWVob3cgcmVzdHJpY3RpdmUgYXMNCm5vdCBldmVyeW9uZSBpcyBnb2luZyB0byB0aGUg YmlnIHBsYXllcnMgKHdobyBhbHNvIHVzZXMgdGhlaXIgb3duDQpDRE4vaW5mcmEpDQotIChkcmVh bSBtb2RlIG9uKSBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgYW5vdGhlciBjb2x1bW4gJ2Ryb3Bw ZWQgYnkgQ0ROJw0KLSBJIGFwcHJlY2lhdGUgdGhlIG5ldyBzaG9ydGVyIGZvcm1hdCA7LSkNCg0K VGhpcyBpcyBhbiBpbXBvcnRhbnQgdG9waWMsIHNvLCBJIHdvdWxkIGxvdmUgdG8gaGF2ZSBmcmVz aGVyIHJlc3VsdA0KKHBlcmhhcHMgZXZlbiBjb21wYXJpbmcgMjAxNCB2cyAyMDE1KSB3aXRob3V0 IGNoYW5naW5nIHRvbyBtdWNoIHRoZSB0ZXh0DQooZXhjZXB0IGFib3ZlIGNvbW1lbnQpLg0KDQoN Ci3DqXJpYw0KDQpPbiA4LzExLzE1IDIwOjAwLCAidjZvcHMgb24gYmVoYWxmIG9mIEZyZWQgQmFr ZXIgKGZyZWQpIg0KPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGZyZWRAY2lz Y28uY29tPiB3cm90ZToNCg0KPlRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvZg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC4NCj5QbGVhc2UgcmVhZCBpdCBub3cuIElm IHlvdSBmaW5kIG5pdHMgKHNwZWxsaW5nIGVycm9ycywgbWlub3Igc3VnZ2VzdGVkDQo+d29yZGlu ZyBjaGFuZ2VzLCBldGMpLCBjb21tZW50IHRvIHRoZSBhdXRob3JzOyBpZiB5b3UgZmluZCBncmVh dGVyDQo+aXNzdWVzLCBzdWNoIGFzIGRpc2FncmVlaW5nIHdpdGggYSBzdGF0ZW1lbnQgb3IgZmlu ZGluZyBhZGRpdGlvbmFsDQo+aXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQsIHBsZWFz ZSBwb3N0IHlvdXIgY29tbWVudHMgdG8gdGhlDQo+bGlzdC4NCj4NCj5XZSBhcmUgbG9va2luZyBz cGVjaWZpY2FsbHkgZm9yIGNvbW1lbnRzIG9uIHRoZSBpbXBvcnRhbmNlIG9mIHRoZQ0KPmRvY3Vt ZW50IGFzIHdlbGwgYXMgaXRzIGNvbnRlbnQuIElmIHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50 IGFuZA0KPmJlbGlldmUgaXQgdG8gYmUgb2Ygb3BlcmF0aW9uYWwgdXRpbGl0eSwgdGhhdCBpcyBh bHNvIGFuIGltcG9ydGFudA0KPmNvbW1lbnQgdG8gbWFrZS4NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2 b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KDQo= From nobody Tue Nov 10 06:56: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 039011B37DD for ; Tue, 10 Nov 2015 06:56:17 -0800 (PST) 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 opLOKFZ-MUPR for ; Tue, 10 Nov 2015 06:56:13 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B3B1B37D2 for ; Tue, 10 Nov 2015 06:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3607; q=dns/txt; s=iport; t=1447167373; x=1448376973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=trZE3Y2RcqYSD2SkWgDiIRKb3qeSj12Jbs1KeC8dQmc=; b=iEgWu0H17ZkTtm7ZZCoW3r6uQhSvRC8L69dv56uuIdzLTRSF0Pbp1kpd NAtupFGw2vv0edVVqSLO/kH34DM/Ya1YF8PpWUDmwY6WAqnm5eaSnlewx UdRdci3H/ADgj4oNm7jJEeFmyY+CeodmqKG1wii3zQfmExGX02cb+VnsE 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9AgBTBUJW/xbLJq1ehA5gDwa+Pw6BZBcKhW8CgXMUAQEBAQEBAYEKhDUBAQEDAQEBASBLCwULAgEIGCoCAicLJQIEDgUOiBgIDbIwkFsBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYhkgm6HdS+BFQWWSAGCUoFgaogJgVtJg3eDJY8Tg3EBHwFDhARyhCeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,270,1444694400"; d="asc'?scan'208";a="631520291" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Nov 2015 14:56:02 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tAAEu2Ee014023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Nov 2015 14:56:02 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; Tue, 10 Nov 2015 09:56:01 -0500 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; Tue, 10 Nov 2015 09:56:01 -0500 From: "Fred Baker (fred)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world WGLC Thread-Index: AQHRG8fqts9QUso1qE6JClk6x+M1DA== Date: Tue, 10 Nov 2015 14:56:01 +0000 Message-ID: References: <201511081900.tA8J02iD007338@irp-lnx1.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.70.230.244] Content-Type: multipart/signed; boundary="Apple-Mail=_F5B16398-0A64-48AC-8E87-256D2D8E4CA1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Tue, 10 Nov 2015 14:56:17 -0000 --Apple-Mail=_F5B16398-0A64-48AC-8E87-256D2D8E4CA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando's report at IETF 94 was that the situation had not = substantially changed. Maybe you want to put the operators you mention = in touch with Fernando et al? > On Nov 10, 2015, at 11:51 PM, Eric Vyncke (evyncke) = wrote: >=20 > Fred, Fernando, Jen and Tim, >=20 > As you know this topic is of high interest to me, so, please accept my > comments as token of appreciation of your work for improvement: >=20 > - data dates back to August 2014... Would it be possible to have a = refresh > dated late 2015? Some operators have reacted to your I-D and the = situation > (per my own measurements) has improved > - section 2 should state the TCP flags used (probably just SYN) > - (cosmetic) I would remove table 2 as it is a duplicate of table 1 = (and > same for table 3/4) > - somewhere you should mention that using Alexa is somehow restrictive = as > not everyone is going to the big players (who also uses their own > CDN/infra) > - (dream mode on) it would be nice to have another column 'dropped by = CDN' > - I appreciate the new shorter format ;-) >=20 > This is an important topic, so, I would love to have fresher result > (perhaps even comparing 2014 vs 2015) without changing too much the = text > (except above comment). >=20 >=20 > -=C3=A9ric >=20 > On 8/11/15 20:00, "v6ops on behalf of Fred Baker (fred)" > wrote: >=20 >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. >> Please read it now. If you find nits (spelling errors, minor = suggested >> wording changes, etc), comment to the authors; if you find greater >> issues, such as disagreeing with a statement or finding additional >> issues that need to be addressed, please post your comments to the >> list. >>=20 >> We are looking specifically for comments on the importance of the >> document as well as its content. If you have read the document and >> believe it to be of operational utility, that is also an important >> comment to make. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_F5B16398-0A64-48AC-8E87-256D2D8E4CA1 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 iQIUAwUBVkIFfUayAOS/EQ8MAQIecg/48nwn8MB+ZINmki3zOZXtkJQTnjJvYTUE vfKFoullepA8DqXlFZCZEJznFEtoy7G6QmaE4gHvV1Xn0oJoAXzze8GDBE8KXk6f FmOlviIKuH9aoofW3kxC7Jv4ewGhVFAj+TPA3mkzJs25u3iFsp8NFHmq0v0Ix0hQ /mIz2YTdefpzVnU5sG8Jd2UDlgpdykvwCMrSfrQ0Blu2Tj4TKNYf2SpDL69wFfbK eOb5hlDSJoU/44Zr+j2+fTxda46VY9rGzeVuVitV9mOIx83WqI29NYF3B6bCpyYL N8RuL0XKCBcjb0nbWPfJRVXGQixAi4nCoHNSsiZFQLvbHOPQofgWx8fR0EWLEaIY hr/s/YzqAIuOWYkkWkYYhkinSQ/FJd/zxczze1iw5PGoHOxNPrchtw3aqZRRENlH f4Vr7zcG/8rMKXzpOrxTcd8S0NlO9ZmIJT9EyLvp7+pbDhfHIZpWpIgScf428b3E TlCO9kHfdmCQQ0g22ZMejfVu3aCP53IeGWcx7MDZHqJ1HEEbrc6JOleM2rHnRxxE fnt30pEkSJRlZkQpxByQT/TRNMC4gUR63ZXct1ORc4DhqwaBNFyh9vTU35sUi8JE JbENezKmFsSWbWRStHfdQkZuZLYtoIUPCaUcdKntG6g0hVXUjt8N8bvMTRLkC7dM sepmWnSDIw== =CrU5 -----END PGP SIGNATURE----- --Apple-Mail=_F5B16398-0A64-48AC-8E87-256D2D8E4CA1-- From nobody Tue Nov 10 07:33: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 8B2881B2D43 for ; Tue, 10 Nov 2015 07:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.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] 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 LQiA8SvsAIvc for ; Tue, 10 Nov 2015 07:32:58 -0800 (PST) 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 25BFA1B2D3B for ; Tue, 10 Nov 2015 07:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5640; q=dns/txt; s=iport; t=1447169578; x=1448379178; h=from:to:cc:subject:date:message-id:mime-version; bh=Nkx75lB4k8ZXmZiAbVy1PxCG/sRB9zh+YoErkPOlCbw=; b=FmdjjL7oqkRSmE2+yl0tNJ1OoQzB2K7Kx8kEXVmv4xM9qMGtxzWH7FAN hiB1GK50PaH+Q+m5TmX2RHuh47gzgwt2tKXAR4BfDS/vMCYonW3Ok1GK4 y+fK5+RUHDETXOnoCMThIMacAUc1GpQ83iY0xst8zLWjt+mNYSaqroLY3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOAgDDDUJW/5xdJa1egm5NgUIGvj8BDYEIBFmGEB6BJDgUAQEBAQEBAYEKhDUBAgQjQhQSAQgEDQMBAigDAgQwFAkKBA4FiC6yVpBiAQEBAQEBBAEBAQEBAQEchlQBhH2EJFeCeoFEBZJng2EBjSWcRAEfAQFChARyhCeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,271,1444694400"; d="scan'208,217";a="205555234" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 10 Nov 2015 15:32:57 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAAFWvuh018513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2015 15:32:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 Nov 2015 10:32:56 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Tue, 10 Nov 2015 10:32:56 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt Thread-Index: AQHRG80S6IbYesXE30qeJVbvw6n/dw== Date: Tue, 10 Nov 2015 15:32:56 +0000 Message-ID: Accept-Language: fr-FR, 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.138.46] Content-Type: multipart/alternative; boundary="_000_D267CC105DBE4evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-03.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, 10 Nov 2015 15:32:59 -0000 --_000_D267CC105DBE4evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0NoYW5naW5nIHRoZSBTdWJqZWN0IHRvIHJlZmxlY3QgdGhlIG5ldyAtMDNdDQoNCkdvb2QgZG9j dW1lbnQgYW5kIHVzZWZ1bCBvbmUuDQoNCkp1c3QgdHdvIGNvbW1lbnRzOg0KDQogICogICBzZWN0 aW9uIDUuMiwgc2hvdWxkIHdlIGFkZCBzb21lIHRleHQgYXJvdW5kIHBlcmZvcm1pbmcgYSBETkEg bXVzdCBiZSBiYWxhbmNlZCB3aXRoIHRoZSBsZW5ndGggb2Ygc2xlZXA/IEkuZS4sIEROQSBjb3Vs ZCB1c2UgbW9yZSBiYXR0ZXJ5IHRoYW4gc3RheWluZyAnYXNsZWVwJz8NCiAgKiAgIFNlY3Rpb24g OCwgdGhlIHBhcmFncmFwaCBpcyByaWdodCBidXQgaXQgYXBwbGllcyB0byBhbnkgbXVsdGljYXN0 IHdoZXRoZXIgSVB2NiBvciBub3QsIHdoZXRoZXIgUkEgb3Igbm90Li4uIEkgd291bGQgc3VnZ2Vz dCBhIHJld29yZGluZw0KDQpBZ2FpbiBhIHVzZWZ1bCwgc2hvcnQgSS1EIDotKQ0KDQotw6lyaWMN Cg0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2ds ZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+DQpEYXRlOiB2ZW5kcmVkaSA2IG5vdmVt YnJlIDIwMTUgMDM6MDANClRvOiBEYXZpZCBGYXJtZXIgPGZhcm1lckB1bW4uZWR1PG1haWx0bzpm YXJtZXJAdW1uLmVkdT4+DQpDYzogInY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4gV0ciIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1yZWR1Y2luZy1yYS1lbmVy Z3ktY29uc3VtcHRpb24tMDIudHh0DQoNCk9uIEZyaSwgTm92IDYsIDIwMTUgYXQgMTI6MTIgQU0s IERhdmlkIEZhcm1lciA8ZmFybWVyQHVtbi5lZHU8bWFpbHRvOmZhcm1lckB1bW4uZWR1Pj4gd3Jv dGU6DQpJIHN0aWxsIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMgaXMgdXNpbmcgdGhlIHRlcm0g Im1vYmlsZSBkZXZpY2UiLCBhbmQgdGhlIHJlc3Qgb2YgdGhlIHRleHQgdXNlcyAiYmF0dGVyeS1w b3dlcmVkIGhvc3QiLg0KDQpGaXggcXVldWVkIHVwIGZvciAtMDMuDQo= --_000_D267CC105DBE4evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <177336576C3E644AA83D0754792A08A8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5bQ2hhbmdpbmcg dGhlIFN1YmplY3QgdG8gcmVmbGVjdCB0aGUgbmV3IC0wM108L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pkdvb2QgZG9jdW1lbnQgYW5kIHVzZWZ1bCBvbmUuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5KdXN0IHR3byBjb21tZW50czo8L2Rpdj4NCjx1bD4NCjxsaT5zZWN0aW9u IDUuMiwgc2hvdWxkIHdlIGFkZCBzb21lIHRleHQgYXJvdW5kIHBlcmZvcm1pbmcgYSBETkEgbXVz dCBiZSBiYWxhbmNlZCB3aXRoIHRoZSBsZW5ndGggb2Ygc2xlZXA/IEkuZS4sIEROQSBjb3VsZCB1 c2UgbW9yZSBiYXR0ZXJ5IHRoYW4gc3RheWluZyAnYXNsZWVwJz88L2xpPjxsaT5TZWN0aW9uIDgs IHRoZSBwYXJhZ3JhcGggaXMgcmlnaHQgYnV0IGl0IGFwcGxpZXMgdG8gYW55IG11bHRpY2FzdCB3 aGV0aGVyIElQdjYgb3Igbm90LCB3aGV0aGVyIFJBIG9yIG5vdC4uLiBJIHdvdWxkIHN1Z2dlc3Qg YSByZXdvcmRpbmc8L2xpPjwvdWw+DQo8ZGl2PkFnYWluIGEgdXNlZnVsLCBzaG9ydCBJLUQgOi0p PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tw6lyaWM8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIExvcmVu em8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bG9yZW56 b0Bnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RGF0ZTogPC9zcGFuPnZlbmRyZWRpIDYgbm92ZW1icmUgMjAxNSAwMzowMDxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkRhdmlkIEZhcm1lciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZhcm1lckB1bW4uZWR1Ij5mYXJtZXJAdW1uLmVkdTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4gV0cmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1yZWR1Y2luZy1yYS1lbmVyZ3ktY29uc3VtcHRp b24tMDIudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92IDYsIDIwMTUgYXQgMTI6MTIgQU0sIERh dmlkIEZhcm1lciA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmZhcm1lckB1 bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+ZmFybWVyQHVtbi5lZHU8L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGRpcj0iYXV0byI+PHNwYW4+DQo8ZGl2Pkkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZCB3aHkg dGhpcyBpcyB1c2luZyB0aGUgdGVybSAmcXVvdDttb2JpbGUgZGV2aWNlJnF1b3Q7LCBhbmQgdGhl IHJlc3Qgb2YgdGhlIHRleHQgdXNlcyAmcXVvdDtiYXR0ZXJ5LXBvd2VyZWQgaG9zdCZxdW90Oy4g Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5GaXggcXVldWVkIHVwIGZvciAtMDMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D267CC105DBE4evynckeciscocom_-- From nobody Tue Nov 10 09:35: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 956FB1B30A3 for ; Tue, 10 Nov 2015 09:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 1ULXrGJ5x0jd for ; Tue, 10 Nov 2015 09:34:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B031A87EF for ; Tue, 10 Nov 2015 09:34:59 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAAHYPb6019100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2015 09:34:26 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> <563FC756.5090906@foobar.org> <56410A97.7050508@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56422AA1.2050700@isi.edu> Date: Tue, 10 Nov 2015 09:34:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; 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 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 10 Nov 2015 17:35:00 -0000 On 11/10/2015 3:50 AM, Philip Homburg wrote: >>> Call me old fashioned, but what NAT breaks is not what is traditionally >>> called a protocol layering violation. (The TCP checksum is one of the classical >>> layering violations in the IP protocol stack) > >> Given that a NAT breaks the TCP checksum (which depends on the IP >> pseudoheader and TCP header) and thus has to recalculate it, wouldn't >> that be proof that a NAT breaks what you consider protocol layer violation? > > If a layering violation like in TCP gets broken by NAT, then I consider > that fair game. What's the layering violation? TCP endpoints are defined as being the endpoint IP + port pair. TCP and IP are not independent layers; they never have been. > I.e., such layering violations should not exist in the > first place, so it is TCP that is broken. If you believe that TCP should have its own IP addresses, then fine. Let's consider the following: IP-IP-TCP Then the first layer is IP, the second is the IP-TCP pair. That would provide the clean layering you desire, but NATs would break that too. NATs intentionally overwrite identities - not just routes. There's no way to do that without violating every basic premise of layering. ... >> We often use L4 identifiers when there are no other upper layer >> end-to-end identifiers available, e.g., the app uses 128.9.160.161:80 >> because that's what the user provided. The fact that these are L4 (or >> L3) identifiers is true only because the addresses got passed down >> through the stack - which is definitely not layer violation. > > Commonly used URNs rely on transport layer addresses (which are broken by > NAT) or DNS, which is also broken by NAT (in some cases). Right - the basic concept of a NAT is exactly opposite the concept of strict layering. > One way of looking at NAT is that it deals with a failure of IP addressing. > In the case of IPv4, with the fact that 32 bits is just not enough. Another view is that NATs also exist - especially in IPv6 - as a way for ISPs to enforce a pricing policy that differentiates consumers from corporate customers by artificially and deliberately interfering with the Internet model of global endpoint addresses (i.e., to interfere with setting up a server, because - of course - only a corporate customer would need to do that). > And in IPv6 most likely in cases where the locator/identifier split is not > in the architecture. See above. > I.e. NAT breaks the model because it is a fix where the model is broken. I agree that NATs for true address sharing serve a useful purpose, but that disappears with IPv6. NATs for security can easily be replaced by stateful firewalls, i.e., that limit incoming connections without rewriting the headers. The problem with believing that NATs fix a broken model is that, if the model *is* broken, it's because of a lack of transport-layer IDs. NATs further destroy that concept when they overwrite both addresses and ports - that's not fixing a broken model, it's breaking it even more. Joe From nobody Tue Nov 10 10:50: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 F3D781A90BE for ; Tue, 10 Nov 2015 10:50:50 -0800 (PST) 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 Q0cib2GL-_ob for ; Tue, 10 Nov 2015 10:50:49 -0800 (PST) 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 7B6E21A8A47 for ; Tue, 10 Nov 2015 10:50:49 -0800 (PST) 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 tAAIon1d000612; Tue, 10 Nov 2015 11:50:49 -0700 Received: from XCH-BLV-201.nw.nos.boeing.com (xch-blv-201.nw.nos.boeing.com [10.57.37.66]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAAIof5P000509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 10 Nov 2015 11:50:41 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.214]) with mapi id 14.03.0235.001; Tue, 10 Nov 2015 10:50:40 -0800 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-templin-v6ops-pdhost Thread-Index: AQHRGJFHSaS6FSGPbkO2UJjsQ6e3sJ6Vm7Ig Date: Tue, 10 Nov 2015 18:50:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F3F3CB@XCH-BLV-504.nw.nos.boeing.com> References: <201511061247.tA6Cl2jH030359@irp-lnx1.cisco.com> In-Reply-To: <201511061247.tA6Cl2jH030359@irp-lnx1.cisco.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: Cc: "draft-templin-v6ops-pdhost@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-templin-v6ops-pdhost 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, 10 Nov 2015 18:50:51 -0000 Hi, this draft was motivated by list discussions on: "draft-ietf-v6ops-host-addr-availability discussion" https://mailarchive.ietf.org/arch/msg/v6ops/lr_yxnCT-psUVMjdMizX0wq9aPI I suggested text on considerations for DAD and multi-addressing based on a delegated prefix but the discussion stalled. So, I wrote up the considerati= ons in this draft. Should this go as a separate draft, or should we fold these considerations into 'draft-ietf-v6ops-host-addr-availability" ? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > Sent: Friday, November 06, 2015 4:47 AM > To: v6ops@ietf.org > Cc: draft-templin-v6ops-pdhost@tools.ietf.org > Subject: [v6ops] new draft: draft-templin-v6ops-pdhost >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-templin-= v6ops-pdhost. Please take a look at it and comment. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 10 16:25: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 A2E721AC409 for ; Tue, 10 Nov 2015 16:25:54 -0800 (PST) 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 2IZYm9rtQ6W6 for ; Tue, 10 Nov 2015 16:25:53 -0800 (PST) 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 C26091AC3FD for ; Tue, 10 Nov 2015 16:25:52 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZwJEQ-0006n6-I7; Wed, 11 Nov 2015 01:25:46 +0100 To: "Eric Vyncke (evyncke)" , Lorenzo Colitti References: <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56421508.10400@si6networks.com> Date: Wed, 11 Nov 2015 01:02:16 +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: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 11 Nov 2015 00:25:55 -0000 On 11/10/2015 11:13 PM, Eric Vyncke (evyncke) wrote: > > What you refer to has to do with the diode-firewall thing (which > is a side effect in nat, and that folks are replicating in ipv6 > by deploying a diode firewall where you currently have a nat > box). Obviously, if your policy is that you don't want incoming > connections, and i have the same policy then, unfortunately, we > have to talk to a third party. > > Nope. It is much easier to establish a connection across a diode > firewall than to establish one across a NAT. In the former case, all > the endpoints need to do is send each other packets at about the > same time. In the latter, they need to implement NAT traversal via > relays. > > It is only 'slightly' easier... Because guessing the TCP sequence number > of the other party... Well good luck :-) I guess that, at the very least, you need be able to guess the ephemeral ports? And, if you're able to do that, there's a flaw in there (see rfc 6056). Bottom line is...wh're talking about which pain is less pain :-)... and truth is that in most of such "pain" scenarios the aforementioned pain reflects policy of "I don't want to talk with anybody, unless it's me the one starting the conversation" -- i.e., you shouldn't be ding it, anyway. 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 Nov 10 16: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 381931AC40E for ; Tue, 10 Nov 2015 16:25:57 -0800 (PST) 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 ou6b02zwsiyx for ; Tue, 10 Nov 2015 16:25:56 -0800 (PST) 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 2A6C21AC3FD for ; Tue, 10 Nov 2015 16:25:56 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZwJEW-0006nF-7x; Wed, 11 Nov 2015 01:25:52 +0100 To: "Eric Vyncke (evyncke)" , "Fred Baker (fred)" , "v6ops@ietf.org" References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5642177A.7020900@si6networks.com> Date: Wed, 11 Nov 2015 01:12:42 +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: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Wed, 11 Nov 2015 00:25:57 -0000 Hi, Eric, On 11/10/2015 11:51 PM, Eric Vyncke (evyncke) wrote: > > As you know this topic is of high interest to me, so, please accept my > comments as token of appreciation of your work for improvement: Thanks! Comments in-line.... > - data dates back to August 2014... Would it be possible to have a refresh > dated late 2015? Some operators have reacted to your I-D and the situation > (per my own measurements) has improved I'll double-check and apply the necessary refreshment. My recollection of me repeating the measurements over time is that they didn't change significantly, but I'll recheck -- thanks for pointing it out, and thanks for repeating the measurements, btw! > - section 2 should state the TCP flags used (probably just SYN) Yes. > - (cosmetic) I would remove table 2 as it is a duplicate of table 1 (and > same for table 3/4) Me, I agree. IIRC this was added on request of at least someone in the wg,,, so I'll wait for other to weigh in, but note that I'm in favor of the change,,, > - somewhere you should mention that using Alexa is somehow restrictive as > not everyone is going to the big players (who also uses their own > CDN/infra) Would you mind elaborating? mm... you argue that some popular (Top 1M) simply don't show up in Alexa's rate, or something else? > - (dream mode on) it would be nice to have another column 'dropped by CDN' > - I appreciate the new shorter format ;-) :-) > This is an important topic, so, I would love to have fresher result > (perhaps even comparing 2014 vs 2015) without changing too much the text > (except above comment). I'll update the numbers. Comparing (given the number of types of measurements would probably be difficult, however)... 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 Tue Nov 10 16:37: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 EAEEF1B44BE for ; Tue, 10 Nov 2015 16:37:40 -0800 (PST) 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 L2w6P--P4Yi5 for ; Tue, 10 Nov 2015 16:37:39 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940571B44BD for ; Tue, 10 Nov 2015 16:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2046; q=dns/txt; s=iport; t=1447202260; x=1448411860; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y7Tt+k9DJ7ZZxt+1qv63BNIajpFM70T44Z7seaAT7J8=; b=KSDC0Lao/2iw9LLe1EFeUN0vZ3Qbu3ZrSuvuEoYrc8VC5esxD1pHTZuU kklItxZHkJcS8nPebpWDpUjIUI+7JZQhZ0FRWBj19HR/1MXhBCsGB/nyq sxv8aXi3u2+PSDOhFExs/MB7gx4jEcJbxP0bXS5AuN7sXVmDTqEAc1f8y k=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBQBijEJW/4MNJK1egztTbwa8KoIogWUdhXMCgUQ5EwEBAQEBAQGBCoQ0AQEBAwF5BQsCAQgOCi4yJQIEDgUOiBgIxBkBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYhkgm6FGYMLgRUBBI0biS0BglKBYGqICYIkmiABIgFAhARyhE+BBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,272,1444694400"; d="asc'?scan'208";a="207079303" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 11 Nov 2015 00:37:39 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tAB0bcAE020335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 00:37:38 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; Tue, 10 Nov 2015 19:37:37 -0500 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; Tue, 10 Nov 2015 19:37:37 -0500 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world WGLC Thread-Index: AQHRHBkqxbLG21Wnh02B7BdCMG0eyQ== Date: Wed, 11 Nov 2015 00:37:37 +0000 Message-ID: References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> <5642177A.7020900@si6networks.com> In-Reply-To: <5642177A.7020900@si6networks.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.244] Content-Type: multipart/signed; boundary="Apple-Mail=_47470FDA-ADE3-4831-8A4B-97BE4DEEC6E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Wed, 11 Nov 2015 00:37:41 -0000 --Apple-Mail=_47470FDA-ADE3-4831-8A4B-97BE4DEEC6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 11, 2015, at 1:12 AM, Fernando Gont = wrote: >=20 >> - somewhere you should mention that using Alexa is somehow = restrictive as >> not everyone is going to the big players (who also uses their own >> CDN/infra) >=20 > Would you mind elaborating? mm... you argue that some popular (Top 1M) > simply don't show up in Alexa's rate, or something else? Quantcast also has a "top million", and while there is a large overlap, = there are at least some differences in ordering. Both have some = "interesting" members, such as Alexa's 1993,zhidao.baidu.com/user/admin and both have some (apparently) very popular sites whose name contains a = space - "Hidden profile". --Apple-Mail=_47470FDA-ADE3-4831-8A4B-97BE4DEEC6E6 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 iQIVAwUBVkKNzkayAOS/EQ8MAQKqLQ//cBWSxtwrwq1ej95EoHbbz30aFmSCrJOV LtuVOnNaeswfCGmbO5TFIZXB7a3UBT0/wppBgJ+ne8pMoNHkm39P6p1bTJCP+YPj bSiwDKNrqsSjDnDaTtl6W9+8VDSmkCspJiLeIlinrKaw54+6Ucy3BAhRcGRHfnqj PiVcxI65gaZ70PqXleURhg5xAOPK1u4BTcWA39vGajELAMOh8re5Xuvd+ndh/iK6 8ywuuHGcgE2/DhyKpvKoDbpPxRpbM2fcskK2zmJLTyNM3oj6yXeOFoldFnhnUe8v ICnmHmE9oOktHTjSNR7uwqjogzI1m5Ry+mbIQXFfzp50fn6XgyThgYHBMf9rPCul 2IS441fL5CwFx/aCaKSSz5dhf3NJsN0v59AUZatYsDMg+Tmz/dZuhmC6GvF0/8hP 2Dwu9mrUtftvK/gJ1dZ1e+wRZHSDvT3UZqNx59Cci+JOmFbWXrUi3h0US6wx80An JBLTTKgi9rEeS05H0dHNFKn8tC5FBNYuucEokC/NIPjmmbFn8bIRUyuswmUzzxoL YDczri58PZ8wakaT7oIqnlhzquUuhLnfZpwSCc0hFRnmo2fRaHFtLE2TI6RqR5IP E090ZvX8jNlABiG4S+cesy32Mr/eMtqkgT7VEmaWhoAMuk7df+AI8DhjmP86NhRB AuiD4wpYrDM= =Bb1+ -----END PGP SIGNATURE----- --Apple-Mail=_47470FDA-ADE3-4831-8A4B-97BE4DEEC6E6-- From nobody Wed Nov 11 06:01: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 F2FC51ACE76; Wed, 11 Nov 2015 06:01:02 -0800 (PST) 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 aTlU53iIsH6b; Wed, 11 Nov 2015 06:01:00 -0800 (PST) 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 B3AF91ACE73; Wed, 11 Nov 2015 06:01:00 -0800 (PST) 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 94873880E6; Wed, 11 Nov 2015 06:01:00 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9DC73328081A; Wed, 11 Nov 2015 06:00:59 -0800 (PST) References: <20151110204646.14504.87111.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org" , mboned@ietf.org, pim@ietf.org, IPv6 Operations , "int-area@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, dnssd@ietf.org, homenet@ietf.org From: Brian Haberman X-Forwarded-Message-Id: <20151110204646.14504.87111.idtracker@ietfa.amsl.com> Message-ID: <56434A0F.2070407@innovationslab.net> Date: Wed, 11 Nov 2015 09:00:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110204646.14504.87111.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IFJ7NbECJQGqSn59wSnwBW2BwEQHsKC4C" Archived-At: Subject: [v6ops] Fwd: New Non-WG Mailing List: Mcast-wifi -- Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues. 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, 11 Nov 2015 14:01:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IFJ7NbECJQGqSn59wSnwBW2BwEQHsKC4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, Apologies for the spam, but I think this is relevant to a number of WGs. If you have an interest in the interactions between IP multicast and 802.11 networks, please join the list and contribute to the discussio= n. Regards, Brian -------- Forwarded Message -------- Subject: New Non-WG Mailing List: Mcast-wifi -- Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues. Date: Tue, 10 Nov 2015 12:46:46 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: mcast-wifi@ietf.org A new IETF non-working group email list has been created. List address: mcast-wifi@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dmcast-wif= i To subscribe: https://www.ietf.org/mailman/listinfo/mcast-wifi Purpose: This list is used for discussions related to issues with multicast in 802.11 Wi-Fi networks as well as solutions/optimizations targeted at resolving these issues. Related working groups are 6lo/6man/6tisch/intarea/mboned/pim/v6ops. For additional information, please contact the list administrators. --IFJ7NbECJQGqSn59wSnwBW2BwEQHsKC4C 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 iQEcBAEBCAAGBQJWQ0oaAAoJEBOZRqCi7goqTNcH/3ovB093WMtbbeSJpfa7SPku C18dvDbyzJDdoChnaVPmp5IB9xrin7y52SW2ul5V89I+Cr/U19WCmRweEAZahy2E k11y3Mfec+8cip4vBkyo4GR5CETAAgMT1+60XB6lsFOdLe8Q8TT/A4A+nvrDg4Ey TBAFAYBKQuJRyUDtPAEi/b1JbrBDdx49Zvr3JL9mkyJeO6czi4/IjqIo+yPT7u1F 75XSEqUeoh9fdudVKYH1pD/k/AqKqlINSjmm9PbsE+hwOJ1NebVLXCj6g+jm0uOe coojsJ5PJkcSLpvwrfnqERG+EzTpgjLpDxEZ27JTRWHd5ds6vFJK3mBHlp8gGSg= =k+pk -----END PGP SIGNATURE----- --IFJ7NbECJQGqSn59wSnwBW2BwEQHsKC4C-- From nobody Wed Nov 11 10:05: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 847511B31AB for ; Wed, 11 Nov 2015 10:05:03 -0800 (PST) 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] 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 qgY3VGVjUr7w for ; Wed, 11 Nov 2015 10:04:58 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 C7C651B31A5 for ; Wed, 11 Nov 2015 10:04:58 -0800 (PST) Received: by ykdv3 with SMTP id v3so62123343ykd.0 for ; Wed, 11 Nov 2015 10:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sIEn7WFAZn8SX16/xWkruh8a7S8K0ixsmpScR3kpBQQ=; b=ZD8UXG3vybdCrA4om95JM8mvKHQwdqLLLO3EBZ7uQJTrPxII6fo14aI654Zn9BLGrA UPi2svuBmQZI3p1ozwKdYold+CwCTKYhwrCzxPfw6ofTbl7ymIyh878x2MVXsgwYbD4q IYCvRmHYzFdQnej7gslM+UlVGAYUM9GldwwVDith832GX3UOmyuSJLRs/ViU1jGEMzmV yam/7OP7OH9PQJLrFIa/oOqXzDU20cGqGqJh9ecoDXxeMsDaIyhOPPlnDdBimQACscD+ T26eG9EXCUc1jBHjaVeKob47RaaLH6oP14X7lrXkA2BDUXUEN99fWaDc60CGu43emWsp adlQ== 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=sIEn7WFAZn8SX16/xWkruh8a7S8K0ixsmpScR3kpBQQ=; b=M/+s1z61hcWRM6Tnjl+33eyqkxL08Z9KkfirKGjSU8IUAMY8+9nuBgJAmu3S3NM10z RaQ0iYlmfITolTpWhBMWC0lMHfaEukplcWi1lfpppJrXN8bbvr37UTMu45zShWxCegJB i7Zof/LJcjU6uvu33dLyMt2wUWBh1I3K51Mw1x7nugQaRTo+fI9J8IhVL/sBuZBXtImx Tx3lysoOGvrpSmRnZiZRll2zyeH257NBTqE7MB4cdDZjalyDyzKuL/N5wSuK733zLIFH S62koUgYe6cjDPKStUgx8wJpK7suoFGmlTjPszY/XJNYK073aXkF3n1cInaFJ+euVzAj Fdxg== X-Gm-Message-State: ALoCoQmwvsYDiWQDxAlunsoeCRnqeSVQkpbW+H/Tcg4XDw0M6hPY85GkDDFOBO5CYCwqW3n4lx5i MIME-Version: 1.0 X-Received: by 10.129.117.11 with SMTP id q11mr10922525ywc.42.1447265097843; Wed, 11 Nov 2015 10:04:57 -0800 (PST) Received: by 10.37.202.11 with HTTP; Wed, 11 Nov 2015 10:04:57 -0800 (PST) In-Reply-To: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> Date: Thu, 12 Nov 2015 03:04:57 +0900 Message-ID: From: Warren Kumari To: Fred Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Wed, 11 Nov 2015 18:05:03 -0000 On Mon, Nov 9, 2015 at 4:00 AM, wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I have read this and believe it to be useful. Nit: I think that the acronyms in the tables (e.g DO8, FH512) should be expanded, preferably close to the table. W > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Nov 11 14:18: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 8747A1B3B44 for ; Wed, 11 Nov 2015 14:18:22 -0800 (PST) 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 auXIHw_YDHoE for ; Wed, 11 Nov 2015 14:18:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 456521B3B41 for ; Wed, 11 Nov 2015 14:18:20 -0800 (PST) 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 tABMHH64015461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Nov 2015 14:17:17 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <563B9D1E.4030606@umn.edu> Date: Wed, 11 Nov 2015 14:17:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B35AE06-9E77-4092-BDE0-E3997D28CE4C@delong.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 11 Nov 2015 22:18:22 -0000 > On Nov 5, 2015, at 10:17 , David Farmer wrote: >=20 > On 11/5/15 03:05 , Howard, Lee wrote: >>=20 >> From: Lorenzo Colitti > >>=20 >> On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee = > > wrote: >>=20 >> And so on. It seems pretty clear. Is this language >> insufficiently strong for you? What words would you use = instead? >>=20 >>=20 >> I would prefer if we used phrasing of the form " is = considered >> harmful" or " is not recommended". >>=20 >>=20 >> You deleted a lot of context, including the text: >>=20 >> =93(NPT66) is not recommended by the IETF.=94 >=20 > For the most part I like this. It takes emotional trigger words out = of it. However, I would suggest focusing on Internet connectivity and = away from all potential uses of NAT. I believe the primary objection to = NAT is in a general-purpose Internet context, and other more specialized = uses might be less objectionable to some. So something like; >=20 > Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in > the context of general-purpose Internet connectivity. I could live with this, but I suggest: =93Use of NPT66 and NAT66 as a general concept are NOT RECOMMENDED in = the context of internet connectivity.=94 If it connects to the v6 internet and it has a v6 address, it shouldn=92t = need or have NAT in the way. Sure, some people will do annoying and harmful things with their = networks, but there=92s no reason we should give them an escape clause = to legitimize such activity. Owen From nobody Thu Nov 12 09:54: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 424D31B2B70 for ; Thu, 12 Nov 2015 09:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 NfNWI8LhoVC9 for ; Thu, 12 Nov 2015 09:54:18 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 160491B2B6F for ; Thu, 12 Nov 2015 09:54:17 -0800 (PST) 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 tACHpoqT010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 09:51:50 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_0EBE2BDC-BB3A-4FEE-9BBC-846CEF2F93B7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Thu, 12 Nov 2015 09:51:49 -0800 Message-Id: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> To: Ivan Pepelnjak X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 17:54:21 -0000 --Apple-Mail=_0EBE2BDC-BB3A-4FEE-9BBC-846CEF2F93B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perhaps when someone presents a viable alternative for protocols that = require out-of-band signaling for connection setup and tear-down. Owen > On Nov 7, 2015, at 22:33 , Ivan Pepelnjak = wrote: >=20 > Just because I was driving without a seat belt for years doesn=E2=80=99t= mean that it=E2=80=99s safe to do so. Just because you COULD doesn=E2=80=99= t mean that you SHOULD. >=20 > When will we finally grow up (as a community) and get to a point where = everyone would consider sending network layer addresses in application = messages a bad practice regardless of whether it works or not? > Ivan Pepelnjak > www.ipSpace.net / blog.ipSpace.net = > On 8 Nov 2015 at 06:26:10, Lorenzo Colitti (lorenzo@google.com = ) wrote: >=20 >> On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard > wrote: >> On 06/11/2015 00:20, Lorenzo Colitti wrote: >>> It breaks any application that requires that the application know = its source address. Examples are SIP, FTP, audio/video chat, etc. >> your argument is the wrong way around: some protocols deliberately = introduce layering violations by demanding that transport identifier = information is encoded at the application layer. Transport identifier = translation merely shows up this brokenness. The brokenness is not with = the translation mechanism but with the higher level protocols. >>=20 >> Nope. Those protocols aren't broken, they worked fine for years until = NAT arrived and broke them. They still work fine on networks that = operate the way the Internet was originally designed with end-to-end = connectivity. >> _______________________________________________=20 >> v6ops mailing list=20 >> v6ops@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/v6ops=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_0EBE2BDC-BB3A-4FEE-9BBC-846CEF2F93B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Perhaps when someone presents a viable alternative for = protocols that require out-of-band signaling for connection setup and = tear-down.

    Owen

    On Nov 7, 2015, at 22:33 , Ivan = Pepelnjak <ipepelnjak@gmail.com> wrote:

    Just because I was driving without a seat belt = for years doesn=E2=80=99t mean that it=E2=80=99s safe to do so. Just = because you COULD doesn=E2=80=99t mean that you SHOULD.

    When will we finally grow up (as a community) and get to a = point where everyone would consider sending network layer addresses in = application messages a bad practice regardless of whether it works or = not?

    On 8 Nov 2015 at 06:26:10, Lorenzo = Colitti (lorenzo@google.com) wrote:

    On Fri, Nov 6, 2015 at 7:08 PM, Nick = Hilliard <nick@foobar.org> wrote:
    On = 06/11/2015 00:20, Lorenzo Colitti wrote:
    It = breaks any application that requires that the application know its = source address. Examples are SIP, FTP, audio/video chat, = etc.
    your argument is the wrong way around: = some protocols deliberately introduce layering violations by demanding = that transport identifier information is encoded at the application = layer.  Transport identifier translation merely shows up this = brokenness.  The brokenness is not with the translation mechanism = but with the higher level protocols.

    Nope. Those protocols aren't broken, = they worked fine for years until NAT arrived and broke them. They = still work fine on networks that operate the way the Internet was = originally designed with end-to-end = connectivity.
    _______________________________________________ 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

    = --Apple-Mail=_0EBE2BDC-BB3A-4FEE-9BBC-846CEF2F93B7-- From nobody Thu Nov 12 10:01: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 2044F1B2BBF for ; Thu, 12 Nov 2015 10:01:52 -0800 (PST) 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 hEAc3yLO5agB for ; Thu, 12 Nov 2015 10:01:50 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 845CF1B2BBD for ; Thu, 12 Nov 2015 10:01:50 -0800 (PST) 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 tACHxbKP013200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 09:59:40 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <563F3AC3.6000205@foobar.org> Date: Thu, 12 Nov 2015 09:59:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:01:52 -0000 > On Nov 8, 2015, at 04:06 , Nick Hilliard wrote: >=20 > On 08/11/2015 05:25, Lorenzo Colitti wrote: >> On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard = wrote: >>> On 06/11/2015 00:20, Lorenzo Colitti wrote: >>>> It breaks any application that requires that the application = know its >>>> source address. Examples are SIP, FTP, audio/video chat, etc. >> your argument is the wrong way around: some protocols deliberately >> introduce layering violations by demanding that transport = identifier >> information is encoded at the application layer. Transport = identifier >> translation merely shows up this brokenness. The brokenness is = not >> with the translation mechanism but with the higher level = protocols. >>=20 >> Nope. Those protocols aren't broken, they worked fine for years until = NAT >> arrived and broke them. They still work fine on networks that operate = the >> way the Internet was originally designed with end-to-end = connectivity. >=20 > NAT predates both sip and the vast majority of other protocols which = encode > inline transport layer identifiers (skype, other chat, etc). >=20 > Also, I hope you're not arguing that protocol layering violations are > acceptable from a design point of view. You realize that from this point of perspective, your argument could be = seen as claiming that DNS which provides L3 information over an L4+ protocol is a layering violation. What would you use instead? Similarly, the argument can be made with website redirects and embedded URLs, even if they contain host names rather than L3 and L4 identifiers directly. You can dismiss this as reductio ad absurdum, but in reality, the = principle of layering violation as a practical solution to problems that don=E2=80=99= t really have a solution without involving some level of layering violation remains. It=E2=80=99s utterly impossible to provide any kind of out of band = signaling or solution for session setup/teardown without involving some form of layering = violation. > You're correct that ftp predates nat but having said that, its = layering > violations were recognised from the earliest days of the internet as = being > atrocious protocol design because of the problems they caused. Yet, despite all of this recognition, nobody ever really solved them. = The only difference introduced with PASV FTP was the ability to reverse the = initiation direction of the OOB channel. Has anyone developed a general file transfer mechanism that doesn=E2=80=99= t involve layering violations? SFTP, SCP, etc. don=E2=80=99t qualify=E2=80=A6 They use the same kind of = layering violation, they just hide it inside of tunnels inside of the SSH protocol. The file transfers in the various chat applications that I=E2=80=99m = aware of also use some form of what amounts to the tunneled layering violations similar to SSH, = regardless of their use of encryption or not. TFTP has all of the same issues as FTP. Is there an alternative to SIP that doesn=E2=80=99t require layering = violations? You can move the layering violations around, but you can=E2=80=99t = eliminate them completely. Owen From nobody Thu Nov 12 10:06: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 5DB001B2BEB for ; Thu, 12 Nov 2015 10:06:18 -0800 (PST) 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 4A_NSOz4hY0q for ; Thu, 12 Nov 2015 10:06:16 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 128111B2BE5 for ; Thu, 12 Nov 2015 10:06:16 -0800 (PST) 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 tACI55xH014988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:05:06 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <563FA84C.7030601@si6networks.com> Date: Thu, 12 Nov 2015 10:05:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <28EECB50-9F5F-4F47-95EB-86BD5E9A9C72@delong.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:06:18 -0000 >> They still work fine on networks that >> operate the way the Internet was originally designed with end-to-end >> connectivity. >=20 > not sure what you mean by "end-to-end" connectivity. I won=E2=80=99t speak for Lorenzo, but what I mean when I talk about = =E2=80=9Cend-to-end=E2=80=9D is the situation where the L3 packet that leaves the origin host arrives at the destination host without being modified except for certain fields intended to be modified in flight. (Namely TTL/Hop Count, L2 and lower layer fields, etc.). Certainly the L3 and higher layer identifiers are = not to be tampered with in flight. If they are, then that is a clear layering violation of the worst = possible type. > But if you refer to the property where there is no filtering between = the > aforementioned two devices, I wonder how many of such networks are > interconnected via the public Internet. I don=E2=80=99t think that=E2=80=99s what is meant in this context, but = I=E2=80=99ll leave it to Lorenzo to speak for himself. > ... that train has left ages ago. Filtering is not the same as packet mutilation. Deliver the packet or don=E2=80=99t deliver the packet according to your = policies on your network, fine. Editing the packet to alter its behavior in flight, OTOH, is one of the = worst kinds of network skulduggery IMHO. Owen From nobody Thu Nov 12 10: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 1CAE71B2C4E for ; Thu, 12 Nov 2015 10:17:12 -0800 (PST) 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 RKljhF1BjghT for ; Thu, 12 Nov 2015 10:17:07 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1453B1B2C4D for ; Thu, 12 Nov 2015 10:17:07 -0800 (PST) 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 tACIG4Kh018126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:16:06 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Thu, 12 Nov 2015 10:16:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06597CFD-BCAF-402A-A743-E9CC33B17796@delong.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563F3AC3.6000205@foobar.org> <563FC756.5090906@foobar.org> <56410A97.7050508@isi.edu> To: Philip Homburg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:17:12 -0000 > On Nov 10, 2015, at 03:50 , Philip Homburg = wrote: >=20 >>> Call me old fashioned, but what NAT breaks is not what is = traditionally >>> called a protocol layering violation. (The TCP checksum is one of = the classical >>> layering violations in the IP protocol stack) >=20 >> Given that a NAT breaks the TCP checksum (which depends on the IP >> pseudoheader and TCP header) and thus has to recalculate it, wouldn't >> that be proof that a NAT breaks what you consider protocol layer = violation? >=20 > If a layering violation like in TCP gets broken by NAT, then I = consider > that fair game. I.e., such layering violations should not exist in the > first place, so it is TCP that is broken. >=20 >> On 11/8/2015 3:08 PM, Philip Homburg wrote: >>>> ddns is also a layering violation because it makes an assumption at = layer 7 >>>>> about what's going on in layer 3. >>>=20 >>> Again, we have to use transport layer identifiers, because the IP = stack >>> doesn't define anything else. >>=20 >> Note that some protocols do define other identifiers, e.g., HTTP uses = URNs. >>=20 >> We often use L4 identifiers when there are no other upper layer >> end-to-end identifiers available, e.g., the app uses 128.9.160.161:80 >> because that's what the user provided. The fact that these are L4 (or >> L3) identifiers is true only because the addresses got passed down >> through the stack - which is definitely not layer violation. >=20 > Commonly used URNs rely on transport layer addresses (which are broken = by > NAT) or DNS, which is also broken by NAT (in some cases). >=20 > One way of looking at NAT is that it deals with a failure of IP = addressing. > In the case of IPv4, with the fact that 32 bits is just not enough. >=20 > And in IPv6 most likely in cases where the locator/identifier split is = not > in the architecture.=20 >=20 > I.e. NAT breaks the model because it is a fix where the model is = broken. Alternatively, NAT is an alternative form of brokenness where the = =E2=80=9Ccure=E2=80=9D is often (usually) worse than the disease. Owen From nobody Thu Nov 12 10:23: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 410F11B2C9E for ; Thu, 12 Nov 2015 10:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 Wm3sejon4rMu for ; Thu, 12 Nov 2015 10:23:28 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 657F01B2C9D for ; Thu, 12 Nov 2015 10:23:28 -0800 (PST) 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 tACILLBu019865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:21:21 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_DB4D084A-67BC-47F3-833F-FE89DC6CEF7D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Thu, 12 Nov 2015 10:21:20 -0800 Message-Id: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:23:30 -0000 --Apple-Mail=_DB4D084A-67BC-47F3-833F-FE89DC6CEF7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) = wrote: >=20 >>>=20 >>> What you refer to has to do with the diode-firewall thing (which is = a side effect in nat, and that folks are replicating in ipv6 by = deploying a diode firewall where you currently have a nat box). = Obviously, if your policy is that you don't want incoming connections, = and i have the same policy then, unfortunately, we have to talk to a = third party. >> Nope. It is much easier to establish a connection across a diode = firewall than to establish one across a NAT. In the former case, all the = endpoints need to do is send each other packets at about the same time. = In the latter, they need to implement NAT traversal via relays. >=20 >=20 > It is only 'slightly' easier... Because guessing the TCP sequence = number of the other party... Well good luck :-) With a diode firewall, you don=E2=80=99t have to guess. Most diode = firewalls don=E2=80=99t look at TCP sequence numbers actively. They look = only at the L3 and L4 identifiers to determine state. Some look at SYN bits and toss SYN packets going in the wrong direction, = but most just look for an ACK bit. Nonetheless, it=E2=80=99s also much easier because a diode firewall can = easily be given an exception to permit a particular flow or the = initiation of a class of flows to a particular protected host or set of = hosts. In the case of a NAT, however (more specifically a NAPT), it is not = possible to program multiple port 80 terminations to land on different = hosts behind the NAT. In short, without NAT, flows which are desired can be permitted. With = NAT, this is much more difficult and in many cases, impossible. I retain my perspective that one of the worst and most ultimate forms of = layering violation is for a forwarding system not residing on either of = the end-hosts in a session to impersonate an end-host and mutilate = unexpected portions of the datagram in flight. Owen --Apple-Mail=_DB4D084A-67BC-47F3-833F-FE89DC6CEF7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <evyncke@cisco.com> = wrote:


    What you refer to has to do with the diode-firewall thing (which is a = side effect in nat, and that folks are replicating in ipv6 by deploying = a diode firewall where you currently have a nat box). Obviously, if your = policy is that you don't want incoming connections, and i have the same policy then, unfortunately, we have to talk to a = third party.
    Nope. It is much easier to establish a connection across = a diode firewall than to establish one across a NAT. In the former case, = all the endpoints need to do is send each other packets at about the = same time. In the latter, they need to implement NAT traversal via relays.

    It is only 'slightly' easier... Because guessing the TCP = sequence number of the other party... Well good luck = :-)

    With a diode = firewall, you don=E2=80=99t have to guess. Most diode firewalls don=E2=80=99= t look at TCP sequence numbers actively. They look only at the L3 and L4 = identifiers to determine state.
    Some look at SYN bits and toss = SYN packets going in the wrong direction, but most just look for an ACK = bit.

    Nonetheless, it=E2=80=99s also = much easier because a diode firewall can easily be given an exception to = permit a particular flow or the initiation of a class of flows to a = particular protected host or set of hosts.

    In the case of a NAT, however (more specifically a = NAPT), it is not possible to program multiple port 80 terminations to = land on different hosts behind the NAT.

    In short, without NAT, flows which are desired can = be permitted. With NAT, this is much more difficult and in many cases, = impossible.

    I retain my perspective = that one of the worst and most ultimate forms of layering violation is = for a forwarding system not residing on either of the end-hosts in a = session to impersonate an end-host and mutilate unexpected portions of = the datagram in flight.

    Owen

    = --Apple-Mail=_DB4D084A-67BC-47F3-833F-FE89DC6CEF7D-- From nobody Thu Nov 12 10:30: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 2D1441B2D49 for ; Thu, 12 Nov 2015 10:30:46 -0800 (PST) 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 MKkX7Q5vxYkj for ; Thu, 12 Nov 2015 10:30:45 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48B1B2BF3 for ; Thu, 12 Nov 2015 10:30:44 -0800 (PST) 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 tACITekS020995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:29:41 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151106.063106.74659839.sthaug@nethelp.no> Date: Thu, 12 Nov 2015 10:29:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:30:46 -0000 > On Nov 5, 2015, at 21:31 , sthaug@nethelp.no wrote: >=20 >> That makes it sound like IETF is not "endorsing" NPT66, as opposed to=20= >> actively recommending that people don't use it. I'm with Lorenzo here = - =20 >> I would prefer very strong language in the form of "deployment of = NPT66 is=20 >> concidered harmful" or "we strongly recommend against the use of = NPT66". >=20 > Okay, one more operator then. I want to have NPT66 (and ULA) available > in the toolbox. >=20 > Steinar Haug, AS 2116 A statement that we strongly recommend against the use of it does not = take it out of your toolbox. It just says that it=E2=80=99s a dangerous tool = and that when you use it to drive a nail through your thumb, you can=E2=80=99t say we = didn=E2=80=99t warn you. Owen From nobody Thu Nov 12 10:34: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 6494E1B2DDD for ; Thu, 12 Nov 2015 10:34:38 -0800 (PST) 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 fLUpHJHW5ZUz for ; Thu, 12 Nov 2015 10:34:37 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1298E1B2DDF for ; Thu, 12 Nov 2015 10:34:37 -0800 (PST) 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 tACIWZkx021579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:32:35 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151106.081425.74651560.sthaug@nethelp.no> Date: Thu, 12 Nov 2015 10:32:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:34:38 -0000 > On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: >=20 >>> Okay, one more operator then. I want to have NPT66 (and ULA) = available >>> in the toolbox. >>>=20 >>=20 >> Why would a recommendation against it prevent you using it on your = network >> if you wanted to? How is the IETF recommending against it stopping = you from >> using it? >=20 > I would of course carefully consider the alternatives. But you're = right > that it probably wouldn't stop me if I concluded that NPT66 was the = best > solution. >=20 >> A recommendation not to do something is for people who fundamentally = don't >> know better. >=20 > Which leaves the people who would like to be provider independent in a > slightly difficult situation. Recommend /48 PI for everybody? Still = too > difficult to acquire for many companies, and with significant scaling > problems if enough people start using it. NPT66? "Harmful", as some > people here would like the documents to say. How is a /48 PI hard to acquire? Where? I know it=E2=80=99s utterly simple in the ARIN region. To the best of my knowledge, it is fairly simple in RIPE. It=E2=80=99s utterly easy in APNIC, though somewhat expensive IMHO. I believe it is fairly easy in LACNIC. To the best of my knowledge, it is not difficult or expensive in = AfriNIC. Please explain exactly what circumstances make it too difficult for any = company to acquire a /48 PI as I would consider this a brokenness in the = relevant RIR=E2=80=99s policy and would happily work to resolve the issue. Owen From nobody Thu Nov 12 10:39: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 A2F1C1B2E28 for ; Thu, 12 Nov 2015 10:39:36 -0800 (PST) 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 IkaR3tQyE2fu for ; Thu, 12 Nov 2015 10:39:35 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id BC1651B2E2A for ; Thu, 12 Nov 2015 10:39:33 -0800 (PST) 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 tACIcOhh022140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 10:38:25 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <563C7DC2.3010704@foobar.org> Date: Thu, 12 Nov 2015 10:38:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563BEBCE.40204@gmail.com> <20151106072616.GS70452@Space.Net> <563C7DC2.3010704@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:39:36 -0000 > On Nov 6, 2015, at 02:15 , Nick Hilliard wrote: >=20 > On 06/11/2015 07:26, Gert Doering wrote: >> On Fri, Nov 06, 2015 at 01:31:02AM +0000, Howard, Lee wrote: >>> Proposed text: >>> ... it does have significant implications to applications, as = documented >>> in [RFC6296] Section 5, which may cause some applications to break. >>>=20 >>> Thus this document does not recommend the use of ULA+NPTv6. >>=20 >> This I can perfectly agree to - it's a different message ("understand=20= >> well what you do if you insist on going there"), and clear enough. >=20 > this is verging on "delenda est carthago" territory. Given the persistent and pestilent nature of NAT externalizing costs = onto other parties not choosing to use it, I think that is a perfectly = valid approach at this time. Let us now go forth and destroy Carthage (remove NAT from the public = internet) as to eliminate this problem from our collective future. If you want to use NAT in whatever form on your own network in a manner = that does not externalize costs to software vendors, other providers, or = pollute the internet with false identifiers, then by all means, do as = you wish. If your use of NAT does not fall within those limitations, then, indeed, = it should be destroyed. Owen From nobody Thu Nov 12 10:46: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 1A3121B2DEE for ; Thu, 12 Nov 2015 10:46:18 -0800 (PST) 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 xmtrsH8sWj6L for ; Thu, 12 Nov 2015 10:46:16 -0800 (PST) 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 196A11B2E65 for ; Thu, 12 Nov 2015 10:46:15 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CD8DE60A56 for ; Thu, 12 Nov 2015 19:46:13 +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 9A34460915 for ; Thu, 12 Nov 2015 19:46:13 +0100 (CET) Received: (qmail 34734 invoked by uid 1007); 12 Nov 2015 19:46:13 +0100 Date: Thu, 12 Nov 2015 19:46:13 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151112184613.GZ89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:46:18 -0000 Hi, On Thu, Nov 12, 2015 at 10:32:34AM -0800, Owen DeLong wrote: > How is a /48 PI hard to acquire? Where? > > I know it???s utterly simple in the ARIN region. > To the best of my knowledge, it is fairly simple in RIPE. > It???s utterly easy in APNIC, though somewhat expensive IMHO. > I believe it is fairly easy in LACNIC. > To the best of my knowledge, it is not difficult or expensive in AfriNIC. > > Please explain exactly what circumstances make it too difficult for any company > to acquire a /48 PI as I would consider this a brokenness in the relevant RIR???s > policy and would happily work to resolve the issue. The IETF world does not (at least "should not") revolve around "companies", and I wish you good luck finding a SoHo ISP that will route your PI space. IOW, having a /48 PI space is nice, but if that does not have Internet connectivity, how exactly does it differ from ULA? 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 Nov 12 10:57: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 87FA91B30B1 for ; Thu, 12 Nov 2015 10:57:10 -0800 (PST) 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 0khVYmad4J-8 for ; Thu, 12 Nov 2015 10:57:08 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 12AFF1B30A9 for ; Thu, 12 Nov 2015 10:57:08 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Zwx3Q-0000CgC; Thu, 12 Nov 2015 19:57:04 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> In-reply-to: Your message of "Thu, 12 Nov 2015 10:32:34 -0800 ." <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> Date: Thu, 12 Nov 2015 19:56:57 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 18:57:10 -0000 > How is a /48 PI hard to acquire? Where? > > I know its utterly simple in the ARIN region. To the best of my > knowledge, it is fairly simple in RIPE. Its utterly easy in APNIC, > though somewhat expensive IMHO. I believe it is fairly easy in > LACNIC. To the best of my knowledge, it is not difficult or > expensive in AfriNIC. > > Please explain exactly what circumstances make it too difficult > for any company to acquire a /48 PI as I would consider this a > brokenness in the relevant RIRs policy and would happily work to > resolve the issue. Yes, it is easy to get a /48 PI and then what? Suppose we have small business that moderately happy with poor man's multihoming using two consumer ISPs (say DSL and cable) and a NAT box. Now we advice that company to use a /48 PI for IPv6. I'm not even aware of any consumer ISP offering routed PI space as a service, I probably wouldn't trust my local cable company to announce my PI space. So what does that cost in your part of the world? My guess is that if one vendor suggests using PI space and another NAT66 then just about any business will pick NAT66. I think it is safe assume that any company that doesn't have IPv4 PI space today will not get IPv6 PI space. Then there is the obvious scaling problem. If we would insist that every small business in the world would get (and announce) PI space then the operators would call us nuts. (IPv6 poor man's multi homing can be done using by manipulating the perference values of the PA prefixes, but there is not even an RFC detailing how that should be done, let alone products on the market) From nobody Thu Nov 12 11:37: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 3A9EB1B32AF for ; Thu, 12 Nov 2015 11:37:11 -0800 (PST) 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 Ily5sfKMIAWS for ; Thu, 12 Nov 2015 11:37:09 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9261B32AE for ; Thu, 12 Nov 2015 11:37:08 -0800 (PST) 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 tACJa6kU032053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 11:36:07 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151112184613.GZ89490@Space.Net> Date: Thu, 12 Nov 2015 11:36:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 19:37:11 -0000 > On Nov 12, 2015, at 10:46 , Gert Doering wrote: >=20 > Hi, >=20 > On Thu, Nov 12, 2015 at 10:32:34AM -0800, Owen DeLong wrote: >> How is a /48 PI hard to acquire? Where? >>=20 >> I know it???s utterly simple in the ARIN region. >> To the best of my knowledge, it is fairly simple in RIPE. >> It???s utterly easy in APNIC, though somewhat expensive IMHO. >> I believe it is fairly easy in LACNIC. >> To the best of my knowledge, it is not difficult or expensive in = AfriNIC. >>=20 >> Please explain exactly what circumstances make it too difficult for = any company >> to acquire a /48 PI as I would consider this a brokenness in the = relevant RIR???s >> policy and would happily work to resolve the issue. >=20 > The IETF world does not (at least "should not") revolve around = "companies", > and I wish you good luck finding a SoHo ISP that will route your PI = space. >=20 > IOW, having a /48 PI space is nice, but if that does not have Internet > connectivity, how exactly does it differ from ULA? 2620:0:930::/48 Q.E.D. Owen From nobody Thu Nov 12 11:43: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 823671B32D2 for ; Thu, 12 Nov 2015 11:43:32 -0800 (PST) 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 zMjYKub4hFBS for ; Thu, 12 Nov 2015 11:43:30 -0800 (PST) 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 3A9C11B32D1 for ; Thu, 12 Nov 2015 11:43:29 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E53D46010F for ; Thu, 12 Nov 2015 20:43:27 +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 9E94C60A5D for ; Thu, 12 Nov 2015 20:43:27 +0100 (CET) Received: (qmail 37241 invoked by uid 1007); 12 Nov 2015 20:43:27 +0100 Date: Thu, 12 Nov 2015 20:43:27 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151112194327.GA89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrxji9MxLi9YGTOD" Content-Disposition: inline In-Reply-To: <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 19:43:32 -0000 --yrxji9MxLi9YGTOD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: > > The IETF world does not (at least "should not") revolve around "compani= es", > > and I wish you good luck finding a SoHo ISP that will route your PI spa= ce. >=20 > 2620:0:930::/48 This is not a typical SoHo ISP. Try finding one which is not your employer. 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 --yrxji9MxLi9YGTOD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkTr399WwGXkzn/FAQLrdhAAm+iSmxTcSFX7+ULtWWplYA+IndBB7X1r pvgD679rEy2sBsFWfyeMTQy5yQ1BHBA7CfToqRwlFuR03wJLEt83jBEtU6GUQ9NY GtWUq+hob476+7rsA4sqcDoQEiBu8mRf7SMGhbqPC3LZPLCDkLSMHVszO9yoXoSF lUAm64O2wSf0Ks7JVvPdildEuuskOGCMG8rAwyXME4BnAz9xgSm2+5B3Pl+sRAhA V4Lwv51xUO1+uMLrPFuV7t2PEvfqmv6bXV/7XVVpK4RARRrmUUd+0Z/OE8i4TC2a 0SPTyJg5fhImN4E+joMdibYY1QjECBfjNF0rvKESkja7jaUJr2irCj215FkTOLPj YXnAP80akNuk0Pp6gHOuiEPSTO1reTGxD6CoxuNL/xRK4A6f/9/e0dqM5vls/sB+ MgX+p9oqEsGdVEh9kf0oFZeKUQPL2mEVgQq/kHnB16qj+QBSJbNKN5Ki2Un38X2Y KnMW8vD0uzH6kni31tHphq0hN86kAo8kFrT8nZ0cRwlR5GMyBrumLburhTOv/SMO euYFRj6KTlPbQdz/oCIFmsQhS3yBMawd4Hf+O130TtwpG3RlqqcpKK35Uay9rnzL gFnCwtgfIO7kSVWXizF+Vrgc87VEhw+Nd3MGcC+JsVLm7wZOTQkVuclVFlyyQqKo q3m4rhY1AFI= =aw4u -----END PGP SIGNATURE----- --yrxji9MxLi9YGTOD-- From nobody Thu Nov 12 11:53: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 385721B3345 for ; Thu, 12 Nov 2015 11:53:39 -0800 (PST) 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 H5FENOd9OqTu for ; Thu, 12 Nov 2015 11:53:38 -0800 (PST) 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 2B5DB1B3347 for ; Thu, 12 Nov 2015 11:53:38 -0800 (PST) Received: by pacdm15 with SMTP id dm15so74219786pac.3 for ; Thu, 12 Nov 2015 11:53:37 -0800 (PST) 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=1ItawGUV6yJrKP3nFcvPUCaeH2xjGTJCnEy00iCmUgQ=; b=B5DcoDKRRtvGqfwYm1HA0nwPWCutJ+lPVqXDW3Kz7/ceZOtUbOqtUeuzcZXUmoRHkr Sht3lqoEBAHXJoqXBgz+FE1cUfkie/ZicV9Sh2enT9ZOMAkq/KhqclFKYJUKoAp99eT/ 1ZsZLh76Eb0OAI7a2dEcrPpbIiOSEdgXOQIWMNu9NdR7X7n24OG5KaDQayK9lkIu8ER8 /4NvSK1o3RttxzRS5SVEfyyb5jTbfDmnEbrg5+8g6lDETcetOSbA4yN5K97/zKzYvR5T vuYXFG4V5vBxx8K5URa1JqLCFNyi0Rfs4lWwT0VCnpZycr05YMZA/GybxuEu/NTeXuJO m/JQ== X-Received: by 10.68.221.230 with SMTP id qh6mr25769418pbc.32.1447358017877; Thu, 12 Nov 2015 11:53:37 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id cs5sm16236639pbc.15.2015.11.12.11.53.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 11:53:35 -0800 (PST) To: Owen DeLong , sthaug@nethelp.no References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5644EE46.7000805@gmail.com> Date: Fri, 13 Nov 2015 08:53: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: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 12 Nov 2015 19:53:39 -0000 Please let's not pretend we're discussing the ULA draft any more. On 13/11/2015 07:32, Owen DeLong wrote: ... > How is a /48 PI hard to acquire? Where? As others have implied, that isn't the point. The point (and I expect we had this argument on the RRG list some years ago) is that we can't put 10,000,000 /48 entries into BGP. So if we go around encouraging all small enterprises to get a PI prefix we are all doomed. Brian From nobody Thu Nov 12 12:09: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 2F8C81B3420 for ; Thu, 12 Nov 2015 12:09:02 -0800 (PST) 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 G0s2hffJBL0V for ; Thu, 12 Nov 2015 12:09:00 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 8ABBA1B341C for ; Thu, 12 Nov 2015 12:09:00 -0800 (PST) Received: by ykdv3 with SMTP id v3so111517447ykd.0 for ; Thu, 12 Nov 2015 12:08:59 -0800 (PST) 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=40jgmibRRjFhn47szRpq+e88hVskFqmEkI2+b48IJFU=; b=riQ2CiGwb4fUnX4Ho0c3Ufnoai8FryZSfk5ncQYp0+QztzYg+cDukCLZ/MRhcr4QqU qF/Dy6jPg9pUD/I1N6XAOllzolmlAsXhjkLofioRf02SbRNknnwlsTwrYIA2woNlKWYl cknWhDnjgi4c7JEY3sPVTf2GjuxNQOYD6dGg0tTTdtYfwcGWgAcD1mNuF1huQTTRvpKM bSLHuscLqefmJopsDuG2/e+HcyDwcKeU/gbdSXaGna2KRsf/NKw/2cNuSEoXJCJHJJmo GIw6LMKnEwV7PNOGk0ucbaYvp3uXDYIlPx8DllpPvNndJXvsDP1estj98sG2IF/BmZQm icAw== X-Received: by 10.129.55.72 with SMTP id e69mr3658194ywa.260.1447358939713; Thu, 12 Nov 2015 12:08:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.45.198 with HTTP; Thu, 12 Nov 2015 12:08:30 -0800 (PST) In-Reply-To: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> From: Mark Smith Date: Fri, 13 Nov 2015 07:08:30 +1100 Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 20:09:02 -0000 On 13 November 2015 at 05:32, Owen DeLong wrote: > >> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: >> > Please explain exactly what circumstances make it too difficult for any c= ompany > to acquire a /48 PI as I would consider this a brokenness in the relevant= RIR=E2=80=99s > policy and would happily work to resolve the issue. > This was was in part what I was getting getting at when I said that abandoning ULAs would discourage adoption of IPv6. If you're building a small network that either currently isn't and may never be attached to the Internet, you have 3 choices: (a) apply for RIR membership and incur annual RIR costs to get a PI /48 and after some time delay, be able to build your IPv6 network (b) use $free ULA space, and be able to build your IPv6 network right now (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now Option (a) has financial costs and time delays that option (b) doesn't, and if option (b) doesn't exist, then option (c) is the most convenient and timely choice, unless it is essential that IPv6 is used. Option (c) being the most convenient, cost effective and timely option for if (b) isn't available will actually discourage support for IPv6. I think that if (a) was the only choice, it is in effect creating an annual tax or license fee on the use of IPv6 technology, because (in theory) you wouldn't be able to use IPv6 unless you paid an RIR and waited for them to give you your space. Of course, the other choice would be that some people would steal space to use instead to build an IPv6 network, like the documentation prefix. Absence of a local use address space encourages stealing of other address spaces if you don't have time to get a proper one or don't have the financial means or financial incentive to get some. Humans don't incur costs on themselves unless they see or perceive some equivalent benefit. Making something available for "free", in this case a local yet globally unique network address space, significantly lowers the barrier to IPv6 adoption. If you've bought the equipment to build your network, and it comes IPv6 enabled for "free", you can then immediately build an IPv6 network using ULA space. If at a later date a ULA addressed network connects to the Internet they would add PA or PI space to be able to access external destinations, because IPv6 is designed to fully support parallel address spaces (i.e., so having ULAs on your network doesn't automatically imply using NAT66). Regards, Mark. From nobody Thu Nov 12 12:25: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 03C131B339E for ; Thu, 12 Nov 2015 12:25:31 -0800 (PST) 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 tNqJBE8Z0NUa for ; Thu, 12 Nov 2015 12:25:29 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8D41B34EB for ; Thu, 12 Nov 2015 12:25:29 -0800 (PST) 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 tACKOSx6005801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 12:24:28 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151112194327.GA89490@Space.Net> Date: Thu, 12 Nov 2015 12:24:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 20:25:31 -0000 > On Nov 12, 2015, at 11:43 , Gert Doering wrote: >=20 > Hi, >=20 > On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>> The IETF world does not (at least "should not") revolve around = "companies", >>> and I wish you good luck finding a SoHo ISP that will route your PI = space. >>=20 >> 2620:0:930::/48 >=20 > This is not a typical SoHo ISP. >=20 > Try finding one which is not your employer. neither of the upstreams for that address employs me at this time. Admittedly I did use to work for ONE of the two, but anyone can get that = one to route their /48. Owen From nobody Thu Nov 12 13:44: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 EBCFE1B374E for ; Thu, 12 Nov 2015 13:44:50 -0800 (PST) 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 bQRa4FvATCqC for ; Thu, 12 Nov 2015 13:44:49 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3689C1B374A for ; Thu, 12 Nov 2015 13:44:48 -0800 (PST) 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 tACLgjoG019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 13:42:46 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Thu, 12 Nov 2015 13:42:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> To: Mark Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 21:44:51 -0000 > On Nov 12, 2015, at 12:08 , Mark Smith wrote: >=20 > On 13 November 2015 at 05:32, Owen DeLong wrote: >>=20 >>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: >>>=20 > >=20 >> Please explain exactly what circumstances make it too difficult for = any company >> to acquire a /48 PI as I would consider this a brokenness in the = relevant RIR=E2=80=99s >> policy and would happily work to resolve the issue. >>=20 >=20 > This was was in part what I was getting getting at when I said that > abandoning ULAs would discourage adoption of IPv6. >=20 > If you're building a small network that either currently isn't and may > never be attached to the Internet, you have 3 choices: >=20 > (a) apply for RIR membership and incur annual RIR costs to get a PI > /48 and after some time delay, be able to build your IPv6 network >=20 > (b) use $free ULA space, and be able to build your IPv6 network right = now >=20 > (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now >=20 >=20 > Option (a) has financial costs and time delays that option (b) > doesn't, and if option (b) doesn't exist, then option (c) is the most > convenient and timely choice, unless it is essential that IPv6 is > used. Option (c) being the most convenient, cost effective and timely > option for if (b) isn't available will actually discourage support for > IPv6. (d) use whatever string of {32,48,64} bits you want and pretend it=E2=80=99= s an IPv6 prefix. Please explain what benefit (b) offers over (d) in such a case. You=E2=80=99= re going to end up renumbering when you attach to the internet either way. > I think that if (a) was the only choice, it is in effect creating an > annual tax or license fee on the use of IPv6 technology, because (in > theory) you wouldn't be able to use IPv6 unless you paid an RIR and > waited for them to give you your space. Of course, the other choice > would be that some people would steal space to use instead to build an > IPv6 network, like the documentation prefix. Absence of a local use > address space encourages stealing of other address spaces if you don't > have time to get a proper one or don't have the financial means or > financial incentive to get some. I=E2=80=99m all for providing a lower cost alternative to having a = legitimate registry for addresses for smaller users. > Humans don't incur costs on themselves unless they see or perceive > some equivalent benefit. Making something available for "free", in > this case a local yet globally unique network address space, > significantly lowers the barrier to IPv6 adoption. If you've bought > the equipment to build your network, and it comes IPv6 enabled for > "free", you can then immediately build an IPv6 network using ULA > space. Except that ULA isn=E2=80=99t globally unique, it=E2=80=99s just = =E2=80=9Cprobably unique=E2=80=9D for various relatively high values of =E2=80=9Cprobably=E2=80=9D depending on how = you go about choosing your ULA prefix. Were ULA globally unique, you=E2=80=99d have the double = edge sword of: 1. It=E2=80=99s good because it=E2=80=99s free PI address = space. 2. It=E2=80=99s bad because it=E2=80=99s a free end-run = around the RIR policy processes. > If at a later date a ULA addressed network connects to the Internet > they would add PA or PI space to be able to access external > destinations, because IPv6 is designed to fully support parallel > address spaces (i.e., so having ULAs on your network doesn't > automatically imply using NAT66). Except for all the problems previously noted in such installations with = various issues around source address selection, etc. Owen From nobody Thu Nov 12 13:48: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 C11211B377A for ; Thu, 12 Nov 2015 13:48:27 -0800 (PST) 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 hwMeayoxwTir for ; Thu, 12 Nov 2015 13:48:25 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6B01B3777 for ; Thu, 12 Nov 2015 13:48:25 -0800 (PST) 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 3F18A1FCAD0; Thu, 12 Nov 2015 21:48:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2F836160085; Thu, 12 Nov 2015 21:48:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 211F9160084; Thu, 12 Nov 2015 21:48:54 +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 QMIhRHJAT2qu; Thu, 12 Nov 2015 21:48:54 +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 D2BDC160067; Thu, 12 Nov 2015 21:48:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4EDE63C98D83; Fri, 13 Nov 2015 08:48:19 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> In-reply-to: Your message of "Thu, 12 Nov 2015 12:24:27 -0800." <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> Date: Fri, 13 Nov 2015 08:48:19 +1100 Message-Id: <20151112214819.4EDE63C98D83@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 21:48:28 -0000 In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen DeLong write s: > > > On Nov 12, 2015, at 11:43 , Gert Doering wrote: > > > > Hi, > > > > On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: > >>> The IETF world does not (at least "should not") revolve around "companies > ", > >>> and I wish you good luck finding a SoHo ISP that will route your PI space > . > >> > >> 2620:0:930::/48 > > > > This is not a typical SoHo ISP. > > > > Try finding one which is not your employer. > > neither of the upstreams for that address employs me at this time. > > Admittedly I did use to work for ONE of the two, but anyone can get that one > to route their /48. And how many SME's are there in the world? This paper [1] puts the number at 125M MSME world wide. That's 125M routing slots if everyone gets a /48. Mark [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Nov 12 13:59: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 827861B37FF for ; Thu, 12 Nov 2015 13:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 hpYjZdLhDx0y for ; Thu, 12 Nov 2015 13:59:04 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7860B1B37F5 for ; Thu, 12 Nov 2015 13:59:04 -0800 (PST) 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 tACLw3oe020492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 13:58:03 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_85927CF7-EFAD-4A44-A792-56A8B18D039B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151112214819.4EDE63C98D83@rock.dv.isc.org> Date: Thu, 12 Nov 2015 13:58:03 -0800 Message-Id: <770A3D01-D26F-46EE-8B4A-79A8618FD90E@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 21:59:06 -0000 --Apple-Mail=_85927CF7-EFAD-4A44-A792-56A8B18D039B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have to solve the scaling problem of how we currently do routing at = some point no matter what. ULA+NPT as a workaround is an extremely poor choice IMHO. Owen > On Nov 12, 2015, at 13:48 , Mark Andrews wrote: >=20 >=20 > In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com = >, Owen DeLong = write > s: >>=20 >>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: >>>=20 >>> Hi, >>>=20 >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>>>> The IETF world does not (at least "should not") revolve around = "companies >> ", >>>>> and I wish you good luck finding a SoHo ISP that will route your = PI space >> . >>>>=20 >>>> 2620:0:930::/48 >>>=20 >>> This is not a typical SoHo ISP. >>>=20 >>> Try finding one which is not your employer. >>=20 >> neither of the upstreams for that address employs me at this time. >>=20 >> Admittedly I did use to work for ONE of the two, but anyone can get = that one=20 >> to route their /48. >=20 > And how many SME's are there in the world? This paper [1] puts the > number at 125M MSME world wide. That's 125M routing slots if > everyone gets a /48. >=20 > Mark >=20 > [1] = http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-C= I-AnalysisNote.pdf?MOD=3DAJPERES = >=20 >> Owen >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops = > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org = --Apple-Mail=_85927CF7-EFAD-4A44-A792-56A8B18D039B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We have to solve the scaling problem of how we currently do = routing at some point no matter what.

    ULA+NPT as a workaround is an extremely = poor choice IMHO.

    Owen

    On Nov 12, 2015, at 13:48 , = Mark Andrews <marka@isc.org> wrote:


    In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen DeLong write
    s:

    On Nov 12, 2015, at 11:43 , Gert Doering <gert@space.net> = wrote:

    Hi,

    On = Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote:
    The IETF world does not (at least "should not") revolve = around "companies
    ",
    and I wish you good luck = finding a SoHo ISP that will route your PI space
    .

    2620:0:930::/48

    This is not a typical SoHo ISP.

    Try finding one which is not your employer.

    neither of the upstreams for that = address employs me at this time.

    Admittedly = I did use to work for ONE of the two, but anyone can get that one 
    to route = their /48.

    And how many SME's are = there in the world?  This paper [1] puts the
    number at 125M MSME world wide.  That's = 125M routing slots if
    everyone gets a = /48.

    Mark

    [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b= 6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES

    Owen

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

    = --Apple-Mail=_85927CF7-EFAD-4A44-A792-56A8B18D039B-- From nobody Thu Nov 12 13:59: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 BD6561B3812 for ; Thu, 12 Nov 2015 13:59:56 -0800 (PST) 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 PCgukzVvb9IN for ; Thu, 12 Nov 2015 13:59:51 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 2785D1B380F for ; Thu, 12 Nov 2015 13:59:50 -0800 (PST) Received: (qmail 40357 invoked from network); 12 Nov 2015 21:59:49 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Nov 2015 21:59:49 -0000 Date: Thu, 12 Nov 2015 22:59:49 +0100 (CET) Message-Id: <20151112.225949.74718464.sthaug@nethelp.no> To: owen@delong.com From: sthaug@nethelp.no In-Reply-To: <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> References: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 21:59:56 -0000 > > If you're building a small network that either currently isn't and may > > never be attached to the Internet, you have 3 choices: > > > > (a) apply for RIR membership and incur annual RIR costs to get a PI > > /48 and after some time delay, be able to build your IPv6 network > > > > (b) use $free ULA space, and be able to build your IPv6 network right now > > > > (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now > > > > > > Option (a) has financial costs and time delays that option (b) > > doesn't, and if option (b) doesn't exist, then option (c) is the most > > convenient and timely choice, unless it is essential that IPv6 is > > used. Option (c) being the most convenient, cost effective and timely > > option for if (b) isn't available will actually discourage support for > > IPv6. > > (d) use whatever string of {32,48,64} bits you want and pretend it$,1ry(Bs > an IPv6 prefix. > > Please explain what benefit (b) offers over (d) in such a case. You$,1ry(Bre going > to end up renumbering when you attach to the internet either way. Option b lets you use NPT66 to attach to the Internet without renumbering. Option d may or may not let you use NPT66 to attach to the Internet without renumbering - depending on whether the IPv6 address you just grabbed out of thin air already is in use. So for those willing to consider NPT66, option b has an advantage. Steinar Haug, AS 2116 From nobody Thu Nov 12 14:04: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 525ED1B3844 for ; Thu, 12 Nov 2015 14:04:29 -0800 (PST) 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 SvFwHQN4v7RH for ; Thu, 12 Nov 2015 14:04:28 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C0A431B3843 for ; Thu, 12 Nov 2015 14:04:27 -0800 (PST) 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 tACM2Qo1020736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 14:02:26 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151112.225949.74718464.sthaug@nethelp.no> Date: Thu, 12 Nov 2015 14:02:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> <20151112.225949.74718464.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 22:04:29 -0000 > On Nov 12, 2015, at 13:59 , sthaug@nethelp.no wrote: >=20 >>> If you're building a small network that either currently isn't and = may >>> never be attached to the Internet, you have 3 choices: >>>=20 >>> (a) apply for RIR membership and incur annual RIR costs to get a PI >>> /48 and after some time delay, be able to build your IPv6 network >>>=20 >>> (b) use $free ULA space, and be able to build your IPv6 network = right now >>>=20 >>> (c) use $free RFC1918 IPv4 space, and build an IPv4 network right = now >>>=20 >>>=20 >>> Option (a) has financial costs and time delays that option (b) >>> doesn't, and if option (b) doesn't exist, then option (c) is the = most >>> convenient and timely choice, unless it is essential that IPv6 is >>> used. Option (c) being the most convenient, cost effective and = timely >>> option for if (b) isn't available will actually discourage support = for >>> IPv6. >>=20 >> (d) use whatever string of {32,48,64} bits you want and pretend = it=EF=BF=BD$,1rys >> an IPv6 prefix. >>=20 >> Please explain what benefit (b) offers over (d) in such a case. = You=EF=BF=BD$,1ryre going >> to end up renumbering when you attach to the internet either way. >=20 > Option b lets you use NPT66 to attach to the Internet without > renumbering. >=20 > Option d may or may not let you use NPT66 to attach to the Internet > without renumbering - depending on whether the IPv6 address you just > grabbed out of thin air already is in use. It=E2=80=99s relatively easy to safely grab addresses that will not be = in use for the foreseeable future using (d). > So for those willing to consider NPT66, option b has an advantage. And for those, shame on them for the tendency this has to create = uncontrolled costs for other users of the internet. This is a form of the toxic polluter business model. Owen From nobody Thu Nov 12 14:53: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 9534D1B39E3 for ; Thu, 12 Nov 2015 14:53:16 -0800 (PST) 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 N00dTKSbCyuI for ; Thu, 12 Nov 2015 14:53:14 -0800 (PST) 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 77BB91B39E2 for ; Thu, 12 Nov 2015 14:53:14 -0800 (PST) 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 61BF61FCAB3; Thu, 12 Nov 2015 22:53:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7F097160067; Thu, 12 Nov 2015 22:53:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6E38D160084; Thu, 12 Nov 2015 22:53:42 +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 MnJLOzOunDTM; Thu, 12 Nov 2015 22:53:42 +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 F2E85160067; Thu, 12 Nov 2015 22:53:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BBA8A3C99209; Fri, 13 Nov 2015 09:53:06 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> In-reply-to: Your message of "Thu, 12 Nov 2015 13:42:45 -0800." <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> Date: Fri, 13 Nov 2015 09:53:06 +1100 Message-Id: <20151112225306.BBA8A3C99209@rock.dv.isc.org> Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 12 Nov 2015 22:53:16 -0000 In message <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>, Owen DeLong write s: > > > On Nov 12, 2015, at 12:08 , Mark Smith wrote: > > > > On 13 November 2015 at 05:32, Owen DeLong wrote: > >> > >>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: > >>> > > >> > >> Please explain exactly what circumstances make it too difficult for > any company > >> to acquire a /48 PI as I would consider this a brokenness in the > relevant RIRs > >> policy and would happily work to resolve the issue. > >> > > > > This was was in part what I was getting getting at when I said that > > abandoning ULAs would discourage adoption of IPv6. > > > > If you're building a small network that either currently isn't and may > > never be attached to the Internet, you have 3 choices: > > > > (a) apply for RIR membership and incur annual RIR costs to get a PI > > /48 and after some time delay, be able to build your IPv6 network > > > > (b) use $free ULA space, and be able to build your IPv6 network right > now > > > > (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now > > > > > > Option (a) has financial costs and time delays that option (b) > > doesn't, and if option (b) doesn't exist, then option (c) is the most > > convenient and timely choice, unless it is essential that IPv6 is > > used. Option (c) being the most convenient, cost effective and timely > > option for if (b) isn't available will actually discourage support for > > IPv6. > > (d) use whatever string of {32,48,64} bits you want and pretend its > an IPv6 prefix. > > Please explain what benefit (b) offers over (d) in such a case. Youre > going to end up renumbering when you attach to the internet either way. Renumbering in IPv6 is not the same as renumbering in IPv4. In this case you are just adding a prefix. You don't stop using the ULA addresses in (b). For (d) you need to remove the addresses because you don't know what you are colliding with. Additionally we have deployed technology for nodes to update their addresses in the DNS which deals with most of the renumber problem. A 1 page BCP which says to do what Apple and various router vendors have been doing for years updating the DNS should be enough to get the rest to do this. > > I think that if (a) was the only choice, it is in effect creating an > > annual tax or license fee on the use of IPv6 technology, because (in > > theory) you wouldn't be able to use IPv6 unless you paid an RIR and > > waited for them to give you your space. Of course, the other choice > > would be that some people would steal space to use instead to build an > > IPv6 network, like the documentation prefix. Absence of a local use > > address space encourages stealing of other address spaces if you don't > > have time to get a proper one or don't have the financial means or > > financial incentive to get some. > > Im all for providing a lower cost alternative to having a legitimate > registry for addresses for smaller users. > > > Humans don't incur costs on themselves unless they see or perceive > > some equivalent benefit. Making something available for "free", in > > this case a local yet globally unique network address space, > > significantly lowers the barrier to IPv6 adoption. If you've bought > > the equipment to build your network, and it comes IPv6 enabled for > > "free", you can then immediately build an IPv6 network using ULA > > space. > > Except that ULA isnt globally unique, its just probably unique for various > relatively high values of probably depending on how you go about choosing > your ULA prefix. Were ULA globally unique, youd have the double edge sword > of: > > 1. Its good because its free PI address space. > 2. Its bad because its a free end-run around the RIR policy > processes. And that matters how? If you happen to learn a remote ULA address and actually use it the border router should block the packet and send back a ICMP administrively prohibited unreachable. If there is a ULA prefix collision you still have to match the rest of the address which is highly unlikely. Subnet collisions in this case are likely but not the full address. > > If at a later date a ULA addressed network connects to the Internet > > they would add PA or PI space to be able to access external > > destinations, because IPv6 is designed to fully support parallel > > address spaces (i.e., so having ULAs on your network doesn't > > automatically imply using NAT66). > > Except for all the problems previously noted in such installations with > various issues around source address selection, etc. Which in practice does not exist. I've run networks with ULA + PA locally and *never* seen a issue due to address selection. Longest match takes care of that for the older machines (0010 vs 1111). Newer machines know about ULA so have different address match rules which deal with ULA address leaks. Properly configuring the border routers to return ICMPv6 administrively prohibited for attempts to send a packet outside the site using a address from the ULA prefix deals with the rest. > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Nov 12 15:50: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 42FFA1B3D29 for ; Thu, 12 Nov 2015 15:50:22 -0800 (PST) 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 W3Hd9z7kptun for ; Thu, 12 Nov 2015 15:50:20 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 977021B3D28 for ; Thu, 12 Nov 2015 15:50:20 -0800 (PST) Received: by padhx2 with SMTP id hx2so79943986pad.1 for ; Thu, 12 Nov 2015 15:50:20 -0800 (PST) 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=QvVf8jvQ6dXLH3htBkDpobL2idDJWQ+s6LNPlyqJIHc=; b=rrVwLe24VZ5wuqbiQrL57AhkbNQ4YfPvXY7ksT0RmJOM7toXs9jmreT8iJSLNC7X35 KSz+gyuqtrRrV9QsFgLWM/i/2XM1DJgGLgsYnF2DOgux2AnSvJQQsLAMGvbW0tgsMady EEw9OYKNb6lxUj+2Igk7vU2UH7FFH3EwBnfaRhXHA8VgGeVgS++KClaghAlr17sjIPV7 EDWwtFlUXcQcWHVCD/knQs4T6MVQ16VYd0NLBGN/FrpNkY5biodw+k8K6VFHLWpcEXDN 74km28xS/1kbLgK9lcNAWR7I7ImCpe0gUXRKq3jPIcPQOXpI84SevRg06r1nfE/sMDT9 B0sw== X-Received: by 10.66.102.101 with SMTP id fn5mr27722616pab.66.1447372220253; Thu, 12 Nov 2015 15:50:20 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id qd2sm16735123pbb.68.2015.11.12.15.50.17 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 15:50:19 -0800 (PST) To: v6ops@ietf.org References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <564525C2.2080508@gmail.com> Date: Fri, 13 Nov 2015 12:50:26 +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: <20151112214819.4EDE63C98D83@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] PI heresy 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, 12 Nov 2015 23:50:22 -0000 On 13/11/2015 10:48, Mark Andrews wrote: > > In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen DeLong write > s: >> >>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: >>> >>> Hi, >>> >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>>>> The IETF world does not (at least "should not") revolve around "companies >> ", >>>>> and I wish you good luck finding a SoHo ISP that will route your PI space >> . >>>> >>>> 2620:0:930::/48 >>> >>> This is not a typical SoHo ISP. >>> >>> Try finding one which is not your employer. >> >> neither of the upstreams for that address employs me at this time. >> >> Admittedly I did use to work for ONE of the two, but anyone can get that one >> to route their /48. > > And how many SME's are there in the world? This paper [1] puts the > number at 125M MSME world wide. That's 125M routing slots if > everyone gets a /48. Thanks for that reference. My estimate of 10M was based on some hand-waving arguments about how many SMEs might seriously want to be multihomed; IMHO most of them will be perfectly happy with PA addressing because they will have anything that needs a stable address hosted anyway. Most SOHOs just don't care, and get renumbered without knowing it after power fails etc. Homenet takes this as a given, of course. Brian > > Mark > > [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES > >> Owen >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 12 16:03: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 74E1D1B3D7D for ; Thu, 12 Nov 2015 16:03:41 -0800 (PST) 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 Bse7hkFpU6Mx for ; Thu, 12 Nov 2015 16:03:39 -0800 (PST) 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 50F851B3D7C for ; Thu, 12 Nov 2015 16:03:39 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:95b3:43ec:1b43:a0b9]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tAD03aPq066801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Nov 2015 00:03:37 GMT (envelope-from joelja@bogus.com) To: Brian E Carpenter , v6ops@ietf.org References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> From: joel jaeggli Message-ID: <564528D7.40507@bogus.com> Date: Thu, 12 Nov 2015 16:03:35 -0800 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: <564525C2.2080508@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LajtsGeQqttSTEkIGJj3Kf2J6SJb04Pds" Archived-At: Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 00:03:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LajtsGeQqttSTEkIGJj3Kf2J6SJb04Pds Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/12/15 3:50 PM, Brian E Carpenter wrote: > On 13/11/2015 10:48, Mark Andrews wrote: >> >> In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen DeL= ong write >> s: >>> >>>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>>>>> The IETF world does not (at least "should not") revolve around "co= mpanies >>> ", >>>>>> and I wish you good luck finding a SoHo ISP that will route your P= I space >>> . >>>>> >>>>> 2620:0:930::/48 >>>> >>>> This is not a typical SoHo ISP. >>>> >>>> Try finding one which is not your employer. >>> >>> neither of the upstreams for that address employs me at this time. >>> >>> Admittedly I did use to work for ONE of the two, but anyone can get t= hat one=20 >>> to route their /48. >> >> And how many SME's are there in the world? This paper [1] puts the >> number at 125M MSME world wide. That's 125M routing slots if >> everyone gets a /48. >=20 > Thanks for that reference. My estimate of 10M was based on some hand-wa= ving > arguments about how many SMEs might seriously want to be multihomed; IM= HO > most of them will be perfectly happy with PA addressing because they wi= ll > have anything that needs a stable address hosted anyway. Most SOHOs jus= t don't > care, and get renumbered without knowing it after power fails etc. Home= net > takes this as a given, of course. http://www.cidr-report.org/cgi-bin/plota?file=3D%2fvar%2fdata%2fbgp%2fas2= =2E0%2fbgp-as-count%2etxt&descr=3DUnique%20ASes&ylabel=3DUnique%20ASes&wi= th=3Dstep > Brian >=20 >=20 >> >> Mark >> >> [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d1= 6/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES >> >>> Owen >>> >>> _______________________________________________ >>> 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 --LajtsGeQqttSTEkIGJj3Kf2J6SJb04Pds 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 iEYEARECAAYFAlZFKNgACgkQ8AA1q7Z/VrI7YACcDzk2xbR0+jCRII/7UUM2SkHc 2WsAoInHU1fiSVgHUNVIQiDcvDpXT4Od =rbYy -----END PGP SIGNATURE----- --LajtsGeQqttSTEkIGJj3Kf2J6SJb04Pds-- From nobody Thu Nov 12 16:04: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 851E61B3D85 for ; Thu, 12 Nov 2015 16:04:09 -0800 (PST) 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, 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 mpRrIAoRtA8b for ; Thu, 12 Nov 2015 16:04:06 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBEE1B3D7D for ; Thu, 12 Nov 2015 16:04:06 -0800 (PST) Received: by qkao63 with SMTP id o63so32167714qka.2 for ; Thu, 12 Nov 2015 16:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1rp/m5d7OL3OgpVjb4/rvGeG66aYBAr+4lt2WRIC5Vg=; b=lakZTfknuGouZWjjQgp5fV7zjTsJAT/ndxwJfxugoGGS6KEnaIC6BcXWpbZ0B+KJxg QAwTClbohhNsfwpQAZJGlkvqFTqtF/5lh93u3Zhov9Mv5cG0+8SJewQ/8DvNdvqxHXmD T7b70ORgy6G+0oeZfMudwE35U7+QLKonPn6kguaMc39NlXOdDwM3nSgtlmiS3npKMmtP P9DTI0THtK1BgNDg7n8DuN8vTbxZw/vZ+ECQkbP9vT0qsk5Qy0R987g2Xwy8mVMmlla7 brP3/1U2pSoeMlzWYOxzL0beqrydFvLdK4ZlZzVCLdqzm2krMM6FRKN3dhfOJtMODyAU KCrA== 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=1rp/m5d7OL3OgpVjb4/rvGeG66aYBAr+4lt2WRIC5Vg=; b=F+FZJCBybl/dnw27+4w3aYWQufEH9GrM+1cs6QLHtAX4Bzw8Tl3b0VlJuJJl1BmjPQ VYfYmncDBKqvJPOStbroPHugfzxYSrxrYw3luyW75JehxVriU6SEGk5SA9AzCFlguFaz ArNO6FfRXrYc7n5uIFkHU3PEie0lNQHxH3ieQMHPoRGynLRV8UNdvD9ZqZbZ3g3RXnzW FlZywP4xcmRK5yJeKUdGEwPw1lO+11iAxsoWakpw9uUG0JDWRVvZ0kaIjAkknB4g1qVr P0HHe0gxIZmRtKWYbAeD4K2lq+Zu1f8Vcq6c1t83s9JZ8TKebZuioSZAe+EEo7AfeHYm 8NFw== X-Gm-Message-State: ALoCoQlis6G6anCDjZsQR/tw4fXqrWkNFPUD8N2gD3XKpU+9kH1dp+vNGim3amIcXeaHEhJMMFjq MIME-Version: 1.0 X-Received: by 10.140.226.8 with SMTP id w8mr20215113qhb.83.1447373045285; Thu, 12 Nov 2015 16:04:05 -0800 (PST) Received: by 10.55.80.66 with HTTP; Thu, 12 Nov 2015 16:04:05 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:ddff:ddf9:96dd:c63d] In-Reply-To: <564525C2.2080508@gmail.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> Date: Fri, 13 Nov 2015 10:04:05 +1000 Message-ID: From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1138f6f038e523052460cc28 Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 00:04:09 -0000 --001a1138f6f038e523052460cc28 Content-Type: text/plain; charset=UTF-8 this is a specious argument. Its as specious as the 'one IP per citizen' complaints relating to some national numbering plans, or the model of assigning v6 to motor vehicle vendors. the reason its specious, is twofold 1) it has a natural ramp up. to get every SME up to speed and *able* to multihome and route, takes time. Therefore there is no cliff moment: its a process. A process which emerges, over time, and permits adjustment of the routing model to cope. 2) other processes are also placing pressure on routing slots and the routing model. Therefore, by the time we need to handle 150-250m SMEs (after all there will be more..) we will have evolved models of both address management, and scoped routing, and abstract routing data models which suit the scale we need. please don't make assumptions now, based on future fear. We have nothing to fear, except fear itself. _G On Fri, Nov 13, 2015 at 9:50 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 13/11/2015 10:48, Mark Andrews wrote: > > > > In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen > DeLong write > > s: > >> > >>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: > >>> > >>> Hi, > >>> > >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: > >>>>> The IETF world does not (at least "should not") revolve around > "companies > >> ", > >>>>> and I wish you good luck finding a SoHo ISP that will route your PI > space > >> . > >>>> > >>>> 2620:0:930::/48 > >>> > >>> This is not a typical SoHo ISP. > >>> > >>> Try finding one which is not your employer. > >> > >> neither of the upstreams for that address employs me at this time. > >> > >> Admittedly I did use to work for ONE of the two, but anyone can get > that one > >> to route their /48. > > > > And how many SME's are there in the world? This paper [1] puts the > > number at 125M MSME world wide. That's 125M routing slots if > > everyone gets a /48. > > Thanks for that reference. My estimate of 10M was based on some hand-waving > arguments about how many SMEs might seriously want to be multihomed; IMHO > most of them will be perfectly happy with PA addressing because they will > have anything that needs a stable address hosted anyway. Most SOHOs just > don't > care, and get renumbered without knowing it after power fails etc. Homenet > takes this as a given, of course. > > Brian > > > > > > Mark > > > > [1] > http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES > > > >> Owen > >> > >> _______________________________________________ > >> 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 > --001a1138f6f038e523052460cc28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    this is a specious argument.=C2=A0 Its as specious as the = 'one IP per citizen' complaints relating to some national numbering= plans, or the model of assigning v6 to motor vehicle vendors.

    the reason its specious, is twofold

    1) it h= as a natural ramp up. to get every SME up to speed and *able* to multihome = and route, takes time. Therefore there is no cliff moment: its a process. A= process which emerges, over time, and permits adjustment of the routing mo= del to cope.

    2) other processes are also placing p= ressure on routing slots and the routing model. Therefore, by the time we n= eed to handle 150-250m SMEs (after all there will be more..) we will have e= volved models of both address management, and scoped routing, and abstract = routing data models which suit the scale we need.

    = please don't make assumptions now, based on future fear. We have nothin= g to fear, except fear itself.

    _G

    On Fri, Nov 13, 2015 a= t 9:50 AM, Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
    On 13/11/2015 10:48, Mark= Andrews wrote:
    >
    > In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen D= eLong write
    > s:
    >>
    >>> On Nov 12, 2015, at 11:43 , Gert Doering <gert@space.net> wrote:
    >>>
    >>> Hi,
    >>>
    >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>>>> The IETF world does not (at least "should not&quo= t;) revolve around "companies
    >> ",
    >>>>> and I wish you good luck finding a SoHo ISP that will = route your PI space
    >> .
    >>>>
    >>>> 2620:0:930::/48
    >>>
    >>> This is not a typical SoHo ISP.
    >>>
    >>> Try finding one which is not your employer.
    >>
    >> neither of the upstreams for that address employs me at this time.=
    >>
    >> Admittedly I did use to work for ONE of the two, but anyone can ge= t that one
    >> to route their /48.
    >
    > And how many SME's are there in the world?=C2=A0 This paper [1] pu= ts the
    > number at 125M MSME world wide.=C2=A0 That's 125M routing slots if=
    > everyone gets a /48.

    Thanks for that reference. My estimate of 10M was based on some hand-waving=
    arguments about how many SMEs might seriously want to be multihomed; IMHO most of them will be perfectly happy with PA addressing because they will have anything that needs a stable address hosted anyway. Most SOHOs just do= n't
    care, and get renumbered without knowing it after power fails etc. Homenet<= br> takes this as a given, of course.

    =C2=A0 =C2=A0 Brian


    >
    > Mark
    >
    > [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b5195= 83b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES
    >
    >> Owen
    >>
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >> https://www.ietf.org/mailman/listinfo/v6ops<= br>
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

    --001a1138f6f038e523052460cc28-- From nobody Thu Nov 12 16:10: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 CE4931B3DB1 for ; Thu, 12 Nov 2015 16:10:31 -0800 (PST) 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 Ps0ciYOIf9Kr for ; Thu, 12 Nov 2015 16:10:31 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 D94CE1B3D75 for ; Thu, 12 Nov 2015 16:10:30 -0800 (PST) Received: by ykdv3 with SMTP id v3so121691703ykd.0 for ; Thu, 12 Nov 2015 16:10:30 -0800 (PST) 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=WuUgBuQsQQvQ1qzmzY/UgdDUplKugAFp7vn4Xebrq7Y=; b=otr2c3aX4n8nI8NIjM9yoIDR4ZmS1dtU7iFXyJvwkI1Mk5x6pAbxKdzKDeCM9HUoTw FU4S6P9QOOW7EDreermtuGd9/xzoWH1Q2Yovm2GtP2IqtvGr3tTFeng//UyGIhgU/Z5A ujxEiaT64MnGTW7hHNpHtuvtJVwoYC0e/wmcQSHPSJnBWtriZ7MPdzWZ1a2Y7aOzPjGe JlQ0p8DSYpVBPNjUMNhJlXYdsb4cKUnFVKMBmXRWaqbbD7J0SgdH7lBwK8TKRmoMiBBn nG6Zo7ynS3awEKLW4dZ4nYLJhWQkNDdHjd2CG9v6GcGSqgEWWogxyibMzCVKY6ecvw9o NeoA== 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=WuUgBuQsQQvQ1qzmzY/UgdDUplKugAFp7vn4Xebrq7Y=; b=N9il9Yum7g1rXk0kN39/henb06fPdDYujFlJ9pt+adNyQe8AI4xTrxvKM2XsNzQRCf 4Gg8AdoEKwFxNbOf296d+35NDDpmbq+hhWEhwdZbLw1lc4C4b5hChnndq4wGZsmQ//WZ VFVx9I1EXVgZ8BvB/f3+lJUbgiq1MBxrWvtV65mnU03kKrnbw1z3WJ4qf0Ms2jDx+maX Sgcq6Z7a44wQOeE+J5WoHkxryoBC5d8TRca4Qm66UESvzaujW65DQovlaqQvZZSD1pSU Gy09/kyItyQFCUkvXd11pcDRzlvnHI3fHRZrx7PHABeHLme5gd0K8YAsgBP7DMJ7Tw2j REOw== X-Gm-Message-State: ALoCoQnvC+Xqc7NtB884FYDNU6UGz60Erq5II/SilIFIH3FhqwEBpkSJoqZYJIfDlKGs0XjQRTjw X-Received: by 10.129.136.5 with SMTP id y5mr19269595ywf.35.1447373430109; Thu, 12 Nov 2015 16:10:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 16:10:10 -0800 (PST) In-Reply-To: References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 09:10:10 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a114effba293fce052460e3e9 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 00:10:32 -0000 --001a114effba293fce052460e3e9 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 10, 2015 at 11:13 PM, Eric Vyncke (evyncke) wrote: > > It is only 'slightly' easier... Because guessing the TCP sequence number > of the other party... Well good luck :-) > The sort of application that tries to do this doesn't typically use TCP. --001a114effba293fce052460e3e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Nov 10, 2015 at 11:13 PM, Eric Vyncke (evyncke) <<= a href=3D"mailto:evyncke@cisco.com" target=3D"_blank">evyncke@cisco.com= > wrote:
    It is only = 'slightly' easier... Because guessing the TCP sequence number of th= e other party... Well good luck :-)

    =
    The sort of application that tries to do this doesn't typically us= e TCP.=C2=A0
    --001a114effba293fce052460e3e9-- From nobody Thu Nov 12 16:15: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 057F81B3DD2 for ; Thu, 12 Nov 2015 16:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 cS8IPuoNyzHm for ; Thu, 12 Nov 2015 16:15:49 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4341B3DCF for ; Thu, 12 Nov 2015 16:15:49 -0800 (PST) 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 tAD0DkWb007648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 16:13:46 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_BD7FE86B-A06E-462D-A670-871D0E4B9DAC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151112225306.BBA8A3C99209@rock.dv.isc.org> Date: Thu, 12 Nov 2015 16:13:45 -0800 Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> <20151112225306.BBA8A3C99209@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 00:15:53 -0000 --Apple-Mail=_BD7FE86B-A06E-462D-A670-871D0E4B9DAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 12, 2015, at 14:53 , Mark Andrews wrote: >=20 >=20 > In message <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com = >, Owen DeLong = write > s: >>=20 >>> On Nov 12, 2015, at 12:08 , Mark Smith = wrote: >>>=20 >>> On 13 November 2015 at 05:32, Owen DeLong wrote: >>>>=20 >>>>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: >>>>>=20 >>> >>>=20 >>>> Please explain exactly what circumstances make it too difficult for >> any company >>>> to acquire a /48 PI as I would consider this a brokenness in the >> relevant RIRs >>>> policy and would happily work to resolve the issue. >>>>=20 >>>=20 >>> This was was in part what I was getting getting at when I said that >>> abandoning ULAs would discourage adoption of IPv6. >>>=20 >>> If you're building a small network that either currently isn't and = may >>> never be attached to the Internet, you have 3 choices: >>>=20 >>> (a) apply for RIR membership and incur annual RIR costs to get a PI >>> /48 and after some time delay, be able to build your IPv6 network >>>=20 >>> (b) use $free ULA space, and be able to build your IPv6 network = right >> now >>>=20 >>> (c) use $free RFC1918 IPv4 space, and build an IPv4 network right = now >>>=20 >>>=20 >>> Option (a) has financial costs and time delays that option (b) >>> doesn't, and if option (b) doesn't exist, then option (c) is the = most >>> convenient and timely choice, unless it is essential that IPv6 is >>> used. Option (c) being the most convenient, cost effective and = timely >>> option for if (b) isn't available will actually discourage support = for >>> IPv6. >>=20 >> (d) use whatever string of {32,48,64} bits you want and pretend its >> an IPv6 prefix. >>=20 >> Please explain what benefit (b) offers over (d) in such a case. Youre >> going to end up renumbering when you attach to the internet either = way. >=20 > Renumbering in IPv6 is not the same as renumbering in IPv4. In > this case you are just adding a prefix. You don't stop using the > ULA addresses in (b). For (d) you need to remove the addresses > because you don't know what you are colliding with. I=E2=80=99m well aware of this. Nonetheless, your statement is not true. (d) if I use something like f3fe::, I can be quite certain for some time = to come that I=E2=80=99m not colliding with anything other than someone else who = randomly chose f3fe::. This is actually a lower likelihood of collision than I get with ULA. True, if I chose something within 2000::/3, I know I=E2=80=99m likely to = collide with some unknown thing that expects their addresses to be globally unique. Also true that at some future date, my f3fe:: address may come to = collide with some future IETF decision at which point I _MAY_ have to remove the = prefix. > Additionally we have deployed technology for nodes to update their > addresses in the DNS which deals with most of the renumber problem. Not sure how this is relevant, but whatever. > A 1 page BCP which says to do what Apple and various router vendors > have been doing for years updating the DNS should be enough to get > the rest to do this. Again, not sure how this is relevant to the utility (or lack thereof) = for ULA. >>> I think that if (a) was the only choice, it is in effect creating an >>> annual tax or license fee on the use of IPv6 technology, because (in >>> theory) you wouldn't be able to use IPv6 unless you paid an RIR and >>> waited for them to give you your space. Of course, the other choice >>> would be that some people would steal space to use instead to build = an >>> IPv6 network, like the documentation prefix. Absence of a local use >>> address space encourages stealing of other address spaces if you = don't >>> have time to get a proper one or don't have the financial means or >>> financial incentive to get some. >>=20 >> Im all for providing a lower cost alternative to having a legitimate >> registry for addresses for smaller users. >>=20 >>> Humans don't incur costs on themselves unless they see or perceive >>> some equivalent benefit. Making something available for "free", in >>> this case a local yet globally unique network address space, >>> significantly lowers the barrier to IPv6 adoption. If you've bought >>> the equipment to build your network, and it comes IPv6 enabled for >>> "free", you can then immediately build an IPv6 network using ULA >>> space. >>=20 >> Except that ULA isnt globally unique, its just probably unique for = various >> relatively high values of probably depending on how you go about = choosing >> your ULA prefix. Were ULA globally unique, youd have the double edge = sword >> of: >>=20 >> 1. Its good because its free PI address space. >> 2. Its bad because its a free end-run around the RIR policy >> processes. >=20 > And that matters how? If you happen to learn a remote ULA address > and actually use it the border router should block the packet and > send back a ICMP administrively prohibited unreachable. If there > is a ULA prefix collision you still have to match the rest of the > address which is highly unlikely. Subnet collisions in this case > are likely but not the full address. Why? There are circumstances where the border router may actually intend to exchange packets with some other person using that same ULA prefix. ULA is just like RFC-1918 except it provides a greater illusion of = utility. It still offers all the same problems, just in a less constrained and = (potentially) harder to identify way. It does offer a greater timeline and potential for the = creation of time-bomb configurations that work at the time of installation and = then break spectacularly at some future date due to the collision of earlier = decisions on two networks that later find themselves connected in places far removed from = where those decisions were made. >>> If at a later date a ULA addressed network connects to the Internet >>> they would add PA or PI space to be able to access external >>> destinations, because IPv6 is designed to fully support parallel >>> address spaces (i.e., so having ULAs on your network doesn't >>> automatically imply using NAT66). >>=20 >> Except for all the problems previously noted in such installations = with >> various issues around source address selection, etc. >=20 > Which in practice does not exist. I've run networks with ULA + PA > locally and *never* seen a issue due to address selection. Longest > match takes care of that for the older machines (0010 vs 1111). > Newer machines know about ULA so have different address match rules > which deal with ULA address leaks. Properly configuring the border > routers to return ICMPv6 administrively prohibited for attempts to > send a packet outside the site using a address from the ULA prefix > deals with the rest. I hate to break it to you Mark, but your relatively narrow experience = does not constitute the entire world. I have seen these problems, even in as = simple a case as GUA/SLAAC + GUA/Privacy Address. I have seen problems getting outbound connections to select the correct = source address in a variety of scenarios and I have seen things break in = significant and interesting ways as a result. I assure you that these problems most definitely do exist in practice in = some environments, even if yours doesn=E2=80=99t happen to be one of them. Owen --Apple-Mail=_BD7FE86B-A06E-462D-A670-871D0E4B9DAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 12, 2015, at 14:53 , Mark Andrews <marka@isc.org> = wrote:


    In message <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>, Owen DeLong write
    s:

    On Nov 12, 2015, at 12:08 , Mark Smith <markzzzsmith@gmail.com> wrote:

    On 13 November 2015 at 05:32, Owen DeLong <owen@delong.com> = wrote:

    On Nov 5, 2015, at 23:14 = , sthaug@nethelp.no = wrote:

    <snip.

    Please = explain exactly what circumstances make it too difficult for
    any company
    to = acquire a /48 PI as I would consider this a brokenness in the
    relevant RIRs
    policy and would happily work to resolve the issue.


    This was was in = part what I was getting getting at when I said that
    abandoning ULAs would discourage adoption of IPv6.

    If you're building a small network that either = currently isn't and may
    never be attached to the Internet, = you have 3 choices:

    (a) apply for RIR = membership and incur annual RIR costs to get a PI
    /48 and = after some time delay, be able to build your IPv6 network

    (b) use $free ULA space, and be able to build = your IPv6 network right
    now

    (c) use = $free RFC1918 IPv4 space, and build an IPv4 network right now


    Option (a) has financial costs = and time delays that option (b)
    doesn't, and if option (b) = doesn't exist, then option (c) is the most
    convenient and = timely choice, unless it is essential that IPv6 is
    used. = Option (c) being the most convenient, cost effective and timely
    option for if (b) isn't available will actually discourage = support for
    IPv6.

    (d) use whatever string of {32,48,64} bits you want and = pretend its
    an IPv6 prefix.

    Please explain what benefit (b) offers over (d) in such a = case. Youre
    going to end up renumbering when you attach to = the internet either way.

    Renumbering in IPv6 is not the same as = renumbering in IPv4.  In
    this case you are just = adding a prefix.  You don't stop using the
    ULA addresses in (b).  For (d) you need to = remove the addresses
    because you don't know = what you are colliding with.

    I=E2=80=99m = well aware of this. Nonetheless, your statement is not = true.

    (d) if I use something like = f3fe::, I can be quite certain for some time to come = that
    I=E2=80=99m not colliding with anything other than = someone else who randomly chose f3fe::.

    This is actually a lower likelihood of collision = than I get with ULA.

    True, if I = chose something within 2000::/3, I know I=E2=80=99m likely to collide = with some
    unknown thing that expects their addresses to be = globally unique.

    Also true that at = some future date, my f3fe:: address may come to collide = with
    some future IETF decision at which point I _MAY_ have to = remove the prefix.

    Additionally we = have deployed technology for nodes to update their
    addresses in the DNS which deals with most of = the renumber problem.

    Not sure = how this is relevant, but whatever.

    A 1 page BCP which says to do what Apple and = various router vendors
    have been doing for years = updating the DNS should be enough to get
    the rest to do this.

    Again, not sure = how this is relevant to the utility (or lack thereof) for = ULA.

    I think that if = (a) was the only choice, it is in effect creating an
    annual = tax or license fee on the use of IPv6 technology, because (in
    theory) you wouldn't be able to use IPv6 unless you paid an = RIR and
    waited for them to give you your space. Of course, = the other choice
    would be that some people would steal = space to use instead to build an
    IPv6 network, like the = documentation prefix. Absence of a local use
    address space = encourages stealing of other address spaces if you don't
    have time to get a proper one or don't have the financial = means or
    financial incentive to get some.

    Im all for providing a lower cost = alternative to having a legitimate
    registry for addresses = for smaller users.

    Humans don't incur costs on themselves unless they see or = perceive
    some equivalent benefit. Making something = available for "free", in
    this case a local yet globally = unique network address space,
    significantly lowers the = barrier to IPv6 adoption. If you've bought
    the equipment = to build your network, and it comes IPv6 enabled for
    "free",= you can then immediately build an IPv6 network using ULA
    space.

    Except that = ULA isnt globally unique, its just probably unique for various
    relatively high values of probably depending on how you go = about choosing
    your ULA prefix. Were ULA globally unique, = youd have the double edge sword
    of:

    = 1. = Its good because its free PI address space.
    2. Its bad = because its a free end-run around the RIR policy
    processes.

    And that matters how?  If you happen to = learn a remote ULA address
    and actually use it the = border router should block the packet and
    send back a ICMP administrively prohibited = unreachable.  If there
    is a ULA prefix collision = you still have to match the rest of the
    address which is highly unlikely.  Subnet = collisions in this case
    are likely but not the = full address.

    Why? There are = circumstances where the border router may actually intend
    to = exchange packets with some other person using that same ULA = prefix.

    ULA is just like RFC-1918 = except it provides a greater illusion of utility. It = still
    offers all the same problems, just in a less constrained = and (potentially) harder
    to identify way. It does offer a = greater timeline and potential for the creation
    of time-bomb = configurations that work at the time of installation and then = break
    spectacularly at some future date due to the collision = of earlier decisions on two
    networks that later find = themselves connected in places far removed from where
    those = decisions were made.

    If at a later date a ULA addressed network connects to the = Internet
    they would add PA or PI space to be able to = access external
    destinations, because IPv6 is designed to = fully support parallel
    address spaces (i.e., so having = ULAs on your network doesn't
    automatically imply using = NAT66).

    Except for all the = problems previously noted in such installations with
    various= issues around source address selection, etc.

    Which in practice does not = exist.  I've run networks with ULA + PA
    locally and *never* seen a issue due to address = selection.  Longest
    match takes care of that = for the older machines (0010 vs 1111).
    Newer machines know about ULA so have different = address match rules
    which deal with ULA = address leaks.  Properly configuring the border
    routers to return ICMPv6 administrively = prohibited for attempts to
    send a packet outside the = site using a address from the ULA prefix
    deals with the rest.

    I hate to = break it to you Mark, but your relatively narrow experience does = not
    constitute the entire world. I have seen these problems, = even in as simple a
    case as GUA/SLAAC + GUA/Privacy = Address.

    I have seen problems = getting outbound connections to select the correct = source
    address in a variety of scenarios and I have seen = things break in significant and
    interesting ways as a = result.

    I assure you that these = problems most definitely do exist in practice in = some
    environments, even if yours doesn=E2=80=99t happen to be = one of them.

    Owen


    = --Apple-Mail=_BD7FE86B-A06E-462D-A670-871D0E4B9DAC-- From nobody Thu Nov 12 16:16: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 936C61B3DDC for ; Thu, 12 Nov 2015 16:16:01 -0800 (PST) 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 Rdh06GbCzH0H for ; Thu, 12 Nov 2015 16:15:56 -0800 (PST) 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 73AC81B3DD5 for ; Thu, 12 Nov 2015 16:15:56 -0800 (PST) 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 D383034930F; Fri, 13 Nov 2015 00:15:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5F65E160067; Fri, 13 Nov 2015 00:16:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4A259160084; Fri, 13 Nov 2015 00:16:27 +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 wPepqEDwuPJp; Fri, 13 Nov 2015 00:16:27 +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 B3B72160067; Fri, 13 Nov 2015 00:16:26 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 607A63C9A177; Fri, 13 Nov 2015 11:15:51 +1100 (EST) To: George Michaelson From: Mark Andrews References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> In-reply-to: Your message of "Fri, 13 Nov 2015 10:04:05 +1000." Date: Fri, 13 Nov 2015 11:15:51 +1100 Message-Id: <20151113001551.607A63C9A177@rock.dv.isc.org> Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 00:16:01 -0000 In message , George Michaelson writes: > > this is a specious argument. Its as specious as the 'one IP per citizen' > complaints relating to some national numbering plans, or the model of > assigning v6 to motor vehicle vendors. > > the reason its specious, is twofold > > 1) it has a natural ramp up. to get every SME up to speed and *able* to > multihome and route, takes time. Therefore there is no cliff moment: its a > process. A process which emerges, over time, and permits adjustment of the > routing model to cope. Your assuming multi-homing. If you don't have PA, ULA + PA and don't have ULA + NAT then PI is all that is left and there is a very small bar to jump to be singly attached. You don't even need to run a routing protocol. You just need the ISP to inject the /48 for you. Owen wants us to just recommend PI and to forget about PA, ULA + PA and ULA + NAT. If that is the recommendation then we will have 125M /48's within a couple of years. That's why we should reject Owen's recommedation and go with something more conservative. e.g. a mixture of PI, PA and PA + ULA. > 2) other processes are also placing pressure on routing slots and the > routing model. Therefore, by the time we need to handle 150-250m SMEs > (after all there will be more..) we will have evolved models of both > address management, and scoped routing, and abstract routing data models > which suit the scale we need. > > please don't make assumptions now, based on future fear. We have nothing to > fear, except fear itself. > > _G > > On Fri, Nov 13, 2015 at 9:50 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > On 13/11/2015 10:48, Mark Andrews wrote: > > > > > > In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen > > DeLong write > > > s: > > >> > > >>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: > > >>> > > >>> Hi, > > >>> > > >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: > > >>>>> The IETF world does not (at least "should not") revolve around > > "companies > > >> ", > > >>>>> and I wish you good luck finding a SoHo ISP that will route your PI > > space > > >> . > > >>>> > > >>>> 2620:0:930::/48 > > >>> > > >>> This is not a typical SoHo ISP. > > >>> > > >>> Try finding one which is not your employer. > > >> > > >> neither of the upstreams for that address employs me at this time. > > >> > > >> Admittedly I did use to work for ONE of the two, but anyone can get > > that one > > >> to route their /48. > > > > > > And how many SME's are there in the world? This paper [1] puts the > > > number at 125M MSME world wide. That's 125M routing slots if > > > everyone gets a /48. > > > > Thanks for that reference. My estimate of 10M was based on some hand-waving > > arguments about how many SMEs might seriously want to be multihomed; IMHO > > most of them will be perfectly happy with PA addressing because they will > > have anything that needs a stable address hosted anyway. Most SOHOs just > > don't > > care, and get renumbered without knowing it after power fails etc. Homenet > > takes this as a given, of course. > > > > Brian > > > > > > > > > > Mark > > > > > > [1] > > http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI > -AnalysisNote.pdf?MOD=AJPERES > > > > > >> Owen > > >> > > >> _______________________________________________ > > >> 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 > > > > --001a1138f6f038e523052460cc28 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
    this is a specious argument.=C2=A0 Its as specious as the = > 'one IP per citizen' complaints relating to some national numbering= > plans, or the model of assigning v6 to motor vehicle vendors.

    v>
    the reason its specious, is twofold

    1) it h= > as a natural ramp up. to get every SME up to speed and *able* to multihome = > and route, takes time. Therefore there is no cliff moment: its a process. A= > process which emerges, over time, and permits adjustment of the routing mo= > del to cope.

    2) other processes are also placing p= > ressure on routing slots and the routing model. Therefore, by the time we n= > eed to handle 150-250m SMEs (after all there will be more..) we will have e= > volved models of both address management, and scoped routing, and abstract = > routing data models which suit the scale we need.

    = > please don't make assumptions now, based on future fear. We have nothin= > g to fear, except fear itself.

    _G
    class=3D"gmail_extra">
    On Fri, Nov 13, 2015 a= > t 9:50 AM, Brian E Carpenter < e.carpenter@gmail.com" target=3D"_blank">brian.e.carpenter@gmail.com>= > ; wrote:
    .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13/11/2015 10:48, Mark= > Andrews wrote:
    > >
    > > In message < delong.com">95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen D= > eLong write
    > > s:
    > >>
    > >>> On Nov 12, 2015, at 11:43 , Gert Doering < :gert@space.net">gert@space.net> wrote:
    > >>>
    > >>> Hi,
    > >>>
    > >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: r> > >>>>> The IETF world does not (at least "should not&quo= > t;) revolve around "companies
    > >> ",
    > >>>>> and I wish you good luck finding a SoHo ISP that will = > route your PI space
    > >> .
    > >>>>
    > >>>> 2620:0:930::/48
    > >>>
    > >>> This is not a typical SoHo ISP.
    > >>>
    > >>> Try finding one which is not your employer.
    > >>
    > >> neither of the upstreams for that address employs me at this time.= >
    > >>
    > >> Admittedly I did use to work for ONE of the two, but anyone can ge= > t that one
    > >> to route their /48.
    > >
    > > And how many SME's are there in the world?=C2=A0 This paper [1] pu= > ts the
    > > number at 125M MSME world wide.=C2=A0 That's 125M routing slots if= >
    > > everyone gets a /48.
    >
    > Thanks for that reference. My estimate of 10M was based on some hand-waving= >
    > arguments about how many SMEs might seriously want to be multihomed; IMHO r> > most of them will be perfectly happy with PA addressing because they will r> > have anything that needs a stable address hosted anyway. Most SOHOs just do= > n't
    > care, and get renumbered without knowing it after power fails etc. Homenet<= > br> > takes this as a given, of course.
    >
    > =C2=A0 =C2=A0 Brian
    >
    >
    > >
    > > Mark
    > >
    > > [1] b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES" rel=3D"noreferrer" tar= > get=3D"_blank">http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b5195= > 83b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES
    > >
    > >> Owen
    > >>
    > >> _______________________________________________
    > >> v6ops mailing list
    > >> v6ops@ietf.org
    > >> eferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops<= > br> >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops
    >

    > > --001a1138f6f038e523052460cc28-- > > > --===============2879774530696980085== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --===============2879774530696980085==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Nov 12 16:16: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 99CA31B3DD7 for ; Thu, 12 Nov 2015 16:16:04 -0800 (PST) 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 qhjPW9H-HZwp for ; Thu, 12 Nov 2015 16:16:03 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 82F2E1B3DD5 for ; Thu, 12 Nov 2015 16:16:02 -0800 (PST) Received: by ykfs79 with SMTP id s79so122038653ykf.1 for ; Thu, 12 Nov 2015 16:16:01 -0800 (PST) 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=lQLlbZ7oIz5ap9zFiV6bPBUL8jI2yd3aKfock9QD/6c=; b=QU5n0jorveQpeBQ0yqheykvvvnTIC7mLzlPrsJGWo580jNnCWYEOpV5RSTnyF+UEQ2 Aui0Bmd01j7VebfdA/+DIfKGaFlMlxfEAsBNa8R3N3llFEatIG0qMs0UeLJ78ZQ708k8 JJSuqRDg0KAkxbShUFGBefOLcFobgUnUtqhkbXb/+rlXL7Prq94jhb8j4xzYc142dOV0 N9JbisAAVKmkcrZBZEUiXTVOHm5H92BBdmRJY9w5BvG87Y3qnMFOsnpE8hxpTA4pUpKq U7yS+5NHQNZf5BTCJNyL+jy5S3eeylRk21HbKhfgaEZduVKu/kke52uPEICyFlqGHkwu iJqA== 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=lQLlbZ7oIz5ap9zFiV6bPBUL8jI2yd3aKfock9QD/6c=; b=RSFqvcWbydthkvaaNHHq89hJfVceZUK2oxdCxA/m4C4gi+DXeSwve7zC6E/WaBQJJM YjKoqYLO+1SybEZpzqSUiGtmWS7hzdMEPeld8m5OJvmAQc6eNxdDei/iZ/UefpTdB0VA Xz6NtgMUn0koTn2X68/VLDzUxwV+LEl5KMQbP9E73r6MJlfm9xI5lO/kFZWP3M5jqIw/ TPl7rg/54VhSY1r40JgOywxO0qwbXbF9ZYTyPFLGSNx4lCITHiH2oCytnc+00pJKOTD8 aKeI467f5WDQXVtfkMd+W1mRfMhrtjIiqE0tzK6uZm9YLAc52zuNd+m4ePEt/WhG8oLw WtHw== X-Gm-Message-State: ALoCoQlsRzTzuQfXBMszYRGLa9FPshSlrGu5tZjfaehbdUbN7mx3sI8tT6hLYKQTIP3+/9ngcc9D X-Received: by 10.13.204.2 with SMTP id o2mr14252646ywd.160.1447373761785; Thu, 12 Nov 2015 16:16:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 16:15:42 -0800 (PST) In-Reply-To: <20151112214819.4EDE63C98D83@rock.dv.isc.org> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 09:15:42 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a114f136aee2b49052460f612 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 00:16:04 -0000 --001a114f136aee2b49052460f612 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 6:48 AM, Mark Andrews wrote: > And how many SME's are there in the world? This paper [1] puts the > number at 125M MSME world wide. That's 125M routing slots if > everyone gets a /48. > I doubt that all but a small fraction of those SMEs actually need multihoming. But even for those that do - we should be working on making it possible to multihome using src+dst routing, not NPT66 or NAT66. --001a114f136aee2b49052460f612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 6:48 AM, Mark Andrews <marka@isc.org> wrote:=
    And how many SME's are there in the = world?=C2=A0 This paper [1] puts the
    number at 125M MSME world wide.=C2=A0 That's 125M routing slots if
    everyone gets a /48.

    I doubt that all b= ut a small fraction of those SMEs actually need multihoming. But even for t= hose that do - we should be working on making it possible to multihome usin= g src+dst routing, not NPT66 or NAT66.
    --001a114f136aee2b49052460f612-- From nobody Thu Nov 12 16:21: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 6ABAA1A8A84 for ; Thu, 12 Nov 2015 16:20:55 -0800 (PST) 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, 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 n3T_ia3SZw-7 for ; Thu, 12 Nov 2015 16:20:53 -0800 (PST) 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 A32211A8A72 for ; Thu, 12 Nov 2015 16:20:53 -0800 (PST) Received: by qkcl124 with SMTP id l124so32775957qkc.3 for ; Thu, 12 Nov 2015 16:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/eFFrx6lyga1ApizjjlAQW6VGJI84tUqpYuTLhtQD4=; b=fZDiODul1QkdtXDAzAkV1A6Z4CrNRY8k+Z+aFYn6GcYFEFl/VfcVlUZor77MejZLxM jYJzun/q//0R2Em6MXdI8/z91hoFBhZ5WIrvKg4l/Yrp7urzHFX2JF5mVcL1Sw5SutU2 R0o7EXb5M4NQ6dK0gBkQX2bjVrzZNvLJLcp7sStRyIkw124U9X1QMAcKBkxEoWe7zVRL QVhIWsiGqt/env2CZXQHl4iDHwQR5xaStcjp8+IjiTlDDFLn2lwXYCabkJaoPxRQ6ZTa qN2sKMm2bjgXZnef2H2gZWDuRNk9nNJ74rlyecKqa8bomEziH/GOQ9sOQVxOgyzX4L6v YpRw== 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=+/eFFrx6lyga1ApizjjlAQW6VGJI84tUqpYuTLhtQD4=; b=i0ylq1jdphXu9Eqp7wH7oCWKmaCpAwf5eMmxIuPe1R6R+U2tTrKDClZXYTs0A2Pccr R+TsXBtDPH52asFtoyq4yoPiXkIWF2MY4id+LT8vpUH8v0RT9AzVR0jotraLAUpEEty0 YFN4iXgVjzVUGbjhT0g9aQg0I35aY20xzxBnhGNfi2c4wGnPf2yYU8SGx4WvQfTsc5CW eMt5LDb/8LPJYkicyEjk7f84XVPTQyIt39POnalMM6D6q6pvakC3CbSSuZerxRyt4Od5 kdo6omCMPdQuJhiXEmP4j4KhU5IB1ZwaEpO+NKzU3Jo62T7+S0Js/37rqORSOZz/IeS0 dyrw== X-Gm-Message-State: ALoCoQk/sTqLQcle44zQxgbMF75Yv4zbI2DtISYkbxl0XoFVEcQnNY8AY280XGZrZbI8lclt6/Px MIME-Version: 1.0 X-Received: by 10.55.18.154 with SMTP id 26mr18895011qks.0.1447374052682; Thu, 12 Nov 2015 16:20:52 -0800 (PST) Received: by 10.55.80.66 with HTTP; Thu, 12 Nov 2015 16:20:52 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:ddff:ddf9:96dd:c63d] In-Reply-To: <5644EE46.7000805@gmail.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> Date: Fri, 13 Nov 2015 10:20:52 +1000 Message-ID: From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114584da44868e0524610833 Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 00:20:55 -0000 --001a114584da44868e0524610833 Content-Type: text/plain; charset=UTF-8 I'm sorry Brian, but as I said in another reply, this is just specious. It's true in as much as IF all SME's wound up in BGP we'd have a heat-death problem. But a) they won't arrive tomorrow, or next year: it takes time, and b) other solutions to routing will emerge. Like, giving them scoped /48 out of a block which has export limits under some covering prefix, and limits the local visibility of their BGP independence to within some constrained context. It never ceases to amaze me that I tell a yak-herder my BGP failures, forcing local path selection, with no subsequent alteration in routing of concern to them, *and we're not even shipping packets* Tony Hain amongst others proposed models of geographic and scoped assignment which were shot down in flames by the usual suspects. Because its "not how we do it now" people don't like talking about this sensibly, but there are rational models of address management which preserve BGP like behaviour, but don't expose all routing decisions globally, that only have local meaning. G On Fri, Nov 13, 2015 at 5:53 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Please let's not pretend we're discussing the ULA draft any more. > > On 13/11/2015 07:32, Owen DeLong wrote: > > ... > > How is a /48 PI hard to acquire? Where? > > As others have implied, that isn't the point. The point (and I expect > we had this argument on the RRG list some years ago) is that we can't > put 10,000,000 /48 entries into BGP. So if we go around encouraging > all small enterprises to get a PI prefix we are all doomed. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114584da44868e0524610833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I'm sorry Brian, but as I said in another reply, this = is just specious. It's true in as much as IF all SME's wound up in = BGP we'd have a heat-death problem.

    But a) they won&= #39;t arrive tomorrow, or next year: it takes time, =C2=A0and b) other solu= tions to routing will emerge. Like, giving them scoped /48 out of a block w= hich has export limits under some covering prefix, and limits the local vis= ibility of their BGP independence to within some constrained context.
    =

    It never ceases to amaze me that I tell a yak-herder my= BGP failures, forcing local path selection, with no subsequent alteration = in routing of concern to them, *and we're not even shipping packets*

    Tony Hain amongst others proposed models of geograph= ic and scoped assignment which were shot down in flames by the usual suspec= ts. Because its "not how we do it now" people don't like talk= ing about this sensibly, but there are rational models of address managemen= t which preserve BGP like behaviour, but don't expose all routing decis= ions globally, that only have local meaning.

    G



    On Fri, Nov 13, 2015 at 5:53 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    Please let's not pretend we're discussing the ULA= draft any more.

    On 13/11/2015 07:32, Owen DeLong wrote:

    ...
    > How is a /48 PI hard to acquire? Where?

    As others have implied, that isn't the point. The point (and I expect we had this argument on the RRG list some years ago) is that we can't put 10,000,000 /48 entries into BGP. So if we go around encouraging
    all small enterprises to get a PI prefix we are all doomed.

    =C2=A0 =C2=A0Brian

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

    --001a114584da44868e0524610833-- From nobody Thu Nov 12 16:24: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 EBCEB1A9029 for ; Thu, 12 Nov 2015 16:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 yfxeOcC7bTtd for ; Thu, 12 Nov 2015 16:24:01 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0D81A8BC4 for ; Thu, 12 Nov 2015 16:24:01 -0800 (PST) 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 tAD0Mxln008504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 16:22:59 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_4CC9A730-516F-44F2-8FC1-830A20CE0F68" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151113001551.607A63C9A177@rock.dv.isc.org> Date: Thu, 12 Nov 2015 16:22:58 -0800 Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> <20151113001551.607A63C9A177@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 00:24:04 -0000 --Apple-Mail=_4CC9A730-516F-44F2-8FC1-830A20CE0F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 12, 2015, at 16:15 , Mark Andrews wrote: >=20 >=20 > In message = > > , George Michaelson writes: >>=20 >> this is a specious argument. Its as specious as the 'one IP per = citizen' >> complaints relating to some national numbering plans, or the model of >> assigning v6 to motor vehicle vendors. >>=20 >> the reason its specious, is twofold >>=20 >> 1) it has a natural ramp up. to get every SME up to speed and *able* = to >> multihome and route, takes time. Therefore there is no cliff moment: = its a >> process. A process which emerges, over time, and permits adjustment = of the >> routing model to cope. >=20 > Your assuming multi-homing. If you don't have PA, ULA + PA and > don't have ULA + NAT then PI is all that is left and there is a > very small bar to jump to be singly attached. You don't even need > to run a routing protocol. You just need the ISP to inject the /48 > for you. >=20 > Owen wants us to just recommend PI and to forget about PA, ULA + > PA and ULA + NAT. If that is the recommendation then we will have > 125M /48's within a couple of years. That's why we should reject > Owen's recommedation and go with something more conservative. No=E2=80=A6 You are placing words into my mouth that simply were never = there. I want to forget about ULA and ULA+NAT. I=E2=80=99m fine with PA for those willing to accept it and I advocate = PI for those not willing to accept PA and its limitations. I=E2=80=99ve never campaigned against PA. I have campaigned against the = refusal of PI for those that did not want PA, but that is a different issue. PA = where it is an adequate solution is fine with me. IMHO, those are a fairly = limited set of circumstances and we should be expecting a relatively significant = growth in the IPv6 routing table over the next couple of years, whether we like = the idea or not. But again, that=E2=80=99s a separate issue. >=20 > e.g. a mixture of PI, PA and PA + ULA. I accept a mixture of PI and PA. I even accept PA+ULA, though I argue it = is an inferior solution with significant drawbacks. Nonetheless, anything involving NAT whether or not it involves ULA on a = system which is connected to the internet is a harmful =E2=80=9Csolution" where = the harm inflicted often (usually) extends beyond the network that chose to implement said = =E2=80=9Csolution=E2=80=9D. Owen --Apple-Mail=_4CC9A730-516F-44F2-8FC1-830A20CE0F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 12, 2015, at 16:15 , Mark Andrews <marka@isc.org> = wrote:


    In message <CAKr6gn2wx_ZQVn-a2X4J4+y0xz27R5XzPCygpRoEwj_ejLpmBw@mail.gmail.= com>
    , George Michaelson writes:

    this is = a specious argument.  Its as specious as the 'one IP per = citizen'
    complaints relating to some national numbering = plans, or the model of
    assigning v6 to motor vehicle = vendors.

    the reason its specious, is = twofold

    1) it has a natural ramp up. to get = every SME up to speed and *able* to
    multihome and route, = takes time. Therefore there is no cliff moment: its a
    process. A process which emerges, over time, and permits = adjustment of the
    routing model to cope.

    Your assuming = multi-homing.  If you don't have PA, ULA + PA and
    don't have ULA + NAT then PI is all that is left = and there is a
    very small bar to jump to = be singly attached.  You don't even need
    to run a routing protocol.  You just need = the ISP to inject the /48
    for you.

    Owen wants us to just recommend PI and to forget = about PA, ULA +
    PA and ULA + NAT.  If = that is the recommendation then we will have
    125M /48's within a couple of years. =  That's why we should reject
    Owen's recommedation and go with something more = conservative.

    No=E2=80=A6 You = are placing words into my mouth that simply were never = there.

    I want to forget about ULA = and ULA+NAT.

    I=E2=80=99m fine with = PA for those willing to accept it and I advocate PI for those = not
    willing to accept PA and its limitations.

    I=E2=80=99ve never campaigned against PA. I have = campaigned against the refusal
    of PI for those that did not = want PA, but that is a different issue. PA where it
    is an = adequate solution is fine with me. IMHO, those are a fairly limited = set
    of circumstances and we should be expecting a relatively = significant growth
    in the IPv6 routing table over the next = couple of years, whether we like the idea
    or not. But again, = that=E2=80=99s a separate issue.



    = e.g. a mixture of PI, PA and PA = + ULA.

    I accept a = mixture of PI and PA. I even accept PA+ULA, though I argue it is = an
    inferior solution with significant drawbacks.

    Nonetheless, anything involving NAT whether or not = it involves ULA on a system
    which is connected to the internet = is a harmful =E2=80=9Csolution" where the harm inflicted
    often = (usually) extends beyond the network that chose to implement said = =E2=80=9Csolution=E2=80=9D.

    Owen


    = --Apple-Mail=_4CC9A730-516F-44F2-8FC1-830A20CE0F68-- From nobody Thu Nov 12 16:24: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 0D62E1A9039 for ; Thu, 12 Nov 2015 16:24:24 -0800 (PST) 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, 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 vXs32lIRDEpp for ; Thu, 12 Nov 2015 16:24:22 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626A51A9032 for ; Thu, 12 Nov 2015 16:24:19 -0800 (PST) Received: by qkcl124 with SMTP id l124so32841847qkc.3 for ; Thu, 12 Nov 2015 16:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CDHAb9kLrLNXDxSrlFIP58mV7CCPKBsei58oVAs0jns=; b=lMRrbczXNaqas4t/RXZ7ajMupa+E5xiiMHJ3jjYKx24aAYfc3pG8yj/LbNBEexgKZp k/Gzxbk1+but84dg6sZ9+awTEGI/bzTOlU7TkL0mbAvAVgbl7YM3VbEm02PwPp70Qz1J cjexP2bssVRORKyrl3r3UjTQQp548rR/ssAxa114uZob9Y9ssMdXngUZXuBURGdi8u60 l3rFwrt4NNkT1rqzhYigjdrCCswTh0WimjP2e70AuMhb0Q4fkzuqCzhzSUEslHAnMe3i nlBeW6AxjEJroTAWXhH1M/mCMU24F9Z/IfCOMwmhD01LV41AtaFbldhk4zXU3EFZzXRJ eM0A== 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=CDHAb9kLrLNXDxSrlFIP58mV7CCPKBsei58oVAs0jns=; b=EtkFzfmmSAhbSkTo+WeZVanVGL++IFk7Ao8FbF/0qOICEBhuFAMzx82MCFAnPaZwuj AR67tP9ts22yAAdJ4R6IxNk28Uvpda8fBeAkbVaIq7p2CIv4urr+mVqURQWVKo6mbdUh STP4x9WzJGqJQccln3UB5SRYLeM2S8oXra01JB1CcM6zvJe5li8HnkRBIiBe9ixHI3mC NnGDdPBm7Azkv/wJgvcvCaCO6jvi3smTQe9KOnpb+ie6gqfqrCCSyW/RCuY010JcLdpO KktTjRX32GHhwq5zHyJepmW4o5PNRX0yhn52CA0VGUpZrxwf12xkgF+KOREetlgkURZN 1AIw== X-Gm-Message-State: ALoCoQkBiXEqyggrVcrJ5n3StDdxBBXaL/sZpAJpgxnyqhwzPz9VS+ZXNYHq/7DZxHD0qKhLDX7Z MIME-Version: 1.0 X-Received: by 10.140.145.150 with SMTP id 144mr20095355qhr.82.1447374258591; Thu, 12 Nov 2015 16:24:18 -0800 (PST) Received: by 10.55.80.66 with HTTP; Thu, 12 Nov 2015 16:24:18 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:ddff:ddf9:96dd:c63d] In-Reply-To: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> Date: Fri, 13 Nov 2015 10:24:18 +1000 Message-ID: From: George Michaelson To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a113553388a6b1e0524611466 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 00:24:24 -0000 --001a113553388a6b1e0524611466 Content-Type: text/plain; charset=UTF-8 Strong +1. We need to stop using FUD on future routing cost to limit how we design systems for enterprises and homes. By all means lets constrain current behaviour to scale with memory and CPU, but to set limits 5-10-15 years out based on fear of a situation which is unlikely to emerge, and will emerge into different technology and models.. Well its sad. Its Dionysius Lardner "60mph will kill humans, stop speeding up steam trains" thinking. Whats even weirder, is that its some people who helped displace prior art, telephone number centric thinking who are doing it. How come the former rebels have become the empire? _G On Fri, Nov 13, 2015 at 10:15 AM, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 6:48 AM, Mark Andrews wrote: > >> And how many SME's are there in the world? This paper [1] puts the >> number at 125M MSME world wide. That's 125M routing slots if >> everyone gets a /48. >> > > I doubt that all but a small fraction of those SMEs actually need > multihoming. But even for those that do - we should be working on making it > possible to multihome using src+dst routing, not NPT66 or NAT66. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113553388a6b1e0524611466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Strong +1. We need to stop using FUD on future routing cos= t to limit how we design systems for enterprises and homes. By all means le= ts constrain current behaviour to scale with memory and CPU, but to set lim= its 5-10-15 years out based on fear of a situation which is unlikely to eme= rge, and will emerge into different technology and models.. Well its sad.
    Its=C2=A0Dionysius=C2=A0Lardner "60mph will kill humans, stop sp= eeding up steam trains" thinking.

    Whats even = weirder, is that its some people who helped displace prior art, telephone n= umber centric thinking who are doing it. How come the former rebels have be= come the empire?

    _G

    On Fri, Nov 13, 2015 at 10:15 AM, Lo= renzo Colitti <lorenzo@google.com> wrote:
    On Fri, Nov 13, 2015 at 6:48 AM, Mark Andrews= <m= arka@isc.org> wrote:
    And ho= w many SME's are there in the world?=C2=A0 This paper [1] puts the
    number at 125M MSME world wide.=C2=A0 That's 125M routing slots if
    everyone gets a /48.

    I doubt tha= t all but a small fraction of those SMEs actually need multihoming. But eve= n for those that do - we should be working on making it possible to multiho= me using src+dst routing, not NPT66 or NAT66.

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


    --001a113553388a6b1e0524611466-- From nobody Thu Nov 12 16:30: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 184421A8AEA for ; Thu, 12 Nov 2015 16:30:32 -0800 (PST) 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 5MCpM4bKbCPs for ; Thu, 12 Nov 2015 16:30:27 -0800 (PST) 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 DD3811A90C0 for ; Thu, 12 Nov 2015 16:30:26 -0800 (PST) Received: by pacdm15 with SMTP id dm15so80833910pac.3 for ; Thu, 12 Nov 2015 16:30:26 -0800 (PST) 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=EjkdPDZI93sc6VS8JN0KaZoQ1V/btbQNeycCHeICHPM=; b=wFELVoY9UfnobTxuRc6dU5wahQ7vuORIs5u6e1eGyuFSWEJdYfPLXkMxIbVgn0X/2n WoZoddlJY/i/UwoGFxpyUQ3m+vYi7Bms5GoLJpctJM9QK9vPYmx5dJYmdNySP0RL60f7 AW5Oi05pGMuxVaYGjDn2Vsiac20/rE8a3v5c7teHwfo3hjNXmyWSz6UHjs39isJusGXu 6mac7L+clzEOAqy0WzZdp+ccENx4NvpCvnWF59FGyTpnUAroiH1WPzUiprGojW4VExJ7 m3Q6aQKnDute0NwalPnkee04IUsipn447rhuTMsM96dDSmqhZ2VFBbySXvVGUHN/6US4 l9rA== X-Received: by 10.68.139.98 with SMTP id qx2mr27836594pbb.150.1447374626308; Thu, 12 Nov 2015 16:30:26 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t13sm16821386pbs.88.2015.11.12.16.30.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 16:30:25 -0800 (PST) To: Mark Andrews , George Michaelson References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> <20151113001551.607A63C9A177@rock.dv.isc.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56452F26.9090308@gmail.com> Date: Fri, 13 Nov 2015 13:30:30 +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: <20151113001551.607A63C9A177@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 00:30:32 -0000 On 13/11/2015 13:15, Mark Andrews wrote: > In message > , George Michaelson writes: >> >> this is a specious argument. Its as specious as the 'one IP per citizen' >> complaints relating to some national numbering plans, or the model of >> assigning v6 to motor vehicle vendors. >> >> the reason its specious, is twofold >> >> 1) it has a natural ramp up. to get every SME up to speed and *able* to >> multihome and route, takes time. Therefore there is no cliff moment: its a >> process. A process which emerges, over time, and permits adjustment of the >> routing model to cope. > > Your assuming multi-homing. If you don't have PA, ULA + PA and > don't have ULA + NAT then PI is all that is left and there is a > very small bar to jump to be singly attached. You don't even need > to run a routing protocol. You just need the ISP to inject the /48 > for you. > > Owen wants us to just recommend PI and to forget about PA, ULA + > PA and ULA + NAT. If that is the recommendation then we will have > 125M /48's within a couple of years. That's why we should reject > Owen's recommedation and go with something more conservative. > > e.g. a mixture of PI, PA and PA + ULA. Exactly. (I deny that my argument is specious; but then I won't believe in the BGP4 scaling fairy until I see him or her). Brian > >> 2) other processes are also placing pressure on routing slots and the >> routing model. Therefore, by the time we need to handle 150-250m SMEs >> (after all there will be more..) we will have evolved models of both >> address management, and scoped routing, and abstract routing data models >> which suit the scale we need. >> >> please don't make assumptions now, based on future fear. We have nothing to >> fear, except fear itself. >> >> _G >> >> On Fri, Nov 13, 2015 at 9:50 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> On 13/11/2015 10:48, Mark Andrews wrote: >>>> >>>> In message <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen >>> DeLong write >>>> s: >>>>> >>>>>> On Nov 12, 2015, at 11:43 , Gert Doering wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote: >>>>>>>> The IETF world does not (at least "should not") revolve around >>> "companies >>>>> ", >>>>>>>> and I wish you good luck finding a SoHo ISP that will route your PI >>> space >>>>> . >>>>>>> >>>>>>> 2620:0:930::/48 >>>>>> >>>>>> This is not a typical SoHo ISP. >>>>>> >>>>>> Try finding one which is not your employer. >>>>> >>>>> neither of the upstreams for that address employs me at this time. >>>>> >>>>> Admittedly I did use to work for ONE of the two, but anyone can get >>> that one >>>>> to route their /48. >>>> >>>> And how many SME's are there in the world? This paper [1] puts the >>>> number at 125M MSME world wide. That's 125M routing slots if >>>> everyone gets a /48. >>> >>> Thanks for that reference. My estimate of 10M was based on some hand-waving >>> arguments about how many SMEs might seriously want to be multihomed; IMHO >>> most of them will be perfectly happy with PA addressing because they will >>> have anything that needs a stable address hosted anyway. Most SOHOs just >>> don't >>> care, and get renumbered without knowing it after power fails etc. Homenet >>> takes this as a given, of course. >>> >>> Brian >>> >>> >>>> >>>> Mark >>>> >>>> [1] >>> http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI >> -AnalysisNote.pdf?MOD=AJPERES >>>> >>>>> Owen >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> --001a1138f6f038e523052460cc28 >> Content-Type: text/html; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >>
    this is a specious argument.=C2=A0 Its as specious as the = >> 'one IP per citizen' complaints relating to some national numbering= >> plans, or the model of assigning v6 to motor vehicle vendors.

    > v>
    the reason its specious, is twofold

    1) it h= >> as a natural ramp up. to get every SME up to speed and *able* to multihome = >> and route, takes time. Therefore there is no cliff moment: its a process. A= >> process which emerges, over time, and permits adjustment of the routing mo= >> del to cope.

    2) other processes are also placing p= >> ressure on routing slots and the routing model. Therefore, by the time we n= >> eed to handle 150-250m SMEs (after all there will be more..) we will have e= >> volved models of both address management, and scoped routing, and abstract = >> routing data models which suit the scale we need.

    = >> please don't make assumptions now, based on future fear. We have nothin= >> g to fear, except fear itself.

    _G
    > class=3D"gmail_extra">
    On Fri, Nov 13, 2015 a= >> t 9:50 AM, Brian E Carpenter <> e.carpenter@gmail.com" target=3D"_blank">brian.e.carpenter@gmail.com>= >> ; wrote:
    > .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13/11/2015 10:48, Mark= >> Andrews wrote:
    >> >
    >> > In message <> delong.com">95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com>, Owen D= >> eLong write
    >> > s:
    >> >>
    >> >>> On Nov 12, 2015, at 11:43 , Gert Doering <> :gert@space.net">gert@space.net> wrote:
    >> >>>
    >> >>> Hi,
    >> >>>
    >> >>> On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote:> r> >> >>>>> The IETF world does not (at least "should not&quo= >> t;) revolve around "companies
    >> >> ",
    >> >>>>> and I wish you good luck finding a SoHo ISP that will = >> route your PI space
    >> >> .
    >> >>>>
    >> >>>> 2620:0:930::/48
    >> >>>
    >> >>> This is not a typical SoHo ISP.
    >> >>>
    >> >>> Try finding one which is not your employer.
    >> >>
    >> >> neither of the upstreams for that address employs me at this time.= >>
    >> >>
    >> >> Admittedly I did use to work for ONE of the two, but anyone can ge= >> t that one
    >> >> to route their /48.
    >> >
    >> > And how many SME's are there in the world?=C2=A0 This paper [1] pu= >> ts the
    >> > number at 125M MSME world wide.=C2=A0 That's 125M routing slots if= >>
    >> > everyone gets a /48.
    >>
    >> Thanks for that reference. My estimate of 10M was based on some hand-waving= >>
    >> arguments about how many SMEs might seriously want to be multihomed; IMHO> r> >> most of them will be perfectly happy with PA addressing because they will> r> >> have anything that needs a stable address hosted anyway. Most SOHOs just do= >> n't
    >> care, and get renumbered without knowing it after power fails etc. Homenet<= >> br> >> takes this as a given, of course.
    >>
    >> =C2=A0 =C2=A0 Brian
    >>
    >>
    >> >
    >> > Mark
    >> >
    >> > [1] > b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES" rel=3D"noreferrer" tar= >> get=3D"_blank">http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b5195= >> 83b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES
    >> >
    >> >> Owen
    >> >>
    >> >> _______________________________________________
    >> >> v6ops mailing list
    >> >> v6ops@ietf.org
    >> >> > eferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops<= >> br> >>
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >> > target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops
    >>

    >> >> --001a1138f6f038e523052460cc28-- >> >> >> --===============2879774530696980085== >> Content-Type: text/plain; charset="us-ascii" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> --===============2879774530696980085==-- >> From nobody Thu Nov 12 16:34: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 128401A9153 for ; Thu, 12 Nov 2015 16:34:43 -0800 (PST) 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 KNXZ2SCi93V4 for ; Thu, 12 Nov 2015 16:34:41 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 980A31A914D for ; Thu, 12 Nov 2015 16:34:41 -0800 (PST) Received: by pacdm15 with SMTP id dm15so80949173pac.3 for ; Thu, 12 Nov 2015 16:34:41 -0800 (PST) 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=ZI5la9Js4QNIGIbyChITHKvFGjq2pI/MP6BBuLjpR7M=; b=ayyk3DoDLSTXQIeIsCFrDzrxcFY+coy+qW9/qaFLW8g2ZKWvm8mpH/0TEF/qEK3WVu QRbodw4BbKoVcQpwRhibAaGxeEIXfrQS70qNtHUu75wWCLDlqtJ7js7hfb/rr8Kyb1xq DaAy5qK8Hk1cpjSTBzaCTs5Dfigr3JCeImuRD9WyQdFzpmBcvAhdQSillTJ/E0EOouR6 i2trWlBuneMts1PWdUcvx5MJEjF2xwibTN1E7igJctqAeKOH4xD6HVt6CiG9zYFB4xK+ DKP+iNFNUYtZ+ylnMreWQoFRBWDnoFA2lj5JYBj+kzxqY0D1E2VM2GGSG+8tBVdnWSrd 1Vpw== X-Received: by 10.66.160.70 with SMTP id xi6mr18918627pab.54.1447374881192; Thu, 12 Nov 2015 16:34:41 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id kj3sm16836338pbc.59.2015.11.12.16.34.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 16:34:40 -0800 (PST) To: George Michaelson References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56453026.3090607@gmail.com> Date: Fri, 13 Nov 2015 13:34:46 +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: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 00:34:43 -0000 On 13/11/2015 13:20, George Michaelson wrote: > I'm sorry Brian, but as I said in another reply, this is just specious. > It's true in as much as IF all SME's wound up in BGP we'd have a heat-death > problem. > > But a) they won't arrive tomorrow, or next year: it takes time, and b) > other solutions to routing will emerge. No doubt. But Mark is correct: we have to defer the crisis until the solution is available. We deferred it once by introducing CIDR 20 years ago. Encouraging PI for all customers is antiCIDR, and that's a problem. Brian > Like, giving them scoped /48 out of > a block which has export limits under some covering prefix, and limits the > local visibility of their BGP independence to within some constrained > context. > > It never ceases to amaze me that I tell a yak-herder my BGP failures, > forcing local path selection, with no subsequent alteration in routing of > concern to them, *and we're not even shipping packets* > > Tony Hain amongst others proposed models of geographic and scoped > assignment which were shot down in flames by the usual suspects. Because > its "not how we do it now" people don't like talking about this sensibly, > but there are rational models of address management which preserve BGP like > behaviour, but don't expose all routing decisions globally, that only have > local meaning. > > G > > > > On Fri, Nov 13, 2015 at 5:53 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Please let's not pretend we're discussing the ULA draft any more. >> >> On 13/11/2015 07:32, Owen DeLong wrote: >> >> ... >>> How is a /48 PI hard to acquire? Where? >> >> As others have implied, that isn't the point. The point (and I expect >> we had this argument on the RRG list some years ago) is that we can't >> put 10,000,000 /48 entries into BGP. So if we go around encouraging >> all small enterprises to get a PI prefix we are all doomed. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Thu Nov 12 16:51: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 266611ACF1D for ; Thu, 12 Nov 2015 16:51:17 -0800 (PST) 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 9j6XJ9vxKEOV for ; Thu, 12 Nov 2015 16:51:14 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054D61ACEE9 for ; Thu, 12 Nov 2015 16:51:14 -0800 (PST) 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 1BA7C1FCAD0; Fri, 13 Nov 2015 00:51:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 94574160067; Fri, 13 Nov 2015 00:51:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 81ACB160084; Fri, 13 Nov 2015 00:51:42 +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 22weI1aAq6vq; Fri, 13 Nov 2015 00:51:42 +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 F29C3160067; Fri, 13 Nov 2015 00:51:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6B9023C9A578; Fri, 13 Nov 2015 11:51:06 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> <20151112225306.BBA8A3C99209@rock.dv.isc.org> In-reply-to: Your message of "Thu, 12 Nov 2015 16:13:45 -0800." Date: Fri, 13 Nov 2015 11:51:06 +1100 Message-Id: <20151113005106.6B9023C9A578@rock.dv.isc.org> Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 00:51:17 -0000 In message , Owen DeLong write s: > > > On Nov 12, 2015, at 14:53 , Mark Andrews wrote: > > > > > > In message <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com > >, Owen DeLong > write > > s: > >> > >>> On Nov 12, 2015, at 12:08 , Mark Smith wrote: > >>> > >>> On 13 November 2015 at 05:32, Owen DeLong wrote: > >>>> > >>>>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: > >>>>> > >>> >>>> > >>>> Please explain exactly what circumstances make it too difficult for > >> any company > >>>> to acquire a /48 PI as I would consider this a brokenness in the > >> relevant RIRs > >>>> policy and would happily work to resolve the issue. > >>>> > >>> > >>> This was was in part what I was getting getting at when I said that > >>> abandoning ULAs would discourage adoption of IPv6. > >>> > >>> If you're building a small network that either currently isn't and may > >>> never be attached to the Internet, you have 3 choices: > >>> > >>> (a) apply for RIR membership and incur annual RIR costs to get a PI > >>> /48 and after some time delay, be able to build your IPv6 network > >>> > >>> (b) use $free ULA space, and be able to build your IPv6 network right > >> now > >>> > >>> (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now > >>> > >>> > >>> Option (a) has financial costs and time delays that option (b) > >>> doesn't, and if option (b) doesn't exist, then option (c) is the most > >>> convenient and timely choice, unless it is essential that IPv6 is > >>> used. Option (c) being the most convenient, cost effective and timely > >>> option for if (b) isn't available will actually discourage support for > >>> IPv6. > >> > >> (d) use whatever string of {32,48,64} bits you want and pretend its > >> an IPv6 prefix. > >> > >> Please explain what benefit (b) offers over (d) in such a case. Youre > >> going to end up renumbering when you attach to the internet either way. > > > > Renumbering in IPv6 is not the same as renumbering in IPv4. In > > this case you are just adding a prefix. You don't stop using the > > ULA addresses in (b). For (d) you need to remove the addresses > > because you don't know what you are colliding with. > > I’m well aware of this. Nonetheless, your statement is not true. > > (d) if I use something like f3fe::, I can be quite certain for some time > to come that > I’m not colliding with anything other than someone else who randomly > chose f3fe::. > > This is actually a lower likelihood of collision than I get with ULA. > > True, if I chose something within 2000::/3, I know I’m likely to collide > with some > unknown thing that expects their addresses to be globally unique. > > Also true that at some future date, my f3fe:: address may come to collide > with > some future IETF decision at which point I _MAY_ have to remove the > prefix. So you just want a random free for all. Guess what it costs to clean up the mess that produces. We are going through the process of dealing with the mess of people thinking that the DNS root was a free for all despite it not being one. > > Additionally we have deployed technology for nodes to update their > > addresses in the DNS which deals with most of the renumber problem. > > Not sure how this is relevant, but whatever. Then you are not @#$!# paying attention. > > A 1 page BCP which says to do what Apple and various router vendors > > have been doing for years updating the DNS should be enough to get > > the rest to do this. > > Again, not sure how this is relevant to the utility (or lack thereof) for > ULA. > > >>> I think that if (a) was the only choice, it is in effect creating an > >>> annual tax or license fee on the use of IPv6 technology, because (in > >>> theory) you wouldn't be able to use IPv6 unless you paid an RIR and > >>> waited for them to give you your space. Of course, the other choice > >>> would be that some people would steal space to use instead to build an > >>> IPv6 network, like the documentation prefix. Absence of a local use > >>> address space encourages stealing of other address spaces if you don't > >>> have time to get a proper one or don't have the financial means or > >>> financial incentive to get some. > >> > >> Im all for providing a lower cost alternative to having a legitimate > >> registry for addresses for smaller users. > >> > >>> Humans don't incur costs on themselves unless they see or perceive > >>> some equivalent benefit. Making something available for "free", in > >>> this case a local yet globally unique network address space, > >>> significantly lowers the barrier to IPv6 adoption. If you've bought > >>> the equipment to build your network, and it comes IPv6 enabled for > >>> "free", you can then immediately build an IPv6 network using ULA > >>> space. > >> > >> Except that ULA isnt globally unique, its just probably unique for > various > >> relatively high values of probably depending on how you go about > choosing > >> your ULA prefix. Were ULA globally unique, youd have the double edge > sword > >> of: > >> > >> 1. Its good because its free PI address space. > >> 2. Its bad because its a free end-run around the RIR policy > >> processes. > > > > And that matters how? If you happen to learn a remote ULA address > > and actually use it the border router should block the packet and > > send back a ICMP administrively prohibited unreachable. If there > > is a ULA prefix collision you still have to match the rest of the > > address which is highly unlikely. Subnet collisions in this case > > are likely but not the full address. > > Why? There are circumstances where the border router may actually intend > to exchange packets with some other person using that same ULA prefix. And border routers can actually talk to two or more sites using the same ULA prefix today. This isn't rocket science. The api's to do this exist and are in use. It just takes a little care. The concept of the site boundary being through the middle of a box and the same prefixes being in use on multiple sites has been part of IPv6 from just about the very begining. If your border router can't handle this file a bug report because it is broken. Now if you want to route between ULA's using the same prefix then you have problems but it is easy to generate new ULA prefixes that don't collide and to then stop using the ones that collided. > ULA is just like RFC-1918 except it provides a greater illusion of > utility. It still > offers all the same problems, just in a less constrained and > (potentially) harder > to identify way. It does offer a greater timeline and potential for the > creation > of time-bomb configurations that work at the time of installation and > then break > spectacularly at some future date due to the collision of earlier > decisions on two > networks that later find themselves connected in places far removed from > where > those decisions were made. There is no time bomb. Only the illusion of a time bomb. > >>> If at a later date a ULA addressed network connects to the Internet > >>> they would add PA or PI space to be able to access external > >>> destinations, because IPv6 is designed to fully support parallel > >>> address spaces (i.e., so having ULAs on your network doesn't > >>> automatically imply using NAT66). > >> > >> Except for all the problems previously noted in such installations with > >> various issues around source address selection, etc. > > > > Which in practice does not exist. I've run networks with ULA + PA > > locally and *never* seen a issue due to address selection. Longest > > match takes care of that for the older machines (0010 vs 1111). > > Newer machines know about ULA so have different address match rules > > which deal with ULA address leaks. Properly configuring the border > > routers to return ICMPv6 administrively prohibited for attempts to > > send a packet outside the site using a address from the ULA prefix > > deals with the rest. > > I hate to break it to you Mark, but your relatively narrow experience > does not > constitute the entire world. I have seen these problems, even in as > simple a > case as GUA/SLAAC + GUA/Privacy Address. > > I have seen problems getting outbound connections to select the correct > source > address in a variety of scenarios and I have seen things break in > significant and > interesting ways as a result. > > I assure you that these problems most definitely do exist in practice in > some > environments, even if yours doesn’t happen to be one of them. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Nov 12 16:58: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 EFC041B3B82 for ; Thu, 12 Nov 2015 16:58:05 -0800 (PST) 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, 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 HHe7JUBYMq4X for ; Thu, 12 Nov 2015 16:58:04 -0800 (PST) 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 D3E341B3B74 for ; Thu, 12 Nov 2015 16:58:03 -0800 (PST) Received: by qkao63 with SMTP id o63so33187481qka.2 for ; Thu, 12 Nov 2015 16:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GiPfwGBZ7VSSQ5PhvwJYqEps827TbTrWXXA1bkwD0cg=; b=C6APqSn0ENDNfVZb7aPfDTajtMGlOrHSS8F8+1Kx20m9FpNkgOyVuQJQ97BDvJ/dgu Y2v4Wqc3jHlm9ZBGupMPoBsykHwkMMkxTRyRo1TD5u8BqQ0kiYtjYi507rJQSJxi99jE uJ5cuYVIjT5GlKH2R+llJqloqdVkRJK7JgGAbCDbCSuUs8vPTXy5YToR0fDZ8DiiP9se 9FmW3Jz8Rsxu5vxEbmK6XMnck5rRliTwKeUEu/8susKMa/IJYjcX/S1+CnE4r4NGtgW5 L99xn0bIROmxd7PkpJ/R+BtobTVHmLFzFxxYZqO0Db5xpoteHE8sfY5rWmMnj1ksqAwh AVdg== 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=GiPfwGBZ7VSSQ5PhvwJYqEps827TbTrWXXA1bkwD0cg=; b=AnSzKUbui6fGWyHu3qaNfh0lo9FCE/YxDY4nWtmLJo3BscLOR1fO/9jX42MrjrHSA8 OCrdwTuhwJvlxpiLBw4fUj1jYCP8os/fyKdycdjREBHTtJPZ2wwTkXyPaknyYbKPvkR9 fZCz8DkUW289mEv/rVizEGp3ox0L9gSJGrTiTeDFAP5CuW2yWFjAGv+k6ANxARB8vg24 ITGkSKVbUUacfVqx+RLvy6vTYfBLjRX5DGgVpBF1p8czoeFzsntyB52Maj3+heGKiczJ c4ipgEEiNAbcz/Vvd4zeZYvVkzNQq6yigFgB0rYWFV+riWJ7LSZ67egEZbG14VaFA0AH C4+g== X-Gm-Message-State: ALoCoQmKilLAePp/5bVywVLhci9Kj6JgRBFOmBZ0JwXYG5tCz9ILNmeW1TVI/Vgc6slznwGQzPxQ MIME-Version: 1.0 X-Received: by 10.55.18.154 with SMTP id 26mr19016906qks.0.1447376283040; Thu, 12 Nov 2015 16:58:03 -0800 (PST) Received: by 10.55.80.66 with HTTP; Thu, 12 Nov 2015 16:58:02 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:bc01:949f:ac2b:4e77] In-Reply-To: <56453026.3090607@gmail.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> Date: Fri, 13 Nov 2015 10:58:02 +1000 Message-ID: From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114584da3510420524618d01 Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 00:58:06 -0000 --001a114584da3510420524618d01 Content-Type: text/plain; charset=UTF-8 Since I work in the governance side, I have to be clear that I have no voice in policy in RIR land, this is just my personal opinion. But my personal opinion is that we are not facing a CIDR scale problem in this niche, and probably don't need to act like we are. My reason is simple: CIDR was about exhaustion as much as about routing. We have only half the problem, and even that is (in my opinion) tendentious. We *may* have half the CIDR problem, but its a may, not a *do*. -Therefore, applying CIDR logic to the address management process in V6 is not (yet) justified. Contrariwise, we have an uptake problem. We should be encouraging uptake of IPv6, and if pushback from network-literate SME's is that they are concerned about capture behind a PA then we should admit PI processes, and not be over-pessimistic about the cost in future routing terms of PI to SMEs Rather than asking BGP/Router people "can you make a router now for 100m prefixes" we should be saying "if we can forsee 100m prefixes in 5-10 years time, can you get there, and if not, what models of prefix management would work for you" I think this is a corollary of what John Scudder did in IEPG: we need the conversation with the ASIC people to be framed the right way. -G On Fri, Nov 13, 2015 at 10:34 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > On 13/11/2015 13:20, George Michaelson wrote: > > I'm sorry Brian, but as I said in another reply, this is just specious. > > It's true in as much as IF all SME's wound up in BGP we'd have a heat-death > > problem. > > > > But a) they won't arrive tomorrow, or next year: it takes time, and b) > > other solutions to routing will emerge. > > No doubt. But Mark is correct: we have to defer the crisis until the solution > is available. We deferred it once by introducing CIDR 20 years ago. Encouraging > PI for all customers is antiCIDR, and that's a problem. > > Brian > > > Like, giving them scoped /48 out of > > a block which has export limits under some covering prefix, and limits the > > local visibility of their BGP independence to within some constrained > > context. > > > > It never ceases to amaze me that I tell a yak-herder my BGP failures, > > forcing local path selection, with no subsequent alteration in routing of > > concern to them, *and we're not even shipping packets* > > > > Tony Hain amongst others proposed models of geographic and scoped > > assignment which were shot down in flames by the usual suspects. Because > > its "not how we do it now" people don't like talking about this sensibly, > > but there are rational models of address management which preserve BGP like > > behaviour, but don't expose all routing decisions globally, that only have > > local meaning. > > > > G > > > > > > > > On Fri, Nov 13, 2015 at 5:53 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> Please let's not pretend we're discussing the ULA draft any more. > >> > >> On 13/11/2015 07:32, Owen DeLong wrote: > >> > >> ... > >>> How is a /48 PI hard to acquire? Where? > >> > >> As others have implied, that isn't the point. The point (and I expect > >> we had this argument on the RRG list some years ago) is that we can't > >> put 10,000,000 /48 entries into BGP. So if we go around encouraging > >> all small enterprises to get a PI prefix we are all doomed. > >> > >> Brian > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > --001a114584da3510420524618d01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Since I work in the governance side, I have to be clear th= at I have no voice in policy in RIR land, this is just my personal opinion.=

    But my personal opinion is that we are not facing a CIDR scale prob= lem in this niche, and probably don't need to act like we are.

    = My reason is simple: CIDR was about exhaustion as much as about routing. We= have only half the problem, and even that is (in my opinion) tendentious. = We *may* have half the CIDR problem, but its a may, not a *do*. -Therefore,= applying CIDR logic to the address management process in V6 is not (yet) j= ustified.

    Contrariwise, we have an uptake problem. We should be enco= uraging uptake of IPv6, and if pushback from network-literate SME's is = that they are concerned about capture behind a PA then we should admit PI p= rocesses, and not be over-pessimistic about the cost in future routing term= s of PI to SMEs

    Rather than asking BGP/Router people &qu= ot;can you make a router now for 100m prefixes" we should be saying &q= uot;if we can forsee 100m prefixes in 5-10 years time, can you get there, a= nd if not, what models of prefix management would work for you"
    <= div>
    I think this is a corollary of what John Scudder did in = IEPG: we need the conversation with the ASIC people to be framed the right = way.

    -G


    On Fri, Nov 13, 2015 at 10:34 A= M, Brian E Carpenter <bri= an.e.carpenter@gmail.com> wrote:
    >
    > On 13/11/2015 13:20= , George Michaelson wrote:
    > > I'm sorry Brian, but as I said = in another reply, this is just specious.
    > > It's true in as m= uch as IF all SME's wound up in BGP we'd have a heat-death
    > = > problem.
    > >
    > > But a) they won't arrive tomorr= ow, or next year: it takes time, =C2=A0and b)
    > > other solutions = to routing will emerge.
    >
    > No doubt. But Mark is correct: we h= ave to defer the crisis until the solution
    > is available. We deferre= d it once by introducing CIDR 20 years ago. Encouraging
    > PI for all = customers is antiCIDR, and that's a problem.
    >
    > =C2=A0 =C2= =A0Brian
    >
    > > Like, giving them scoped /48 out of
    > &= gt; a block which has export limits under some covering prefix, and limits = the
    > > local visibility of their BGP independence to within some = constrained
    > > context.
    > >
    > > It never ceases= to amaze me that I tell a yak-herder my BGP failures,
    > > forcing= local path selection, with no subsequent alteration in routing of
    > = > concern to them, *and we're not even shipping packets*
    > >= ;
    > > Tony Hain amongst others proposed models of geographic and s= coped
    > > assignment which were shot down in flames by the usual s= uspects. Because
    > > its "not how we do it now" people d= on't like talking about this sensibly,
    > > but there are ratio= nal models of address management which preserve BGP like
    > > behav= iour, but don't expose all routing decisions globally, that only have> > local meaning.
    > >
    > > G
    > >
    >= >
    > >
    > > On Fri, Nov 13, 2015 at 5:53 AM, Brian E Ca= rpenter <
    > > br= ian.e.carpenter@gmail.com> wrote:
    > >
    > >> Plea= se let's not pretend we're discussing the ULA draft any more.
    &g= t; >>
    > >> On 13/11/2015 07:32, Owen DeLong wrote:
    >= ; >>
    > >> ...
    > >>> How is a /48 PI hard t= o acquire? Where?
    > >>
    > >> As others have implied,= that isn't the point. The point (and I expect
    > >> we had = this argument on the RRG list some years ago) is that we can't
    > = >> put 10,000,000 /48 entries into BGP. So if we go around encouragin= g
    > >> all small enterprises to get a PI prefix we are all doom= ed.
    > >>
    > >> =C2=A0 =C2=A0Brian
    > >>> >> _______________________________________________
    > >= ;> v6ops mailing list
    > >> v6ops@ietf.org
    > >> https://www.ietf.org/mailman/listinfo/v6ops
    > &= gt;>
    > >
    --001a114584da3510420524618d01-- From nobody Thu Nov 12 17:10: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 E49C21B3BFE for ; Thu, 12 Nov 2015 17:10:41 -0800 (PST) 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 5uZBs7vLcnkQ for ; Thu, 12 Nov 2015 17:10:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id CDB651B3B9D for ; Thu, 12 Nov 2015 17:10:39 -0800 (PST) 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 tAD18bYv014088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 17:08:37 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151113005106.6B9023C9A578@rock.dv.isc.org> Date: Thu, 12 Nov 2015 17:08:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9E70736D-3FB2-44DA-BC45-9CFF327CBE4E@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> <20151112225306.BBA8A3C99209@rock.dv.isc.org> <20151113005106.6B9023C9A578@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 01:10:42 -0000 >> This is actually a lower likelihood of collision than I get with ULA. >>=20 >> True, if I chose something within 2000::/3, I know I=E2=80=99m likely = to collide >> with some >> unknown thing that expects their addresses to be globally unique. >>=20 >> Also true that at some future date, my f3fe:: address may come to = collide >> with >> some future IETF decision at which point I _MAY_ have to remove the >> prefix. >=20 > So you just want a random free for all. Guess what it costs to clean > up the mess that produces. We are going through the process of = dealing > with the mess of people thinking that the DNS root was a free for all > despite it not being one. No, not advocating doing this, just pointing out that it has little = difference from ULA. >>> Additionally we have deployed technology for nodes to update their >>> addresses in the DNS which deals with most of the renumber problem. >>=20 >> Not sure how this is relevant, but whatever. >=20 > Then you are not @#$!# paying attention. Sure I am. The fact that I don=E2=80=99t agree with you and don=E2=80=99t = share your perspective doesn=E2=80=99t mean I=E2=80=99m not paying attention. >>> A 1 page BCP which says to do what Apple and various router vendors >>> have been doing for years updating the DNS should be enough to get >>> the rest to do this. >>=20 >> Again, not sure how this is relevant to the utility (or lack thereof) = for >> ULA. >>=20 >>>>> I think that if (a) was the only choice, it is in effect creating = an >>>>> annual tax or license fee on the use of IPv6 technology, because = (in >>>>> theory) you wouldn't be able to use IPv6 unless you paid an RIR = and >>>>> waited for them to give you your space. Of course, the other = choice >>>>> would be that some people would steal space to use instead to = build an >>>>> IPv6 network, like the documentation prefix. Absence of a local = use >>>>> address space encourages stealing of other address spaces if you = don't >>>>> have time to get a proper one or don't have the financial means or >>>>> financial incentive to get some. >>>>=20 >>>> Im all for providing a lower cost alternative to having a = legitimate >>>> registry for addresses for smaller users. >>>>=20 >>>>> Humans don't incur costs on themselves unless they see or perceive >>>>> some equivalent benefit. Making something available for "free", in >>>>> this case a local yet globally unique network address space, >>>>> significantly lowers the barrier to IPv6 adoption. If you've = bought >>>>> the equipment to build your network, and it comes IPv6 enabled for >>>>> "free", you can then immediately build an IPv6 network using ULA >>>>> space. >>>>=20 >>>> Except that ULA isnt globally unique, its just probably unique for >> various >>>> relatively high values of probably depending on how you go about >> choosing >>>> your ULA prefix. Were ULA globally unique, youd have the double = edge >> sword >>>> of: >>>>=20 >>>> 1. Its good because its free PI address space. >>>> 2. Its bad because its a free end-run around the RIR policy >>>> processes. >>>=20 >>> And that matters how? If you happen to learn a remote ULA address >>> and actually use it the border router should block the packet and >>> send back a ICMP administrively prohibited unreachable. If there >>> is a ULA prefix collision you still have to match the rest of the >>> address which is highly unlikely. Subnet collisions in this case >>> are likely but not the full address. >>=20 >> Why? There are circumstances where the border router may actually = intend >> to exchange packets with some other person using that same ULA = prefix. >=20 > And border routers can actually talk to two or more sites using the > same ULA prefix today. This isn't rocket science. The api's to > do this exist and are in use. It just takes a little care. The > concept of the site boundary being through the middle of a box and > the same prefixes being in use on multiple sites has been part of > IPv6 from just about the very begining. If your border router can't > handle this file a bug report because it is broken. >=20 > Now if you want to route between ULA's using the same prefix then > you have problems but it is easy to generate new ULA prefixes that > don't collide and to then stop using the ones that collided. I didn=E2=80=99t say anything about this=E2=80=A6 My point was that your = claim that a border router should never forward a ULA packet was patently false and you just proved my point. >=20 >> ULA is just like RFC-1918 except it provides a greater illusion of >> utility. It still >> offers all the same problems, just in a less constrained and >> (potentially) harder >> to identify way. It does offer a greater timeline and potential for = the >> creation >> of time-bomb configurations that work at the time of installation and >> then break >> spectacularly at some future date due to the collision of earlier >> decisions on two >> networks that later find themselves connected in places far removed = from >> where >> those decisions were made. >=20 > There is no time bomb. Only the illusion of a time bomb. Only if you have fully coordinated ULA which there is no supporting RFC = to provide. Sure there are an assortment of ULA registries out there (which = do happen to in several cases already collide with each other), but short = of the two sites that later collide using the same registry, yes, there is an = actual time bomb. Owen From nobody Thu Nov 12 17:47: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 4AA3E1A00C0 for ; Thu, 12 Nov 2015 17:47:50 -0800 (PST) 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, 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 wctJai8fZlFg for ; Thu, 12 Nov 2015 17:47:49 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id D16911A0093 for ; Thu, 12 Nov 2015 17:47:48 -0800 (PST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 12 Nov 2015 19:47:47 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f175.google.com [209.85.223.175] #+LO+TS+TR X-Umn-Classification: local Received: by iouu10 with SMTP id u10so76758451iou.0 for ; Thu, 12 Nov 2015 17:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Hqjr+u2vWAQHRPn8R9/gclfzQTO3+4s4Z6qBLXJ/u28=; b=bBrYQrahST9ULOWRsyWzwL6lTi4EKRqJ1Gu1qDTY8NMbmh+eZYaLPazsjp3uzK88oo +fHW8u+x3PGUQLbDzL2nR3t1GmVuicCRaQ42g3t5plBauBIycreuR95+aCUQKWBkogH4 VfTBVl5rtutMJQATYCnxaJ9V64SEcDVlTKO3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=Hqjr+u2vWAQHRPn8R9/gclfzQTO3+4s4Z6qBLXJ/u28=; b=CN7e4PCAnVCbgPbr9JsS55zppxaM5hHqmkC96w3+vRYPgzt501It1ZkGzWBFccdUkg dIYDFeyHzl8Y+9cIBL++beW7L8khoHuABS2XxytpKC6TDsfZ22IbLGpYfiDWk0RpIzZb B7AszSBn1T5yhyek3r97L/516IAVvGD+jR8hrj9JGc+2ihA+5f74sM+ar67YSmOHDxbt YscIQEvzq02Lfxts/Y+nxRgvM5r09cLkkQQfNBGQQ36XUKTSGQ5cbYlzZTUtNFvDz0A/ 00AMQcxo3VGjpe854zskuou15SFo884EgL7eLO7iNJqud5S3mWtx8psqgeq8l7zC4svP kTNA== X-Gm-Message-State: ALoCoQkp7hLNVvENWD34ewpap5VpFj3X6/MeJW/6SGvlD6dMb1A6adrBwMbB5ZEljc5Otp+iECjFKeCVzqhaOsF5SQe0U04aYmf+3SMjKxj7couFz4irTSlvpxvZvGSKQmjzP6qDuh9D X-Received: by 10.107.138.147 with SMTP id c19mr20977102ioj.82.1447379267159; Thu, 12 Nov 2015 17:47:47 -0800 (PST) X-Received: by 10.107.138.147 with SMTP id c19mr20977071ioj.82.1447379266757; Thu, 12 Nov 2015 17:47:46 -0800 (PST) Received: from x-10-104-143-49.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:acf3:67c9:59a9:b079]) by smtp.gmail.com with ESMTPSA id l41sm6062288iod.34.2015.11.12.17.47.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 17:47:44 -0800 (PST) References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> To: Mark Andrews , Owen DeLong From: David Farmer Organization: University of Minnesota Message-ID: <5645413E.7020308@umn.edu> Date: Thu, 12 Nov 2015 19:47:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151112214819.4EDE63C98D83@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 01:47:50 -0000 On 11/12/15 15:48 , Mark Andrews wrote: > And how many SME's are there in the world? This paper [1] puts the > number at 125M MSME world wide. That's 125M routing slots if > everyone gets a /48. > > Mark > > [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES Flipping that around, how many Large Enterprises are there in the world? I found about 16K for the US. So, expand that globally, that shouldn't be insane to think about for the number of PI blocks in the global IPv6 route table. Like has been said they won't happen all at once and I sure even some of them will do PA anyway. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Nov 12 18:11: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 BF4651B3EC2 for ; Thu, 12 Nov 2015 18:11:48 -0800 (PST) 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 4O-5dur2k4nW for ; Thu, 12 Nov 2015 18:11:48 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 C47A51B3EC1 for ; Thu, 12 Nov 2015 18:11:47 -0800 (PST) Received: by ykdv3 with SMTP id v3so125549145ykd.0 for ; Thu, 12 Nov 2015 18:11:47 -0800 (PST) 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=htzymbdWZAdfZxAbFNDeUeOMGTHohcZe99FRSUCZM98=; b=Q6XKSeRk/htihFLxTrc5eROQJHL/4VO1KY99vfcqHDgz0b32q3kYt19egNafBngnKD w6q15Thjjy0S5dEoJ5gZhuiBFp733JXU1MjXJUdvQw++ubo6Yae0LthuPwKyPa9/VY0h yb0fmEp0wHXntwBy/oVf+UYdHlTZmovQ1Y2YsM+3IGJq/XC5JJa2yCzGAt5tSrGPMIUZ fpuqf7ZyoShFiFZRo2xKLdoha+x+jYhzZJ2gh7wf8uef3Tqq4aa4Oks0ZSradpz2nEzd VnKpC0nXftHFi0MmmcGcSo5hslqoX11vQ/1ax2kSQVmRfgik+4G1edZdx3soskkvqbTU UwXw== 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=htzymbdWZAdfZxAbFNDeUeOMGTHohcZe99FRSUCZM98=; b=OGNm3nXWhuv58zh2DywDi7fSh+17hPYP21qcmuCvKLybY1HLyn2Fv++sbRBwp7RaBm 7BIIAlesCumUwMIAVLjopv9eZx/s/ulaOLRcjqnASJTGMYY19GKY4tObIz3GWr2s5YVZ E85p4v9j4PxKaE93dKX7tbVge4nN4s0pSzZpA01q8DeMvbqJp3v+aqrN0mJhGOeH72Y9 sfFYicBwkzKgTgIzlHgMZtswCRVPc0uFsnzdZMaPDW7xaQtQcEFFuQfe0L4zyll1rXNe lvaQsftWHKgXi8zNKTFvStyxlRutLOGEZXpXBdoTDuTDUFs68ZhfUg1SAtnr/vzHfFnx KYUQ== X-Gm-Message-State: ALoCoQlsyRZsazud/huu8k1c5FkFr0sLodb35tMyvgPLFZlNqMe9RizqWNCqk8kn3WNqJKESDVza X-Received: by 10.129.153.198 with SMTP id q189mr19898104ywg.337.1447380707012; Thu, 12 Nov 2015 18:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 18:11:27 -0800 (PST) In-Reply-To: <56453026.3090607@gmail.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 11:11:27 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c0b7316e62fe005246294c0 Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 02:11:48 -0000 --94eb2c0b7316e62fe005246294c0 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 9:34 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > No doubt. But Mark is correct: we have to defer the crisis until the > solution > is available. We deferred it once by introducing CIDR 20 years ago. > Encouraging > PI for all customers is antiCIDR, and that's a problem. > The solution is there - it's multihoming using src+dst routing. This is what we should be recommending. --94eb2c0b7316e62fe005246294c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 9:34 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
    No doub= t. But Mark is correct: we have to defer the crisis until the solution
    is available. We deferred it once by introducing CIDR 20 years ago. Encoura= ging
    PI for all customers is antiCIDR, and that's a problem.

    The solution is there - it's multihoming using src= +dst routing. This is what we should be recommending.
    --94eb2c0b7316e62fe005246294c0-- From nobody Thu Nov 12 18:27: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 431FE1B3EDD for ; Thu, 12 Nov 2015 18:27:34 -0800 (PST) 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 6a2ItIFB2yrc for ; Thu, 12 Nov 2015 18:27:33 -0800 (PST) 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 0D5F61B3EDB for ; Thu, 12 Nov 2015 18:27:33 -0800 (PST) Received: by pacdm15 with SMTP id dm15so84033311pac.3 for ; Thu, 12 Nov 2015 18:27:31 -0800 (PST) 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=JhFeeNuZ9vRlqIcASLuvot3nA0LnkLJy8sUgrc+62UE=; b=KReh1G2tjsphpv7Ki1WBa5fBA7wGCvx1XC0KLriWd1FnQxUnuNhY1yslgTuYe06R3v zv2Y8kiB0UodSPjmwTBK5bVfGhLL38vIXpXJQQoIas2PXCmZShCwG6sysSVTQMzfPoKG R5Tl+0Mq5LhmzSU1BdNnshwGoy6Jzo31Z/3zDmGp22HZBgjbouoky/u6guNlL8jkegYB LgH6zRFLd5o3kHr0xuyEE2C8xNWzc3I0S2YgdkfqVzRSeRFmmY2nd9R9sBZsXnupLut2 PScMLYDmji5+AMEebNK3g6Czga16WJGb94iTlPv8AdRo1zHe2ygWZKleN48F+04sgzhC 5dAQ== X-Received: by 10.68.92.194 with SMTP id co2mr28064643pbb.125.1447381651594; Thu, 12 Nov 2015 18:27:31 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id kj3sm17119013pbc.59.2015.11.12.18.27.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 18:27:30 -0800 (PST) To: Lorenzo Colitti References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56454A98.1000305@gmail.com> Date: Fri, 13 Nov 2015 15:27: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 02:27:34 -0000 On 13/11/2015 15:11, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 9:34 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> No doubt. But Mark is correct: we have to defer the crisis until the >> solution >> is available. We deferred it once by introducing CIDR 20 years ago. >> Encouraging >> PI for all customers is antiCIDR, and that's a problem. >> > > The solution is there - it's multihoming using src+dst routing. This is > what we should be recommending. Like draft-ietf-6man-multi-homed-host does, you mean? I can't possibly disagree ;-) Brian From nobody Thu Nov 12 18:33: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 7D8F31B3EF2 for ; Thu, 12 Nov 2015 18:32:56 -0800 (PST) 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 4VJrRcRGtJ-F for ; Thu, 12 Nov 2015 18:32:55 -0800 (PST) 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 0A3571B3EEC for ; Thu, 12 Nov 2015 18:32:55 -0800 (PST) Received: by pacdm15 with SMTP id dm15so84183393pac.3 for ; Thu, 12 Nov 2015 18:32:54 -0800 (PST) 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=SWCuSJl2B0GTBi0XTAHFml3PNZh4LNlTf2FkQpD8v9Q=; b=pmFtMh3HuEI/9PfhfiUemyUvIddb8QNPl/SyUFXPvd+H37Bbs6tUTAjdHETSowBTKU T2LmD/JpCS7weROpVXbn9xs98sMx1T5dn9o9BgnajkYrhxeoDWqus3AVEND2MrKtwjV8 owOJpoO8bc5cLXStvAAswQFgfqvVzvbL9JdpmUMjjiMnrHhDRSe2U8y0N28zs4pLk4Yy EqzQl9WEmf7i0ugB38iM0fCqpL1U5Z9NUDVyvRM/+kYJjYW37QBwmdPxiZwT7If38Ld8 ooFmh06Yh6hIxBHuCR+cL/G5If5rfL7b3e8MuFGvIUAiBk+Z6pKUpXRiCzUk3WRVoxhO mL2A== X-Received: by 10.66.234.133 with SMTP id ue5mr27946769pac.56.1447381974706; Thu, 12 Nov 2015 18:32:54 -0800 (PST) Received: from ?IPv6:2406:e007:58dd:1:28cc:dc4c:9703:6781? ([2406:e007:58dd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id mt2sm12658251pbb.90.2015.11.12.18.32.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 18:32:53 -0800 (PST) To: David Farmer , Mark Andrews , Owen DeLong References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <5645413E.7020308@umn.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56454BDB.3030805@gmail.com> Date: Fri, 13 Nov 2015 15:32:59 +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: <5645413E.7020308@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 02:32:56 -0000 On 13/11/2015 14:47, David Farmer wrote: > On 11/12/15 15:48 , Mark Andrews wrote: >> And how many SME's are there in the world? This paper [1] puts the >> number at 125M MSME world wide. That's 125M routing slots if >> everyone gets a /48. >> >> Mark >> >> [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES > > Flipping that around, how many Large Enterprises are there in the world? I found about 16K for the US. So, expand that > globally, that shouldn't be insane to think about for the number of PI blocks in the global IPv6 route table. > Absolutely not, a few hundred thousand PI prefixes are not very alarming. It's when we get to millions that PI becomes a possible heresy. Brian > Like has been said they won't happen all at once and I sure even some of them will do PA anyway. > From nobody Thu Nov 12 18:36: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 09C2A1B3EC9 for ; Thu, 12 Nov 2015 18:36:31 -0800 (PST) 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 qVAf5LTaFfMI for ; Thu, 12 Nov 2015 18:36:29 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 612651B3EF1 for ; Thu, 12 Nov 2015 18:36:29 -0800 (PST) Received: by ioir85 with SMTP id r85so44393741ioi.1 for ; Thu, 12 Nov 2015 18:36:28 -0800 (PST) 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=GxRAD0RTtg1g4ASkRtSozoqnPUUAtQDTY5k0WizwbYo=; b=gzXU1PlIWr67cYBzV5fsaC1iwdvTy0VLMZ9gT19KZzZzJk/F0epKjLKC6fqE15yAOv heS4d83EQBeC6QldGvBuF7kor0KDK3ZO3mgEXs9FBpxvfy34sgLmKCRRvZpGRmYNdtnn XVtBiWsdcNfwOYYzPJ2zvwN7xZ1lEqe65Nmu30YIMljPCSeM/+RBxMPoSsYRfCGTFrLj ksdriQI+vtSBl2Zcw8UBJ3+lDBVjAXt+VLPxf8QcMBJbwUK2Z3LfRI/KPIy6YtbcDaQ+ XpkdJqxQKflOxp+o5GvdZ2rridUjZ6fSYm+T3J4PHlzMJISOeyyJ9x+3M1RZmqiQ3gBq oddQ== MIME-Version: 1.0 X-Received: by 10.107.184.9 with SMTP id i9mr2815658iof.4.1447382188042; Thu, 12 Nov 2015 18:36:28 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.47.217 with HTTP; Thu, 12 Nov 2015 18:36:27 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 12 Nov 2015 18:36:27 -0800 X-Google-Sender-Auth: QGujrLBU-d9PsZl2B-XXAsy-soI Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 02:36:31 -0000 At Mon, 9 Nov 2015 19:59:30 +0000, "Templin, Fred L" wrote: > 3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN interface. > Again, 'N' does not do DAD on the WAN interface because (again) 'P' is not > assigned to that interface. > > > I don't think this is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses). > > FLT>>> RFC4862 says: > FLT>>> - An interface whose DupAddrDetectTransmits variable is set to zero > FLT>>> does not perform Duplicate Address Detection. > FLT>>> This shows that the node has latitude in when it can deem DAD as unnecessary > FLT>>> for a given interface. In this case, the address A is not matched by a prefix in the > FLT>>> Prefix List for the WAN interface and it is known that the prefix will never > FLT>>> never be added to the Prefix List for the WAN interface by node N nor any > FLT>>> node on the WAN link. I think I understand what you are trying to say, and I tend to agree that it would be quite unlikely that someone else than node 'N' is using address 'A' in the WAN link in practice in this scenario. However, I think it's dangerous to just jump to the conclusion that DAD is not necessary in this case in some kind of standard document. In my understanding, DAD is designed to cover "quite unlikely scenarios" including cases with some broken implementations/operation. In this particular scenario, I would say that the original intent of DAD covers an "unlikely" case where the remote (or some other, depending the type of link) node of the WAN link is broken or some invalid operation and is actually using address "A". I would not necessarily be opposed to the idea of allowing this particular use case to set DupAddrDetectTransmits to 0, but I don't think we can casually say so in draft-ietf-v6ops-host-addr-availability. IMO, that would require a separate standard track document that updates RFC4862 with providing sufficient rationale of why this can be considered an exception (and why it's that important). -- JINMEI, Tatuya From nobody Thu Nov 12 18:55: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 33C261B3F14 for ; Thu, 12 Nov 2015 18:55:08 -0800 (PST) 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 icW_upF3_IcU for ; Thu, 12 Nov 2015 18:55:07 -0800 (PST) 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 03C111B3F13 for ; Thu, 12 Nov 2015 18:55:07 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1Zx4Vv-0007hC-QB; Fri, 13 Nov 2015 03:55:00 +0100 To: Lorenzo Colitti , "Eric Vyncke (evyncke)" References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <564537A7.90102@si6networks.com> Date: Fri, 13 Nov 2015 10:06:47 +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: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 02:55:08 -0000 On 11/13/2015 09:10 AM, Lorenzo Colitti wrote: > On Tue, Nov 10, 2015 at 11:13 PM, Eric Vyncke (evyncke) > > wrote: > > It is only 'slightly' easier... Because guessing the TCP sequence > number of the other party... Well good luck :-) > > > The sort of application that tries to do this doesn't typically use TCP. You still need to guess the port numbers. And if you're able to, that's a sign there's something you still need to fix (see RFC6056). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Nov 12 18:55: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 78A411B3F13 for ; Thu, 12 Nov 2015 18:55:08 -0800 (PST) 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 gMPvrvXbMft8 for ; Thu, 12 Nov 2015 18:55:06 -0800 (PST) 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 2F0C41B3F12 for ; Thu, 12 Nov 2015 18:55:06 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1Zx4Vr-0007h4-6R; Fri, 13 Nov 2015 03:54:55 +0100 To: Owen DeLong References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <28EECB50-9F5F-4F47-95EB-86BD5E9A9C72@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56453712.4030209@si6networks.com> Date: Fri, 13 Nov 2015 10:04:18 +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: <28EECB50-9F5F-4F47-95EB-86BD5E9A9C72@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 02:55:08 -0000 On 11/13/2015 03:05 AM, Owen DeLong wrote: >>> They still work fine on networks that >>> operate the way the Internet was originally designed with end-to-end >>> connectivity. >> >> not sure what you mean by "end-to-end" connectivity. > > I won’t speak for Lorenzo, but what I mean when I talk about “end-to-end” > is the situation where the L3 packet that leaves the origin host arrives > at the destination host without being modified except for certain fields > intended to be modified in flight. (Namely TTL/Hop Count, L2 and lower > layer fields, etc.). Certainly the L3 and higher layer identifiers are not > to be tampered with in flight. FTP PORT doesn't work fine in firewalled environments. It requires a middlebox to tap into the FTP control protocol so that the fw can open the necessary holes. -- So the only networks where FTP PORT works fine is un-NATed, unfiltered networks -- which is kind of Wonderland. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Nov 12 18:55: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 C81511B3F1D for ; Thu, 12 Nov 2015 18:55:17 -0800 (PST) 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 W61fKUGZJJAY for ; Thu, 12 Nov 2015 18:55:16 -0800 (PST) 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 746C51B3F1C for ; Thu, 12 Nov 2015 18:55:16 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1Zx4W6-0007hw-JM; Fri, 13 Nov 2015 03:55:10 +0100 To: Owen DeLong , "Eric Vyncke (evyncke)" References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56453C96.7070509@si6networks.com> Date: Fri, 13 Nov 2015 10:27:50 +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: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 02:55:18 -0000 Owen, On 11/13/2015 03:21 AM, Owen DeLong wrote: > >> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) > > wrote: >> >>> Nope. It is much easier to establish a connection across a diode >>> firewall than to establish one across a NAT. In the former case, all >>> the endpoints need to do is send each other packets at about the same >>> time. In the latter, they need to implement NAT traversal via relays. >> >> It is only 'slightly' easier... Because guessing the TCP sequence >> number of the other party... Well good luck :-) > > With a diode firewall, you don’t have to guess. Most diode firewalls > don’t look at TCP sequence numbers actively. They look only at the L3 > and L4 identifiers to determine state. > Some look at SYN bits and toss SYN packets going in the wrong direction, > but most just look for an ACK bit. > > Nonetheless, it’s also much easier because a diode firewall can easily > be given an exception to permit a particular flow or the initiation of a > class of flows to a particular protected host or set of hosts. The problem is how to do this automagically. > In the case of a NAT, however (more specifically a NAPT), it is not > possible to program multiple port 80 terminations to land on different > hosts behind the NAT. That's like saying that the problem with cars is that they cannot fly -- yes, that's what a NAT is. I might also add that this is another kludge that is made evident by NAT: there's no reason whatsoever for which a given service should run in any specific transport protocol port. Consider that a kludge or shortcut than a principle. > I retain my perspective that one of the worst and most ultimate forms of > layering violation is for a forwarding system not residing on either of > the end-hosts in a session to impersonate an end-host and mutilate > unexpected portions of the datagram in flight. I might grant that one if you want. But virtualy everything that you mentioned that NAT breaks are shortcuts (or flawed design) rather than "principles" we should stick to. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Nov 12 19:00: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 D253D1B3F17 for ; Thu, 12 Nov 2015 18:59:58 -0800 (PST) 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 5-IJRkm4AqgS for ; Thu, 12 Nov 2015 18:59:58 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 D4DBC1B3F09 for ; Thu, 12 Nov 2015 18:59:57 -0800 (PST) Received: by ykba77 with SMTP id a77so126473496ykb.2 for ; Thu, 12 Nov 2015 18:59:57 -0800 (PST) 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=ctevwOAz8TiGPJAUJIIUBt4770Yq6OOeYodJKhCJT1g=; b=DhRMyNTbxg/dI6ggM+uK0fQA/IWjvDxdJG+47u2zTcEnr+fbGfyPxuZumcnTAoqOH/ RhTt0UH2Ieqg53XC/2jl3xfhJzg+sFjM+S2iiVhmdmH7XICHC+XFdwwbW+FQ+kbtUAoS UEGIBs9wITwZL+OROOoB+1MzvgxftCukAQ25p9YjjObgpsjjDtf4ZgfRKQdVu9LAVRRc 2t4g8I89/Y4PVKSSwpi3IGw5muhV+PB4Cx5XVI3YrKA3+04kgSh8qptCmd6N2xJ4ymw4 jkGa+Fh9sSBPd2odEkks7vQa+MFURgO4UQNgi3FaJXrlO9IhLhQOiyZ1j4FO86tBkID9 uT+A== 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=ctevwOAz8TiGPJAUJIIUBt4770Yq6OOeYodJKhCJT1g=; b=dFBAyOqGysaRWcwQpGqezZFA18wJBHH0QswqTb4MHFPt5S89MDKxHZeNp0ROxovzTO ccmF9HOmQqMxk42fmu4aA9GvYmK76ZF3tiNz0oX189B+GdfmHoDsfpCEwju+LMGMisYg e4VubgNCt0F0DdK0+j9yEU6ZJPLzGARbwuGhRRItZDjRIHsPhAPCSfIo+EUiiTV3CHAt mdBc8BHgA0dcsFYwt5K/qUst9dsQ8an3UHQ0N4UQjekGE/JH6Vf7ZiwfiepZX3YP75ko GIBDHpQ0K+d4DokV6LKjc22bzBL74DnWQwVtWZ0wxClNdrO6JsYcc9VOopvZTCHygBHR aW2w== X-Gm-Message-State: ALoCoQkVuxy6VsJAYYOwSNqLB1+WR8TIF0StRByYI1RjasPcl+PZpSeHo0PlxXxlYVmcpmo+EWid X-Received: by 10.129.78.86 with SMTP id c83mr3243777ywb.116.1447383597063; Thu, 12 Nov 2015 18:59:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 18:59:37 -0800 (PST) In-Reply-To: <564537A7.90102@si6networks.com> References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 11:59:37 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114db4d828bb5b0524634198 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 02:59:59 -0000 --001a114db4d828bb5b0524634198 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 10:06 AM, Fernando Gont wrote: > > The sort of application that tries to do this doesn't typically use TCP. > > You still need to guess the port numbers. And if you're able to, that's > a sign there's something you still need to fix (see RFC6056). The port numbers are no more a guess than the IP addresses are. Whatever told you the IP addresses can also tell you the port numbers. --001a114db4d828bb5b0524634198 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a114db4d828bb5b0524634198-- From nobody Thu Nov 12 19:07: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 EFF5E1B3F29 for ; Thu, 12 Nov 2015 19:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 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, 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 3tvXHdofK_eZ for ; Thu, 12 Nov 2015 19:07:16 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 514F01B3F28 for ; Thu, 12 Nov 2015 19:07:16 -0800 (PST) Received: by ykdv3 with SMTP id v3so127195441ykd.0 for ; Thu, 12 Nov 2015 19:07:15 -0800 (PST) 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=BvHKjUkjtF65UpHlb/YC058HZx+HQgeXcJWJqCzcnP8=; b=PwoEo+xR3vuQxMW148tsZhagWpC0WnAu6rtKk7aN4tRy6IfdcCGMzmk2I/aVZXWd0y HW2FV2yAdZx/ddQiQqBv4xJGJU20WG0JvsQ6iEBM1LlBu/wZniHcM/gv6aOWCyrX9VlL iJ7MrtvRvMYTW3VPtluSSwamDSUknX0s1uSvU1JHUqVpmQ8PdcPKJXGwL/B31SS2qVN6 /x1E9LpEk5iQd5ZJCYfezvj6bxpR1B9RM2EDBxDhNU/OJi5gXySZvFEdlXGyERZ7tLy3 H3DtGAqHQ+MW/CIxr3DEkGCWSJlxFlyVq5lx40RSp2/MQsrziVmK+gfz0s2Hj5k63hjV xpoQ== 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=BvHKjUkjtF65UpHlb/YC058HZx+HQgeXcJWJqCzcnP8=; b=WK3ubSRtPYMdniWxG5H0oRe+yojrWPY2t5ezJvx6w0C//5xpVWyTK8e8RKv5MRXq7D zTrRvLuJAA7ahkAPEURMrZeW2zWb5bvIGZ9MyQXxLsWn1J9pXFLxukPCznZ2Fr8QjaF2 jRpOU3IXOJ09gc7EF0Hctu5iyn3r4ZvyhV7xAdB0js7mQK85dX282bbl1JjumoNWXt75 whacq6iKKFhySkvYwi6TD0rWI0jy2VNAybeNeBSzNxR6NfS7rNsqmxXWreZXtyut5cLO ActdSjuYoTgUtcqExSB3vO7CMl18hm/fdLaLZuy8kexupBoYKd0jsOpT/m3++ULvXhtw ekfA== X-Gm-Message-State: ALoCoQlmmI9Z3B8oCrt7rXG85ndduKH9EKgzG4LlJwSVSrymOt/0EG/PC5g8y0zRsKOOgnCDyL/E X-Received: by 10.129.136.5 with SMTP id y5mr20051388ywf.35.1447384035434; Thu, 12 Nov 2015 19:07:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 19:06:55 -0800 (PST) In-Reply-To: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 12:06:55 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a114effba49d1880524635bd2 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 03:07:18 -0000 --001a114effba49d1880524635bd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2015 at 11:36 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I think I understand what you are trying to say, and I tend to agree > that it would be quite unlikely that someone else than node 'N' is > using address 'A' in the WAN link in practice in this scenario. > However, I think it's dangerous to just jump to the conclusion that > DAD is not necessary in this case in some kind of standard document. > In my understanding, DAD is designed to cover "quite unlikely > scenarios" including cases with some broken implementations/operation. > In this particular scenario, I would say that the original intent of > DAD covers an "unlikely" case where the remote (or some other, > depending the type of link) node of the WAN link is broken or some > invalid operation and is actually using address "A". > RFC 4862 is says: Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface. That is true in almost all cases, including DHCPv6 PD. For example, if a device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi hotspot, then any address that the device itself forms out of that /64 MUST perform DAD so that other devices connected to the wifi hotspot do not use the same address. At most we could slightly amend this to ..."MUST be performed on all unicast addresses prior to assigning them to an interface except a loopback interface". Even node-internal interfaces are not necessarily safe to omit DAD on. For example, in a mobile device the application processor and baseband processor might both be on the same link, and because they are two separate processors running two separate network stacks, they need to do DAD. --001a114effba49d1880524635bd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 11:36 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei= @wide.ad.jp> wrote:
    I think I understand = what you are trying to say, and I tend to agree
    that it would be quite unlikely that someone else than node 'N' is<= br> using address 'A' in the WAN link in practice in this scenario.
    However, I think it's dangerous to just jump to the conclusion that
    DAD is not necessary in this case in some kind of standard document.
    In my understanding, DAD is designed to cover "quite unlikely
    scenarios" including cases with some broken implementations/operation.=
    In this particular scenario, I would say that the original intent of
    DAD covers an "unlikely" case where the remote (or some other, depending the type of link) node of the WAN link is broken or some
    invalid operation and is actually using address "A".

    RFC 4862 is says: =C2=A0 Duplicate Address Detectio= n MUST be performed on all unicast addresses prior to assigning them to an = interface.

    That is true in almost all cases, inclu= ding DHCPv6 PD. For example, if a device gets a /64 via DHCPv6 PD, and shar= es that /64 via a wifi hotspot, then any address that the device itself for= ms out of that /64 MUST perform DAD so that other devices connected to the = wifi hotspot do not use the same address.

    At most = we could slightly amend this to ..."MUST be performed on all unicast a= ddresses prior to assigning them to an interface except a loopback interfac= e". Even node-internal interfaces are not necessarily safe to omit DAD= on. For example, in a mobile device the application processor and baseband= processor might both be on the same link, and because they are two separat= e processors running two separate network stacks, they need to do DAD.
    --001a114effba49d1880524635bd2-- From nobody Thu Nov 12 19:24: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 CC5481B3F4F for ; Thu, 12 Nov 2015 19:24:41 -0800 (PST) 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 ZLtV_lkRps-q for ; Thu, 12 Nov 2015 19:24:41 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 DDD281B3F4E for ; Thu, 12 Nov 2015 19:24:40 -0800 (PST) Received: by ykfs79 with SMTP id s79so127883855ykf.1 for ; Thu, 12 Nov 2015 19:24:40 -0800 (PST) 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=OLFJr8ns+gcYCw9lAlgR7mP1haE7unlByWNbTytq+Mk=; b=lulZmqZX2U4KbSrmZI7pmEGwjFM3tlzmOXxQpt8SaqREIYwF3Fd0kfhRfeQQHnNKrm W2qvJISsasklXnkNSkp+t7P9/aaFJALg5N7cBrpKCbITUcaE/NkaOeaNkr2aiN7J7a/n Ix5gjjRwLlBoFCrRuJQjHevaQErIZr5vvE+OUEY6x1oMUaLxrej0KxZqJLysAX7s5/GJ E9N03gY+xHXXa3L9/sff03cnciLTsqtV3InuMOahakAy9bs6M2iSSCmYOVycwSL9cEX1 5iPxObpQPEeATlOed5/lrW+qCcqIozBLh69dsBnVyJyq1BMBmS+DHrCF4m+BMOf+IdA2 YhVA== 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=OLFJr8ns+gcYCw9lAlgR7mP1haE7unlByWNbTytq+Mk=; b=cwFWyQZrci74wUqnLyzAAsgibi+gxsmRm2ZBfib26lW1xtyTfsBqnkgPoYVU02itf/ h3+QPhG/VBxypOePTwnW5gz0sk6FVW382lEB3lJ1IZGMR7Up7ueIxIbI1iu+aZr75uoW ZQabmf8/kp8Xn52g9M2qaoxZHg630cEGyDGiqd+/eFKMQ/q+F42HAucDH4OCFqNqw/Zq w6mdaxge2WxKA5+FL4pjMcyM6L8UujfmRcIZ42+dH1qUQCh5qG+x08qv9BB3f4WA+whX tXLW/p6ughUR/m7zPXibJgjEI8tiFtfRsyXwf3Nz1TlE8CzO9W5HIi70eTBQ/LDzAnI0 Lebw== X-Gm-Message-State: ALoCoQkHQiFkf5CnsUz9s6XhCU+qlrHfmUuJXPQbQMt8ERZL5CZg0JfcOUKrhYvbW8O4uP1/xnE6 X-Received: by 10.129.83.87 with SMTP id h84mr20990783ywb.156.1447385080133; Thu, 12 Nov 2015 19:24:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 19:24:20 -0800 (PST) In-Reply-To: <56454A98.1000305@gmail.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <56454A98.1000305@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 12:24:20 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114d8dae8e9e0e052463994a Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 03:24:42 -0000 --001a114d8dae8e9e0e052463994a Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 11:27 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > The solution is there - it's multihoming using src+dst routing. This is > > what we should be recommending. > > Like draft-ietf-6man-multi-homed-host does, you mean? I can't possibly > disagree ;-) > Well, the hard part is not the host, but the network... but still, good that we agree :-) --001a114d8dae8e9e0e052463994a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 11:27 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
    > The solution is there - it's mul= tihoming using src+dst routing. This is
    > what we should be recommending.

    Like draft-ietf-6man-multi-homed-host does, you mean? I can'= ;t possibly disagree ;-)

    Well, the hard= part is not the host, but the network... but still, good that we agree :-)= =C2=A0
    --001a114d8dae8e9e0e052463994a-- From nobody Thu Nov 12 19:36: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 4345C1B3F6F for ; Thu, 12 Nov 2015 19:36:06 -0800 (PST) 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 oVzJYZO25v3C for ; Thu, 12 Nov 2015 19:36:04 -0800 (PST) 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 1A8521B3F6D for ; Thu, 12 Nov 2015 19:36:03 -0800 (PST) Received: from p59224-ipngn200301daianjibetu.nara.ocn.ne.jp ([58.92.78.224] helo=[192.168.1.197]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1Zx59W-00087U-Bj; Fri, 13 Nov 2015 04:35:55 +0100 To: Lorenzo Colitti References: <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56455ACD.6040804@si6networks.com> Date: Fri, 13 Nov 2015 12:36:45 +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: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 03:36:06 -0000 On 11/13/2015 11:59 AM, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 10:06 AM, Fernando Gont > wrote: > > > The sort of application that tries to do this doesn't typically use TCP. > > You still need to guess the port numbers. And if you're able to, that's > a sign there's something you still need to fix (see RFC6056). > > > The port numbers are no more a guess than the IP addresses are. Whatever > told you the IP addresses can also tell you the port numbers. So: You want to talk to me, but I don't accept incoimng connections. I want to talk to you, but you don't accept incoming connections. You claim that it is simpler to achieve that with NATs, than with FWs. How would that happen without relying on a third party, and without guessing port numbers to fake e.g. a TCP simultaneous open? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Nov 12 19:54: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 486BC1B3FAA for ; Thu, 12 Nov 2015 19:54:21 -0800 (PST) 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 jOd1r-u2Y2kT for ; Thu, 12 Nov 2015 19:54:20 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 3FB661B3FA9 for ; Thu, 12 Nov 2015 19:54:20 -0800 (PST) Received: by ykdr82 with SMTP id r82so128174097ykd.3 for ; Thu, 12 Nov 2015 19:54:19 -0800 (PST) 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=5QqerIX+kJXVPp3nLX9olsTbtK6e6Yqjus+cjYUh2q8=; b=egDPVG7QwWAdf7BkWBJ74+2SNzOptgBJLC/mX9hjnS23iAS+ZLFfi8qdy/OMR6emKS yW5KuG7GcpbyqmcjcmuuyB4o6Hrmnvg8thdh0ioMzPI8bb+co8aBUDg4Nac5nWIw1DIY Jl1VQdETn3hkMi4JvL5/UdKzZMPPBBDuHtA3EbUBQkugDTmVrG0XjINFJF9Qq8i8305C eKOO4vy5yRM7WKAEZYFZiIfSYzArjlTOkUZJPe0cT7ol089vUwzuLoKCqmWy22Ve4N34 V9CPaxPgSB4BmptEjk4ksCy+5fs+5oMd0hpUUTWRNm9jXz1gPQfJCZLpeewVBUHW9S94 sBpw== 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=5QqerIX+kJXVPp3nLX9olsTbtK6e6Yqjus+cjYUh2q8=; b=aqdrzqytgQ4bxwU2NQH+WA6i0OjCmQIHNsK8l3Lmw8fKg1sdZNVLcWZi1wLKhkC0p5 ZRXv5Dx5oTQVWU07pKmmQw2BAtnpoB0lbpHUNAAb2mNLaYZAu8cjfy5WpLTMBDvbPn8L LUc00z6NmaX5YIMpK/jAYS0jCGa7H9dywdRktG7W3K542/pUQRTERO6IC4sASoYt8Ch/ FVy1a4tCHNhsEgWyf1fekdYCNJ+tX4gT2SVOFAWGC3frGPgH5mKaf5qnXS0N8veOzYWE cr5um7dKuAZDQg9MTWD4+qWRyvwwW029tVdrqIgi/t42PUla9dypk7F8e8aZk24Hn5FO q4Wg== X-Gm-Message-State: ALoCoQlTnEQZiyxJe7EAi9nZY2+hl17YerPrGb0T9oVyrajJHO9HuRssm+j5FuNh1IrssRcyanxO X-Received: by 10.129.44.3 with SMTP id s3mr18579461yws.141.1447386859404; Thu, 12 Nov 2015 19:54:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 19:53:59 -0800 (PST) In-Reply-To: <56455ACD.6040804@si6networks.com> References: <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 12:53:59 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114278de9c108505246403a2 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 03:54:21 -0000 --001a114278de9c108505246403a2 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 12:36 PM, Fernando Gont wrote: > You claim that it is simpler to achieve that with NATs, than with FWs. > How would that happen without relying on a third party, and without > guessing port numbers to fake e.g. a TCP simultaneous open? The IP addresses and port numbers could be signaled out of band using another mechanism (NFC, bluetooth, email, smoke signals, well-known ports, whatever). If you don't use NAT, the two parties have all the information they need and the communication can be entirely peer-to-peer with no third party involved. If you do NAT, you have to involve a third party, and depending on how draconian the NAT is, that third party might have to be proxy all the traffic for the duration of the connection. That's high cost, high latency, and low quality. --001a114278de9c108505246403a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 12:36 PM, Fernando Gont <fgont@si6networks.com> wrote:
    You claim that it is simpler to ac= hieve that with NATs, than with FWs.
    How would that happen without relying on a third party, and without
    guessing port numbers to fake e.g. a TCP simultaneous open?

    --001a114278de9c108505246403a2-- From nobody Thu Nov 12 20:15: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 C486B1B3FD4 for ; Thu, 12 Nov 2015 20:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_64=0.6, 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 NHTvABebuxOS for ; Thu, 12 Nov 2015 20:15:01 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2321B3FD6 for ; Thu, 12 Nov 2015 20:15:01 -0800 (PST) Received: by ioc74 with SMTP id 74so86699216ioc.2 for ; Thu, 12 Nov 2015 20:15:00 -0800 (PST) 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=UUYs53lYX9Giet5l9RU6Q3E6KdHPP0BIkufRPLcuDCg=; b=RfibVJS3hhKSXco+NA1pRvR3dtXTPSV/5Xn6Nsumbr1EE9K6IXCyz6aXuhywiYSgI0 uv+dUWEPLGn1b2Rj6zq3Q3PhNIVPvfBXzLSVCnmFERgnLK6Uxt41j2VhWIWVrFh93XHF tYIvYwqRYrCyijyxLb8Tdt0AGbbb5vj8PfalJ2vPrqKPiQ0GDi3BcLdKFmKzW34beHCn 7s37E2VhDJlJ4i8ewhPGkXbfxrJZOvExElGgONoB42O1m4wgk9HPfXlv0DrCVlAz7vwT 6MDdAFgpRhymZcLM+mAYZBOg1vtquQfHkwwZu7ala/G5K7+fDp3RrqnKNuhobIj6mCE2 JPHQ== MIME-Version: 1.0 X-Received: by 10.107.164.227 with SMTP id d96mr17694725ioj.73.1447388100664; Thu, 12 Nov 2015 20:15:00 -0800 (PST) Sender: fgont.mobile@gmail.com Received: by 10.36.21.130 with HTTP; Thu, 12 Nov 2015 20:15:00 -0800 (PST) Received: by 10.36.21.130 with HTTP; Thu, 12 Nov 2015 20:15:00 -0800 (PST) In-Reply-To: References: <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> Date: Fri, 13 Nov 2015 01:15:00 -0300 X-Google-Sender-Auth: 2SRWaSRlERA9KLiGUD7Cox3XcJ8 Message-ID: From: Fernando Gont To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a1142261497a5200524644d9b Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 04:15:03 -0000 --001a1142261497a5200524644d9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 13/11/2015 12:54, "Lorenzo Colitti" escribi=C3=B3: > > On Fri, Nov 13, 2015 at 12:36 PM, Fernando Gont wrote: >> >> You claim that it is simpler to achieve that with NATs, than with FWs. >> How would that happen without relying on a third party, and without >> guessing port numbers to fake e.g. a TCP simultaneous open? > > > The IP addresses and port numbers could be signaled out of band using another mechanism (NFC, bluetooth, email, smoke signals, well-known ports, whatever). And for that signaling you need.... a third party. Si it ends up being a discussion of what type of third party one hates the most. As noted, shortcuts in the current in the current architecture should not be interpreted as design principles.. NATs happen to make this very evident. Don't shoot the messenger for this. If a network has a policy of only allowing outgoing connections, then any workaround to do that is an attack on that policy. And making.that workaround more difficult can thus be seen as a feature. Fernando --001a1142261497a5200524644d9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    El 13/11/2015 12:54, "Lorenzo Colitti" <    lorenzo@google.com> escribi=C3=B3:
    >
    > On Fri, Nov 13, 2015 at 12:36 PM, Fernando Gont <fgont@si6networks.com> wrote:
    >>
    >> You claim that it is simpler to achieve that with NATs, than with = FWs.
    >> How would that happen without relying on a third party, and withou= t
    >> guessing port numbers to fake e.g. a TCP simultaneous open?
    >
    >
    > The IP addresses and port numbers could be signaled out of band using = another mechanism (NFC, bluetooth, email, smoke signals, well-known ports, = whatever).

    And for that signaling you need.... a third party.

    Si it ends up being a discussion of what type of third party= one hates the most.

    As noted, shortcuts in the current in the current architectu= re should not be interpreted as design principles.. NATs happen to make thi= s very evident. Don't shoot the messenger for this.

    If a network has a policy of only allowing outgoing connecti= ons, then any workaround to do that is an attack on that policy. And making= .that workaround more difficult can thus be seen as a feature.

    Fernando

    --001a1142261497a5200524644d9b-- From nobody Thu Nov 12 20:50: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 9B4631B3FFA for ; Thu, 12 Nov 2015 20:50:20 -0800 (PST) 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 7l9TnB6a33_A for ; Thu, 12 Nov 2015 20:50:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D8B221B3FF7 for ; Thu, 12 Nov 2015 20:50:18 -0800 (PST) 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 tAD4n30O013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 20:49:03 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <56453712.4030209@si6networks.com> Date: Thu, 12 Nov 2015 20:49:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A9C485D-E94F-40D2-96A9-92E261905D46@delong.com> References: <5637FDD0.70300@jvknet.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <563B9D1E.4030606@umn.edu> <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <28EECB50-9F5F-4F47-95EB-86BD5E9A9C72@delong.com> <56453712.4030209@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 04:50:20 -0000 > On Nov 12, 2015, at 17:04 , Fernando Gont = wrote: >=20 > On 11/13/2015 03:05 AM, Owen DeLong wrote: >>>> They still work fine on networks that >>>> operate the way the Internet was originally designed with = end-to-end >>>> connectivity. >>>=20 >>> not sure what you mean by "end-to-end" connectivity. >>=20 >> I won=E2=80=99t speak for Lorenzo, but what I mean when I talk about = =E2=80=9Cend-to-end=E2=80=9D >> is the situation where the L3 packet that leaves the origin host = arrives >> at the destination host without being modified except for certain = fields >> intended to be modified in flight. (Namely TTL/Hop Count, L2 and = lower >> layer fields, etc.). Certainly the L3 and higher layer identifiers = are not >> to be tampered with in flight. >=20 > FTP PORT doesn't work fine in firewalled environments. It requires a > middlebox to tap into the FTP control protocol so that the fw can open > the necessary holes. -- So the only networks where FTP PORT works fine > is un-NATed, unfiltered networks -- which is kind of Wonderland. FTP is not the only protocol being discussed and there are actually a = variety of alternative ways to solve the FTP PORT problem that do not require removing the firewall or having an unfiltered network. Owen From nobody Thu Nov 12 20:55: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 41CDB1B3F1D for ; Thu, 12 Nov 2015 20:55:17 -0800 (PST) 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 aeLPLhlSzIdb for ; Thu, 12 Nov 2015 20:55:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A85771B3DDA for ; Thu, 12 Nov 2015 20:55:15 -0800 (PST) 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 tAD4r8i4013302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 20:53:08 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <56453C96.7070509@si6networks.com> Date: Thu, 12 Nov 2015 20:53:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com> References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <56453C96.7070509@si6netwo! rks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 04:55:17 -0000 > On Nov 12, 2015, at 17:27 , Fernando Gont = wrote: >=20 > Owen, >=20 > On 11/13/2015 03:21 AM, Owen DeLong wrote: >>=20 >>> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) >> > wrote: >>>=20 >>>> Nope. It is much easier to establish a connection across a diode >>>> firewall than to establish one across a NAT. In the former case, = all >>>> the endpoints need to do is send each other packets at about the = same >>>> time. In the latter, they need to implement NAT traversal via = relays. >>>=20 >>> It is only 'slightly' easier... Because guessing the TCP sequence >>> number of the other party... Well good luck :-) >>=20 >> With a diode firewall, you don=E2=80=99t have to guess. Most diode = firewalls >> don=E2=80=99t look at TCP sequence numbers actively. They look only = at the L3 >> and L4 identifiers to determine state. >> Some look at SYN bits and toss SYN packets going in the wrong = direction, >> but most just look for an ACK bit. >>=20 >> Nonetheless, it=E2=80=99s also much easier because a diode firewall = can easily >> be given an exception to permit a particular flow or the initiation = of a >> class of flows to a particular protected host or set of hosts. >=20 > The problem is how to do this automagically. Why does it have to be automagic? >=20 >=20 >> In the case of a NAT, however (more specifically a NAPT), it is not >> possible to program multiple port 80 terminations to land on = different >> hosts behind the NAT. >=20 > That's like saying that the problem with cars is that they cannot fly = -- > yes, that's what a NAT is. Well=E2=80=A6 That is certainly a limitation of most automobiles, but = I=E2=80=99m happy to report that there are working alternatives such as the Terrafugia = Transition and some older prototypes as well. > I might also add that this is another kludge that is made evident by > NAT: there's no reason whatsoever for which a given service should run > in any specific transport protocol port. Consider that a kludge or > shortcut than a principle. Meh=E2=80=A6 There=E2=80=99s no mechanism available for signaling port = numbers in response to name lookups (modulo SRV records that don=E2=80=99t seem to be very = popular in practice). There are certain advantages to the idea of well known port = numbers and whether or not you consider them a kludge, they are certainly in = widespread use and have a great deal of history and support in the IETF and IANA. >> I retain my perspective that one of the worst and most ultimate forms = of >> layering violation is for a forwarding system not residing on either = of >> the end-hosts in a session to impersonate an end-host and mutilate >> unexpected portions of the datagram in flight. >=20 > I might grant that one if you want. But virtualy everything that you > mentioned that NAT breaks are shortcuts (or flawed design) rather than > "principles" we should stick to. We can agree to disagree as we so often do. Owen From nobody Thu Nov 12 23:59: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 5574A1A00D4 for ; Thu, 12 Nov 2015 23:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.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] 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 9vGZ0QnedjI6 for ; Thu, 12 Nov 2015 23:59:51 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62B61A00C8 for ; Thu, 12 Nov 2015 23:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6342; q=dns/txt; s=iport; t=1447401591; x=1448611191; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Vlcr4IxOlIplg52tPiYc2LGT8EQMhQO71865+uYvODk=; b=Q169Bei+HE0i/ZKuJiv6d4fUGC2dLItGC0OPoxY4pSNSxfxupu6e86WQ qNFG+BBGZ5L50F4qYEb0iMC588nV1GAyhL/MIISlA+GOXpI25vSDe7Llz Aczq9NJNm1NMauq5X0goAZuMNAC/YpiFda82QwFwoS9mesOaXEUeUkOxS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAgCnl0VW/5NdJa1egm5NgUIGvjsBD?= =?us-ascii?q?YEIBFmGEAIcgSE4FAEBAQEBAQGBCoQ0AQEBAwEjVgULAgEIBA0DAQIBJwMCAgI?= =?us-ascii?q?wFAkIAgQBDQWIJgiyG5BUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUAYR9hHuCe?= =?us-ascii?q?oFEBZZIAY0mgVuWeINxAR8BAUKEBHKENoEHAQEB?= X-IronPort-AV: E=Sophos; i="5.20,286,1444694400"; d="scan'208,217"; a="44563909" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 13 Nov 2015 07:59:50 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAD7xoRJ026497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 07:59:50 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 02:59:49 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 02:59:49 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRHae1VO7a+hOYbUqLqGWwMabUxZ6Zd6WAgAAfhoCAAGSigA== Date: Fri, 13 Nov 2015 07:59:49 +0000 Message-ID: References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> In-Reply-To: Accept-Language: fr-FR, 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.138.46] Content-Type: multipart/alternative; boundary="_000_D26B56545DE76evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 07:59:53 -0000 --_000_D26B56545DE76evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSB0aG9zZSBsaXZlbHkgTkFUIGRpc2N1c3Npb25zLi4uDQoNCkkgYWdyZWUgd2l0aCBMb3Jlbnpv OiBwb3J0cyBhcmUgJ2p1c3QnIGFuIGV4dGVuc2lvbiBvZiB0aGUgSVAgYWRkcmVzcyBhbmQgY2Fu IGJlIG5lZ290aWF0ZWQgKFNEUCBmb3IgZXhhbXBsZSkuIEFsc28gYWdyZWUgd2l0aCBGZXJuYW5k bzogYWRkIGEgM3JkIHBhcnR5IChvciBhIDR0aCBvbmUgLS0gZG91YmxlIE5BVCkgYW5kIHlvdXIg cHJvYmxlbXMgY29tZS4NCg0KQW5kIHRoZXJlIGFyZSBhdCBsZWFzdCBvbmUgZmlyZXdhbGwgd2hp Y2ggY2hlY2tzIHRoZSBUQ1Agc2VxdWVuY2UgbnVtYmVycywgc28sIGFueSBhdHRlbXB0IHRvICdi eXBhc3MnIHRoZSBkaW9kZS1saWtlIGZ1bmN0aW9uIGJ5IHNlbmRpbmcgU1lOIG9uIG9uZSBzaWRl IGFuZCBTWU4rQUNLIG9uIHRoZSBvdGhlciBzaWRlIHdpbGwgYWxzbyByZXF1aXJlIHRvIG5lZ290 aWF0ZSB0aGUgVENQIHNlcXVlbmNlIG51bWJlcnMuLi4gQW5kIHRob3NlIGFyZSBvdXRzaWRlIHRo ZSByZWFsbSBvZiB0aGUgdXNlciBzcGFjZSBhcHBsaWNhdGlvbg0KDQotw6lyaWMNCg0KRnJvbTog TG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xl LmNvbT4+DQpEYXRlOiB2ZW5kcmVkaSAxMyBub3ZlbWJyZSAyMDE1IDAzOjU5DQpUbzogRmVybmFu ZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5j b20+Pg0KQ2M6IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBj aXNjby5jb20+PiwgSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNh Z2UtcmVjb21tZW5kYXRpb25zIC0gd29yayBvciBhYmFuZG9uPw0KDQpPbiBGcmksIE5vdiAxMywg MjAxNSBhdCAxMDowNiBBTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1h aWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+PiB3cm90ZToNCj4gVGhlIHNvcnQgb2YgYXBwbGlj YXRpb24gdGhhdCB0cmllcyB0byBkbyB0aGlzIGRvZXNuJ3QgdHlwaWNhbGx5IHVzZSBUQ1AuDQoN CllvdSBzdGlsbCBuZWVkIHRvIGd1ZXNzIHRoZSBwb3J0IG51bWJlcnMuIEFuZCBpZiB5b3UncmUg YWJsZSB0bywgdGhhdCdzDQphIHNpZ24gdGhlcmUncyBzb21ldGhpbmcgeW91IHN0aWxsIG5lZWQg dG8gZml4IChzZWUgUkZDNjA1NikuDQoNClRoZSBwb3J0IG51bWJlcnMgYXJlIG5vIG1vcmUgYSBn dWVzcyB0aGFuIHRoZSBJUCBhZGRyZXNzZXMgYXJlLiBXaGF0ZXZlciB0b2xkIHlvdSB0aGUgSVAg YWRkcmVzc2VzIGNhbiBhbHNvIHRlbGwgeW91IHRoZSBwb3J0IG51bWJlcnMuDQo= --_000_D26B56545DE76evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <64E10F21D5F7194DB8C9CBAB93FEFB35@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BIHRob3NlIGxp dmVseSBOQVQgZGlzY3Vzc2lvbnMuLi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkg YWdyZWUgd2l0aCBMb3JlbnpvOiBwb3J0cyBhcmUgJ2p1c3QnIGFuIGV4dGVuc2lvbiBvZiB0aGUg SVAgYWRkcmVzcyBhbmQgY2FuIGJlIG5lZ290aWF0ZWQgKFNEUCBmb3IgZXhhbXBsZSkuIEFsc28g YWdyZWUgd2l0aCBGZXJuYW5kbzogYWRkIGEgM3JkIHBhcnR5IChvciBhIDR0aCBvbmUgLS0gZG91 YmxlIE5BVCkgYW5kIHlvdXIgcHJvYmxlbXMgY29tZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkFuZCB0aGVyZSBhcmUgYXQgbGVhc3Qgb25lIGZpcmV3YWxsIHdoaWNoIGNoZWNrcyB0 aGUgVENQIHNlcXVlbmNlIG51bWJlcnMsIHNvLCBhbnkgYXR0ZW1wdCB0byAnYnlwYXNzJyB0aGUg ZGlvZGUtbGlrZSBmdW5jdGlvbiBieSBzZW5kaW5nIFNZTiBvbiBvbmUgc2lkZSBhbmQgU1lOJiM0 MztBQ0sgb24gdGhlIG90aGVyIHNpZGUgd2lsbCBhbHNvIHJlcXVpcmUgdG8gbmVnb3RpYXRlIHRo ZSBUQ1Agc2VxdWVuY2UgbnVtYmVycy4uLiBBbmQgdGhvc2UNCiBhcmUgb3V0c2lkZSB0aGUgcmVh bG0gb2YgdGhlIHVzZXIgc3BhY2UgYXBwbGljYXRpb248L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pi3DqXJpYyZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJP TEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBm b250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRP TTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006 IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDog I2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9Q OiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Mb3Jl bnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVu em9AZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj52ZW5kcmVkaSAxMyBub3ZlbWJyZSAyMDE1IDAzOjU5PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+RmVybmFuZG8gR29udCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSI+ZmdvbnRAc2k2bmV0d29ya3MuY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5F cmljIFZ5bmNrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tl QGNpc2NvLmNvbTwvYT4mZ3Q7LCBJUHY2IE9wZXJhdGlvbnMgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12 Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zIC0gd29yayBvciBhYmFuZG9uPzxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIE5vdiAxMywgMjAxNSBhdCAxMDowNiBBTSwgRmVybmFuZG8gR29udCA8c3Bh biBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxz cGFuIGNsYXNzPSIiPiZndDsgVGhlIHNvcnQgb2YgYXBwbGljYXRpb24gdGhhdCB0cmllcyB0byBk byB0aGlzIGRvZXNuJ3QgdHlwaWNhbGx5IHVzZSBUQ1AuPGJyPg0KPGJyPg0KPC9zcGFuPllvdSBz dGlsbCBuZWVkIHRvIGd1ZXNzIHRoZSBwb3J0IG51bWJlcnMuIEFuZCBpZiB5b3UncmUgYWJsZSB0 bywgdGhhdCdzPGJyPg0KYSBzaWduIHRoZXJlJ3Mgc29tZXRoaW5nIHlvdSBzdGlsbCBuZWVkIHRv IGZpeCAoc2VlIFJGQzYwNTYpLjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoZSBwb3J0IG51bWJlcnMgYXJlIG5vIG1vcmUgYSBndWVzcyB0aGFuIHRoZSBJUCBhZGRyZXNz ZXMgYXJlLiBXaGF0ZXZlciB0b2xkIHlvdSB0aGUgSVAgYWRkcmVzc2VzIGNhbiBhbHNvIHRlbGwg eW91IHRoZSBwb3J0IG51bWJlcnMuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_D26B56545DE76evynckeciscocom_-- From nobody Fri Nov 13 00:05: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 397F41A0218 for ; Fri, 13 Nov 2015 00:05:13 -0800 (PST) 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 0MS7YiVdJ4z1 for ; Fri, 13 Nov 2015 00:05:11 -0800 (PST) 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 0212B1A01F7 for ; Fri, 13 Nov 2015 00:05:10 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 92E8162DED for ; Fri, 13 Nov 2015 09:05:08 +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 5182E60AA4 for ; Fri, 13 Nov 2015 09:05:08 +0100 (CET) Received: (qmail 70569 invoked by uid 1007); 13 Nov 2015 09:05:08 +0100 Date: Fri, 13 Nov 2015 09:05:08 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20151113080508.GB89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 08:05:13 -0000 Hi, On Fri, Nov 13, 2015 at 11:11:27AM +0900, Lorenzo Colitti wrote: > The solution is there - it's multihoming using src+dst routing. This is > what we should be recommending. And to chime in: I see this as a good and viable solution for end users and "small shop multihoming" - small shop being: no externally visible stuff hosted locally, no inbound VPN stuff, no firewall rules elsewhere that reference these IPv6 prefixes, etc. - "your typical barber shop". There are bits and pieces missing to make this a complete solution (namely, source address failover or "source address happy eyeballs"), but if these show up, the solution is actually more flexible and more powerful than BGP-based stuff. You want bittorrent from your machine to take another upstream than your ssh sessions? "just pick the proper source address"... (and yes, work is needed here) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Nov 13 03:11: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 C50311AC3FD for ; Fri, 13 Nov 2015 03:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_64=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 fMTCB-FF6sjF for ; Fri, 13 Nov 2015 03:11:30 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 6A0C41AC3FC for ; Fri, 13 Nov 2015 03:11:30 -0800 (PST) Received: by ykdv3 with SMTP id v3so140458696ykd.0 for ; Fri, 13 Nov 2015 03:11:29 -0800 (PST) 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=KN7UkyEuKep4Ne0twh4Pbx156ER9KjQmOrJkXi76Rog=; b=CzsgYxxxlh/NLnYB3eev9KsMZ+etJdoYnwX7Jcl8oE8u/DvNPDoN6VUobrvs+yAvPN ugLzfagZZjIF+K0I4BfCZi3I+2zQ2npnH0SxjX+Ddtlkh2GsSUFZmlzG6NBZlhO8eYAv ozVvS1uVx3Abui/7OenH8n0TBIucqtCS/KOI16ni4zzXTjj6FFiefqq1G7qgmIquqQ5B RSGwTkxyuaXAUZUgiNN3Qg1PJu/SuwUutYYRKQglL9MsyabMtRoYmcxrk8QI5lCCNZdg NlCESwGw49N0e5B+C80jsMHTOb1XIDZYhG5jAx07pHoGKal2Uf56DtoFMhouQy3zsKNU X8FQ== 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=KN7UkyEuKep4Ne0twh4Pbx156ER9KjQmOrJkXi76Rog=; b=cfvXZ2QRDP/TNazjKASAv5OT/esNj/1mPmxw7VqMM4+zzT5C1tKU0Rcawlu+QZohqJ s2PtL2YabxA1eCTMbZ4mKayHvI12ZHJWFhsU90qST8qLzHdb1x6kIBcBVbmGFQ8m10If tpcn2rTaSzzThQmuo0UXE0e5sNyeGQZhVbaw5UHSF06Igc1gcymJFu2yiCcsCZ+1UIPI RHBUajATny/bncZOygjJKLnrnSDgRF84ylDvfn3Uo0q1Hw/d5HE+QsAmypH1sB11cj7d FUQmBfTjBX8Jp86jUwnsM+xlVOV2J2StAKqnv/KXu9wPBtP1wogifSlBrodcSaytuwxi BOpA== X-Gm-Message-State: ALoCoQlv+OmgQ/Hkf8YYE7AmCbmALz1gv6mN5Fe5JZJru8+Af5vfjkVQooAL/quyQKGjvheTOw7i X-Received: by 10.129.78.86 with SMTP id c83mr5297093ywb.116.1447413089668; Fri, 13 Nov 2015 03:11:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Fri, 13 Nov 2015 03:11:09 -0800 (PST) In-Reply-To: References: <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 20:11:09 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114db4d80e0da305246a1f2c Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 11:11:32 -0000 --001a114db4d80e0da305246a1f2c Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 1:15 PM, Fernando Gont wrote: > > The IP addresses and port numbers could be signaled out of band using > another mechanism (NFC, bluetooth, email, smoke signals, well-known ports, > whatever). > > And for that signaling you need.... a third party. > Not for NFC, bluetooth, smoke signals, or well-known ports you don't. And even if you do need a third party, there's a huge difference between a third party that relays / snoops your traffic vs. a third party that just puts the two parties in touch and then disappears from the equation. > As noted, shortcuts in the current in the current architecture should not > be interpreted as design principles.. NATs happen to make this very > evident. Don't shoot the messenger for this. > And we come around to the previous argument. The situation is not that we are shooting NAT for coming and telling us the architecture is broken. The situation is that we are shooting NAT for breaking it. > If a network has a policy of only allowing outgoing connections, then any > workaround to do that is an attack on that policy. And making.that > workaround more difficult can thus be seen as a feature. > Such a policy is misguided because it ignores the reality that today outgoing connections are just as dangerous as incoming ones, if not more. We need a better reason to break the architecture than misguided policies. --001a114db4d80e0da305246a1f2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 1:15 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:

    > The IP addresses and port numbers could be signaled out of ba= nd using another mechanism (NFC, bluetooth, email, smoke signals, well-know= n ports, whatever).

    And for that signaling you need.... a third party.

    Not for NFC, bluetooth, smoke signals, or well-known por= ts you don't. And even if you do need a third party, there's a huge= difference between a third party that relays / snoops your traffic vs. a t= hird party that just puts the two parties in touch and then disappears from= the equation.

    As noted, shortcuts in the current in the current architectu= re should not be interpreted as design principles.. NATs happen to make thi= s very evident. Don't shoot the messenger for this.

    And we come around to the previous argument. The situation is not that we= are shooting NAT for coming and telling us the architecture is broken. The= situation is that we are shooting NAT for breaking it.

    If a network has a policy of only allowing outgoing connecti= ons, then any workaround to do that is an attack on that policy. And making= .that workaround more difficult can thus be seen as a feature.

    Such a policy is misguided because it ignores the reality that to= day outgoing connections are just as dangerous as incoming ones, if not mor= e. We need a better reason to break the architecture than misguided policie= s.
    --001a114db4d80e0da305246a1f2c-- From nobody Fri Nov 13 03:12: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 BFAD81AC40C for ; Fri, 13 Nov 2015 03:12:34 -0800 (PST) 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 MIxqQPSuGShr for ; Fri, 13 Nov 2015 03:12:33 -0800 (PST) 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 28F661AC406 for ; Fri, 13 Nov 2015 03:12:33 -0800 (PST) Received: by ykba77 with SMTP id a77so139982039ykb.2 for ; Fri, 13 Nov 2015 03:12:32 -0800 (PST) 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=q6NTUe/1DbHNuVlCyjDJIRF42p4QSy81kIIPNkrzbpU=; b=BPaf929zZPQ888L5/XpyhzY7PAC5YFcfmkjjJAS6RA+TOHgbg08ePJJHVtGTwADRPs 68YvQgTupDR/ywL+KdSZknQbLPufxWv9eiz2Bwb7A/zNdV2Z2rsWJE9cPKilNLacafW0 T3TWHfq3NDK7i7eBcMPTREyHNGvMLEAum9lWBGuiqSu9kro70SQD5+7KOeTnaGlvFgLM 7BB+wHMw6C0/bX+OSED70xOagvgAxH7bUTZaFD1id97POF8rwsvKhf8UvrOHd8A8YrPV FoCGk963xGNL18q7A2Q/ZunBc4e0GYCgFyt4C7A++K+blWLbj4KzzAR+DnE1yiji0mJa jaAQ== 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=q6NTUe/1DbHNuVlCyjDJIRF42p4QSy81kIIPNkrzbpU=; b=ZYG52qaky1O5OyC9bPlKtpFiFnmPuIbvIKKQHiiIAaHX5DQObVMn4kA4PNVpWy0LfY ozTVOCWffTFZEgK4bSX4PPH5dQYdkWRK1DmWokyelokFH2N+A2sGS82heK4d7iK7jFfA VWJgF/+kXiwPHPVRNiEtzfaGtnopIuKAlfb26ChZk21BpKdX2ZMVgBDtc/Pvg7zMyHU5 D4boRWD1wmtbVpWhq5m0OsWQZpDx/zNcP12GBbc296hMezh18WZ3dFmX14B6hHVo+Kfi wgo79lEeW8RtPkQTV6IlLRxkCVvA2mH/0rT0QjmX+EOVaZ7UTLnqErY1X/e+ZXmsWanB t5kQ== X-Gm-Message-State: ALoCoQnztleVnOVUWvR+JnTbmgf5Dq+1yB1Ga5LxYG93jitZZN+USsTqbp/fnvL6LOZmknEE2pio X-Received: by 10.13.204.2 with SMTP id o2mr16785385ywd.160.1447413152369; Fri, 13 Nov 2015 03:12:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Fri, 13 Nov 2015 03:12:12 -0800 (PST) In-Reply-To: References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 20:12:12 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a114f136acac04205246a22c1 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 11:12:34 -0000 --001a114f136acac04205246a22c1 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 4:59 PM, Eric Vyncke (evyncke) wrote: > I agree with Lorenzo: ports are 'just' an extension of the IP address and > can be negotiated (SDP for example). Also agree with Fernando: add a 3rd > party (or a 4th one -- double NAT) and your problems come. > > And there are at least one firewall which checks the TCP sequence numbers, > so, any attempt to 'bypass' the diode-like function by sending SYN on one > side and SYN+ACK on the other side will also require to negotiate the TCP > sequence numbers... And those are outside the realm of the user space > application > Absolutely. There are firewalls that only allow through pink packets on Tuesdays. But checking the sequence number won't help with UDP. --001a114f136acac04205246a22c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 4:59 PM, Eric Vyncke (evyncke) <evyncke@cisco.com&= gt; wrote:
    I agree with Lorenzo: ports are 'just' an extension of the IP = address and can be negotiated (SDP for example). Also agree with Fernando: = add a 3rd party (or a 4th one -- double NAT) and your problems come.

    And there are at least one firewall which checks the TCP sequence numb= ers, so, any attempt to 'bypass' the diode-like function by sending= SYN on one side and SYN+ACK on the other side will also require to negotia= te the TCP sequence numbers... And those are outside the realm of the user space application

    Absolutely. There are firewalls that only allow throu= gh pink packets on Tuesdays. But checking the sequence number won't hel= p with UDP.
    --001a114f136acac04205246a22c1-- From nobody Fri Nov 13 03:16: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 C7C131AC417 for ; Fri, 13 Nov 2015 03:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.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] 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 bmsRGi2yZuFF for ; Fri, 13 Nov 2015 03:16:44 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B3B1AC3E6 for ; Fri, 13 Nov 2015 03:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2010; q=dns/txt; s=iport; t=1447413404; x=1448623004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+kUmWkmPP6pWEmf8/yi7g/9QQ1rUq1v/5thvi47q6do=; b=KIGAYMGoDcmcwborHzzdaIcAKgF7PgNBM7G8f9iXTJFRmQ51yzJvr6A9 3H/QH1SEWoKzyFHw/9JDtYkbBAWHKQ2GFOzbsMqY7hJxiDArYlPWhC2bT fVQyccUTztC9YXzTq7B36ispG2SVD4JjEjTwGB+O8FAbFhSAAAtrOI5Yb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgDNxUVW/51dJa1egm5NgUi+PAENg?= =?us-ascii?q?WWGEAIcgSY4FAEBAQEBAQGBCoQrCgEBBCNWEAIBCAMBPgICAjAlAgQOiDOwf5B?= =?us-ascii?q?YAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUAYR9h3WBRAWWSAGNJpxEAR8BAUKEB?= =?us-ascii?q?IUogQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,287,1444694400"; d="scan'208,217";a="207924494" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 13 Nov 2015 11:16:44 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tADBGh69025568 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 11:16:43 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 06:16:42 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 06:16:42 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRHae1VO7a+hOYbUqLqGWwMabUxZ6Zd6WAgAAfhoCAAGSigIAAJP8AgAAR/4A= Date: Fri, 13 Nov 2015 11:16:42 +0000 Message-ID: References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <564537A7.90102@si6networks.com> In-Reply-To: Accept-Language: fr-FR, 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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.138.46] Content-Type: multipart/alternative; boundary="_000_D26B84F05DF41evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 11:16:45 -0000 --_000_D26B84F05DF41evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBYnNvbHV0ZWx5LiBUaGVyZSBhcmUgZmlyZXdhbGxzIHRoYXQgb25seSBhbGxvdyB0aHJvdWdo IHBpbmsgcGFja2V0cyBvbiBUdWVzZGF5cy4gQnV0IGNoZWNraW5nIHRoZSBzZXF1ZW5jZSBudW1i ZXIgd29uJ3QgaGVscCB3aXRoIFVEUC4NCg0KQW5kIHllbGxvdyBwYWNrZXRzIG9uIEZyaWRheXMu IEFuZCwgdGhlIGFic2VuY2Ugb2YgJ3N0YXRlcycgaW4gVURQIHBhY2tldCBpcyBvbmUgcmVhc29u IHdoeSBzb21lIGVkZ2Ugc2VjdXJpdHkgcG9saWN5IGJsb2NrIFVEUA0KDQotw6lyaWMNCg== --_000_D26B84F05DF41evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5235C9DE08D3C14ABB7FD63E9143FCE6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5BYnNvbHV0ZWx5LiBUaGVyZSBhcmUgZmlyZXdhbGxzIHRoYXQgb25seSBhbGxv dyB0aHJvdWdoIHBpbmsgcGFja2V0cyBvbiBUdWVzZGF5cy4gQnV0IGNoZWNraW5nIHRoZSBzZXF1 ZW5jZSBudW1iZXIgd29uJ3QgaGVscCB3aXRoIFVEUC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFu ZCB5ZWxsb3cgcGFja2V0cyBvbiBGcmlkYXlzLiBBbmQsIHRoZSBhYnNlbmNlIG9mICdzdGF0ZXMn IGluIFVEUCBwYWNrZXQgaXMgb25lIHJlYXNvbiB3aHkgc29tZSBlZGdlIHNlY3VyaXR5IHBvbGlj eSBibG9jayBVRFAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi3DqXJpYzwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D26B84F05DF41evynckeciscocom_-- From nobody Fri Nov 13 03:19: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 AF7B41AC42A for ; Fri, 13 Nov 2015 03:19:04 -0800 (PST) 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 9A-j_OrHRHen for ; Fri, 13 Nov 2015 03:19:03 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 06E981AC41F for ; Fri, 13 Nov 2015 03:19:03 -0800 (PST) Received: by ykba77 with SMTP id a77so140187751ykb.2 for ; Fri, 13 Nov 2015 03:19:02 -0800 (PST) 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=ToXQSvJJEhgFYlhdpEQgL/Z7AfKELfQhbCtr8PfLVSI=; b=Qa0DDe8XiYpR9OLW+wS0i85l6s+BAp/Xv2jNf2XzVnqdOO16GTsBFHpZlq1nqhAZbg MFeALjrIPJjUeT1vXOIPBmg5VBt/7D26mJhWgVuzPEGFCefLKy5FGQG1LhQSnYlvAmiR WV+Ud/DYuCqaJrwE68O2Lx+CvbGwksDkbTrxWGYze/ky0vEmzvpkmsdUm7wFi9KWASML HZEPGFuslmJxvOUsT6EUU3ggTjmWvnMx3rAORvUQ/mrFwn6hK7YauobJN7+TuigRIGpI hPredXGl/YiPkFw/UrZe9bLFGxwW1++LNvwJ/8V7LRG9XJdruR4Tx6gCuJCC28scO9xL KrKQ== 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=ToXQSvJJEhgFYlhdpEQgL/Z7AfKELfQhbCtr8PfLVSI=; b=iAAd9oRqt73UjMW7DyvaOh7EpduP68SHGoW0FVx+4Q2OhE1GcyQ4ZPtDGMxxMDCRAb 96QWa8Z7KQuuy8o5E/7vQhPA4Scl94cPGB/Qs3PAXtrMAvkcsoMQuJ1NV/QYaVO9d1HG Z0DbMOO2Qe3OgkqdMlxIq3T/aezfYyuZEsInEoj1tvuX1pVwmTJYjdnw/kglmYb8BO02 jv2C3nLhx7mlYL7sG5zYdr2qS30F+xZypg1FsOFQjd5g/woyo3FWenU89nJ62mEokOUp 55ilxOPgUOZrOmQ81nsHMU1PzfpxKX8OnfL9ZL5q06bqYSEJqauezbdLdiIgIbrlhTWZ OM4A== X-Gm-Message-State: ALoCoQmzUoKXsdLpd/iUg+4sl0A1UxuBjSbO2fJSHCast7Vk1Dgn2k1R0jVB6msynuikYW80+MSu X-Received: by 10.129.90.193 with SMTP id o184mr22498160ywb.123.1447413542236; Fri, 13 Nov 2015 03:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Fri, 13 Nov 2015 03:18:42 -0800 (PST) In-Reply-To: <20151113080508.GB89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 20:18:42 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1149163407aca705246a3a9a Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 11:19:04 -0000 --001a1149163407aca705246a3a9a Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 5:05 PM, Gert Doering wrote: > There are bits and pieces missing to make this a complete solution > (namely, source address failover or "source address happy eyeballs"), > I think you can address most of this by deprecating addresses when an upstream goes away. --001a1149163407aca705246a3a9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 5:05 PM, Gert Doering <gert@space.net> wrot= e:
    There are bits and pieces missing to m= ake this a complete solution
    (namely, source address failover or "source address happy eyeballs&quo= t;),

    I think you can address most of th= is by deprecating addresses when an upstream goes away.
    --001a1149163407aca705246a3a9a-- From nobody Fri Nov 13 03:21: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 42E0A1AC417 for ; Fri, 13 Nov 2015 03:21:45 -0800 (PST) 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 J1kcQ6ciEnAi for ; Fri, 13 Nov 2015 03:21:43 -0800 (PST) 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 578681AC41F for ; Fri, 13 Nov 2015 03:21:43 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C2863632D8 for ; Fri, 13 Nov 2015 12:21:41 +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 8F8A160760 for ; Fri, 13 Nov 2015 12:21:41 +0100 (CET) Received: (qmail 87156 invoked by uid 1007); 13 Nov 2015 12:21:41 +0100 Date: Fri, 13 Nov 2015 12:21:41 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20151113112141.GN89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1XmnKQGVLLNJnMip" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 11:21:45 -0000 --1XmnKQGVLLNJnMip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 13, 2015 at 08:18:42PM +0900, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 5:05 PM, Gert Doering wrote: >=20 > > There are bits and pieces missing to make this a complete solution > > (namely, source address failover or "source address happy eyeballs"), >=20 > I think you can address most of this by deprecating addresses when an > upstream goes away. Networks break further upstream, without the actual upstream being noticeab= le broken. Networks break certain paths, while others are working fine. We can do better than all-or-nothing. We should. 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 --1XmnKQGVLLNJnMip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkXHxd9WwGXkzn/FAQKkPhAAkLjY5/+Rbi74N5E6SHVvdMGMOYcGeDA7 yMZgN6aU5ksxMqRKDNVk++FfDEiOtVIF4eMFyaxbCq+Z+vxys+hylYBUCINe5zI/ SFryCLp271ksVpEmXmqYJKKm9m/YTLvtLvJgODTlUVrMblIjKnTTeeojuCpsfjk8 GfablSVX25zFijUKCVjp2HClP1hNckPKy+7w298rwMAvoQYc3NqYNwPEMUsXyvOi v9/pb+RUKc/wclE6EKdon2Vt9kbRUSdDm1XB2S5Q6X0OBScbgyLj+HsMuO801dKO 6k6n1rklFxVsbqxBnWpZPqLT+Khg9PWAqeD7afvlL+K6u67sjOkY9PmUs7C40EeY 1J59xBylMwO0njKpuHzq72ksGCHRjdgUuCWbJK4qn6i6zUX/k6BBnq5Dkyi4geE7 7soljYLRxWGIGNlHiq5WUwlCOWUIQZZQxbNREOkJup8rMLDA+k/1gy9CYwIf93lX pfSRgNGWOim4JNkBYDvijCnNPx2cOwGELUylLQ4lBhsoNz6Eu7tAOkhBGnGL9HJC zLXVtUG8gAz3iNx8V2xvWiuAK/V8n16z5boMW6Bx2LSxjluLTmCP6q+dZGFtMtY8 92fwQDpqFFm7D+87Ko27MyqADhvfziQKLZ0+6Y8bW/sjuC6T60oWWd3DjdCVpqBl eu6xaorzkQU= =d0ws -----END PGP SIGNATURE----- --1XmnKQGVLLNJnMip-- From nobody Fri Nov 13 03: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 9D07F1ACC83 for ; Fri, 13 Nov 2015 03:26:14 -0800 (PST) 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 n5A7SmQhed5S for ; Fri, 13 Nov 2015 03:26:13 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 9771A1AC442 for ; Fri, 13 Nov 2015 03:26:13 -0800 (PST) Received: by ykba77 with SMTP id a77so140415043ykb.2 for ; Fri, 13 Nov 2015 03:26:13 -0800 (PST) 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=TqdHja+Wm93TCTZkq8Xg0tIzg3OKVVimlJy+ATrG0BY=; b=R9lZbdrhw0d02/CgNWyEsWW15IT1sSS49gGPx2TU5pMsCLhaBwfn7kqB8ASyeSRG1k /sMCdjZnCsaqXphmjhjPBi8HJjiB4KxgQ+2mXUiSXgtP7X95ZfnCfx0u1YhVaD1pyYEo ppEsPMwsXEz/Id9N6vVqZpaQJ5VcLhKsyo0Re4BilATgOpKHpo4S5XxZyVGTtb65s3TZ J7nrbusZ9Z+s4/lAr2XDNnCmxSErr9uOKuBCyguH6LjSLjvOZVcsjBCuIDa+p2+sctjX Y3nc83eSYfyov65uvzIGDbx/gG7l0XUvc5/jlt3W7dPdePXN0YLoTgUc7qzsnCf77KQ8 B3/w== 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=TqdHja+Wm93TCTZkq8Xg0tIzg3OKVVimlJy+ATrG0BY=; b=DyfErDQAutrEFi2r+zgRsgGvxSK2j1+AwudliyRr4WboGsbiWh8OyPYQD3T1REvZyq L6hkGZSUPxEy8Xl5TlP/Z8nrg7K3WmfyEx4yLeIrgxr3n9XGx9Tl6ldNbl8pChAfbcqi b2oLqJIshsiRtHibpjWmLHe9fYZG7yfXFtJfiuyTNUmVA3dqDSx3qLx+8Go0FG/Q9KZT ucwACPdm6AWNCurVHPDizgpzozHRk/XEV849ZWjqHUSYHzElnEXnEWRg6s9qO9Jqr9Um WzuYweHaZeum3nzg0cE/z+wE73j4ZtPlEYb4EeU2peYiWaFZqFuDV4Fdu3oBCV+8/l8N Y5kg== X-Gm-Message-State: ALoCoQmHD4uya0GAyuaJ7tY+bVNu/2dfdUMztkK/92urRyrYuLI/QeXGkLHK0K6lzwaDrcsYJhtO X-Received: by 10.129.136.5 with SMTP id y5mr22074545ywf.35.1447413972834; Fri, 13 Nov 2015 03:26:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Fri, 13 Nov 2015 03:25:53 -0800 (PST) In-Reply-To: <20151113112141.GN89490@Space.Net> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> From: Lorenzo Colitti Date: Fri, 13 Nov 2015 20:25:53 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a114effbab20f9f05246a5309 Archived-At: Cc: "" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 11:26:14 -0000 --001a114effbab20f9f05246a5309 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 8:21 PM, Gert Doering wrote: > > I think you can address most of this by deprecating addresses when an > > upstream goes away. > > Networks break further upstream, without the actual upstream being > noticeable broken. Networks break certain paths, while others are working > fine. > True, but this happens today with RFC1918+NAT multihoming as well. > We can do better than all-or-nothing. We should. > Agreed. But even if we don't, we won't be making things worse. --001a114effbab20f9f05246a5309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Nov 13, 2015 at 8:21 PM, Gert Doering <gert@space.net> wrot= e:
    > I think yo= u can address most of this by deprecating addresses when an
    > upstream goes away.

    Networks break further upstream, without the actual upstream be= ing noticeable=C2=A0broken.=C2=A0 Networks break certain paths, while other= s are working fine.

    True, but this happ= ens today with RFC1918+NAT multihoming as well.
    =C2=A0
    We can do better than all-or-nothing.=C2=A0 We sh= ould.

    Agreed. But even if we don't,= we won't be making things worse.
    --001a114effbab20f9f05246a5309-- From nobody Fri Nov 13 04:31: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 EDFF41A049A for ; Fri, 13 Nov 2015 04:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 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, 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 1Z4SYsnyJ10K for ; Fri, 13 Nov 2015 04:31:35 -0800 (PST) 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 997661A19EF for ; Fri, 13 Nov 2015 04:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1512; q=dns/txt; s=iport; t=1447417887; x=1448627487; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xH9bv61POhqGmcA1E9AAr5q6m64iRt2IZtpbZGf8PTc=; b=NlezyfkKIfbxnknxlI3f6/ObxWMbJ0oj+1hxXnKOVmk56GkD/ElAzOwG 6oGzC6030sm032bsosTpyow2Yr03o3u2gevze62vQ1t+6UQ3EhyUozW2V qnFMXxgYVzjhLd1e8xLGeie3jfoFg/TRmGLUYZGrEzsO39zqHUP5eVZOS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmAgDg1kVW/5pdJa1egzuBQga+PAENgWWGEAIcgSk4FAEBAQEBAQGBCoQ0AQEBBCMRRRACAQYCEQQBAQMCIwMCAgIwFAEICAIEAQ0FCIgmknmdNZBXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGEcYMEgUQBBJZIAY0fnEsBHwEBQoIRHYFWcoQ2gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,287,1444694400"; d="scan'208";a="206599570" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 13 Nov 2015 12:31:25 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tADCVPtZ021171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 12:31:25 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 07:31:24 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 07:31:24 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQA== Date: Fri, 13 Nov 2015 12:31:24 +0000 Message-ID: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 12:31:37 -0000 DQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEyLCAyMDE1IDEw OjA3IFBNDQpUbzog56We5piO6YGU5ZOJDQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdjZvcHNdIERBRCBhZ2FpbiBbd2FzOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFp bGFiaWxpdHkgZGlzY3Vzc2lvbl0NCg0KDQo+QXQgbW9zdCB3ZSBjb3VsZCBzbGlnaHRseSBhbWVu ZCB0aGlzIHRvIC4uLiJNVVNUIGJlIHBlcmZvcm1lZCBvbiBhbGwgdW5pY2FzdCBhZGRyZXNzZXMg cHJpb3IgdG8gYXNzaWduaW5nIHRoZW0gdG8gYW4gaW50ZXJmYWNlIGV4Y2VwdCBhIGxvb3BiYWNr IGludGVyZmFjZSIuIEV2ZW4gbm9kZS1pbnRlcm5hbCBpbnRlcmZhY2VzIGFyZSBub3QgPm5lY2Vz c2FyaWx5IHNhZmUgdG8gb21pdCBEQUQgb24uIEZvciBleGFtcGxlLCBpbiBhIG1vYmlsZSBkZXZp Y2UgdGhlIGFwcGxpY2F0aW9uIHByb2Nlc3NvciBhbmQgYmFzZWJhbmQgcHJvY2Vzc29yIG1pZ2h0 IGJvdGggYmUgb24gdGhlIHNhbWUgbGluaywgYW5kIGJlY2F1c2UgdGhleSBhcmUgdHdvIHNlcGFy YXRlIHByb2Nlc3NvcnMgPnJ1bm5pbmcgdHdvIHNlcGFyYXRlIG5ldHdvcmsgc3RhY2tzLCB0aGV5 IG5lZWQgdG8gZG8gREFELg0KDQpBcHBlbmRpeCBBIG9mIFJGQzQ4NjIgYWxyZWFkeSBjYXV0aW9u cyBhZ2FpbnN0IGEgbG9vcGJhY2sgaW50ZXJmYWNlIGxvb3BpbmcgYmFjayBEQUQgcHJvYmVzLiAg RGlkIHlvdSBoYXZlIGFueSBvdGhlciByZWFzb24gdG8gZGlzYWJsZSBEQUQgZm9yIGEgbG9vcGJh Y2sgaW50ZXJmYWNlPyAgRm9yIGV4YW1wbGUsIG9uIGEgcm91dGVyLCBhIGxvb3BiYWNrIGludGVy ZmFjZSBpcyBjb25maWd1cmVkIGFuZCB0aGUgSVB2NiBhZGRyZXNzIG9uIHRoZSBpbnRlcmZhY2Ug aXMgdXNlZCB0byBzb3VyY2UgcGFja2V0cy4gIFdoeSB3b3VsZCBvbmUgbm90IHBlcmZvcm0gREFE IGZvciB0aGUgSVB2NiBhZGRyZXNzIHVzZWQgYnkgdGhlIGxvb3BiYWNrIGludGVyZmFjZT8NCg0K VGhhbmtzLA0KDQpIZW1hbnQNCg== From nobody Fri Nov 13 04:49: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 3331A1A21AF for ; Fri, 13 Nov 2015 04:49:24 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.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 karM69hOk5Iw for ; Fri, 13 Nov 2015 04:49:22 -0800 (PST) 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 0195B1A21A4 for ; Fri, 13 Nov 2015 04:49:22 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZxDn5-0000EpC; Fri, 13 Nov 2015 13:49:19 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> In-reply-to: Your message of "Fri, 13 Nov 2015 12:21:41 +0100 ." <20151113112141.GN89490@Space.Net> Date: Fri, 13 Nov 2015 13:49:13 +0100 Archived-At: Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 12:49:24 -0000 >Networks break further upstream, without the actual upstream being >noticeable >broken. Networks break certain paths, while others are working fine. > >We can do better than all-or-nothing. We should. I don't think a host should try to figure out which paths work and which don't. Maybe somebody can come up with a simple algorithm that generalises happy-eyeballs and that is compatible with today's host operating systems. But I doubt it. So while we wait for hosts to magically figure out what works and what doesn't (and for mobile hosts, in any possible context, even when there is high packet loss on the local link, etc), I propose that routers just inform hosts which source prefixes are unusable according to unspecified monitoring code running on the router. (Obviously, routers should also propate that knowledge over internal routing protocols in setups with multiple routers). From nobody Fri Nov 13 04:49: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 6EB151A21B8 for ; Fri, 13 Nov 2015 04:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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_SE=0.35, 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 Bppbk6rCO8U5 for ; Fri, 13 Nov 2015 04:49:26 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738031A21AF for ; Fri, 13 Nov 2015 04:49:26 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E95FA2; Fri, 13 Nov 2015 13:49:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1447418964; bh=5mHsWBsK/XRaZHPIQYDo8q/ywM4QintyryE7K/i4Tac=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Bw7QSnHINfvz+M7auhmsk2f3ZtY71buy/Bl1jOoKnsM1nn/pyOvBwt6J67I4LWReJ ncUtbKF7DOVMRbI0gVGSeRt0L3QASllqw/GqVlbpUTHhJXdSSNkUHR5aNOm/faZvRc +xWJ65vDJhuXhFN6EqSTJZc91NEEnS/jdWWJmE0Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5615FA1; Fri, 13 Nov 2015 13:49:24 +0100 (CET) Date: Fri, 13 Nov 2015 13:49:24 +0100 (CET) From: Mikael Abrahamsson To: George Michaelson In-Reply-To: Message-ID: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 12:49:27 -0000 On Fri, 13 Nov 2015, George Michaelson wrote: > Strong +1. We need to stop using FUD on future routing cost to limit how we > design systems for enterprises and homes. By all means lets constrain > current behaviour to scale with memory and CPU, but to set limits 5-10-15 > years out based on fear of a situation which is unlikely to emerge, and > will emerge into different technology and models.. Well its sad. > > Its Dionysius Lardner "60mph will kill humans, stop speeding up steam > trains" thinking. > > Whats even weirder, is that its some people who helped displace prior art, > telephone number centric thinking who are doing it. How come the former > rebels have become the empire? I have been involved in Internet core routing for 15 years. I've seen the routing table grow from around 100k entries, to 650k or so. Yet, as far as I can tell, state of the art platforms still can't install routing updates faster than around 10k prefixes per second, which is not significantly faster than 15 years ago. What has changed is a lot of advanced mechanisms to work around this problem, plus faster CPUs so changes propagate faster so we have less flapping of routes. No significant improvement in the routing system has happened during this time, and I don't see any in the works. Doing route lookups is costly, larger tables mean more power consumption etc. I'm sure we can design routers that can handle 10x the prefixes they can today, but at what cost? Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe? IP has become successful because the core doesn't have to keep state for L4 connections, but if we radically increase the state needed to be kept for L3 destinations, we will most likely run into problems. Yes, they might be solved, but currently we do not know how. So I would very much like to stay away from an architecture that suggests "PI for everybody". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Nov 13 04:56: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 19EE41A6F0A for ; Fri, 13 Nov 2015 04:56:45 -0800 (PST) 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 f2PMfqpBA-YL for ; Fri, 13 Nov 2015 04:56:43 -0800 (PST) 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 3DD0B1A6F07 for ; Fri, 13 Nov 2015 04:56:43 -0800 (PST) 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 tADCufgC022199 for ; Fri, 13 Nov 2015 13:56:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DEF8320501F for ; Fri, 13 Nov 2015 14:02:52 +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 DA35B204FFA for ; Fri, 13 Nov 2015 14:02:52 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tADCudOC024198 for ; Fri, 13 Nov 2015 13:56:40 +0100 To: v6ops@ietf.org References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <5645DE07.3050605@gmail.com> Date: Fri, 13 Nov 2015 13:56:39 +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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 12:56:45 -0000 Le 13/11/2015 13:31, Hemant Singh (shemant) a Ă©crit : > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo > Colitti Sent: Thursday, November 12, 2015 10:07 PM To: 神ćŽé”哉 Cc: > v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: > draft-ietf-v6ops-host-addr-availability discussion] > > >> At most we could slightly amend this to ..."MUST be performed on >> all unicast addresses prior to assigning them to an interface >> except a loopback interface". Even node-internal interfaces are not >> >necessarily safe to omit DAD on. For example, in a mobile device >> the application processor and baseband processor might both be on >> the same link, and because they are two separate processors >> >running two separate network stacks, they need to do DAD. > > Appendix A of RFC4862 already cautions against a loopback interface > looping back DAD probes. Did you have any other reason to disable > DAD for a loopback interface? For example, on a router, a loopback > interface is configured and the IPv6 address on the interface is used > to source packets. Why would one not perform DAD for the IPv6 > address used by the loopback interface? One wouldnt care about DAD on loopback interface, because it's not noise on a wire, and it's not time consuming. Alex > > Thanks, > > Hemant _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Nov 13 05:00: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 8EFD51A6F27 for ; Fri, 13 Nov 2015 05:00:23 -0800 (PST) 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 0Rd3gXA6EbV9 for ; Fri, 13 Nov 2015 05:00:21 -0800 (PST) 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 536191A6F32 for ; Fri, 13 Nov 2015 05:00:21 -0800 (PST) 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 tADD0ISr013794 for ; Fri, 13 Nov 2015 14:00:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0B68204FAD for ; Fri, 13 Nov 2015 14:06:30 +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 A920D204F10 for ; Fri, 13 Nov 2015 14:06:30 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tADD0ICU028415 for ; Fri, 13 Nov 2015 14:00:18 +0100 To: v6ops@ietf.org References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <5645DEE2.5050108@gmail.com> Date: Fri, 13 Nov 2015 14:00:18 +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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 13:00:23 -0000 Le 13/11/2015 04:06, Lorenzo Colitti a Ă©crit : > On Fri, Nov 13, 2015 at 11:36 AM, 神ćŽé”哉 > wrote: > > I think I understand what you are trying to say, and I tend to agree > that it would be quite unlikely that someone else than node 'N' is > using address 'A' in the WAN link in practice in this scenario. > However, I think it's dangerous to just jump to the conclusion that > DAD is not necessary in this case in some kind of standard document. > In my understanding, DAD is designed to cover "quite unlikely > scenarios" including cases with some broken > implementations/operation. In this particular scenario, I would say > that the original intent of DAD covers an "unlikely" case where the > remote (or some other, depending the type of link) node of the WAN > link is broken or some invalid operation and is actually using > address "A". > > > RFC 4862 is says: Duplicate Address Detection MUST be performed on > all unicast addresses prior to assigning them to an interface. > > That is true in almost all cases, including DHCPv6 PD. For example, > if a device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi > hotspot, then any address that the device itself forms out of that > /64 MUST perform DAD so that other devices connected to the wifi > hotspot do not use the same address. YEs, but there are additional cases of assigning an address of the delegated prefix. The device is a non-tethering device, forms an address out of the delegated prefix, and assigns it on its egress interface. Since the prefix is delegated to that device exclusively then the device is safe to assume no-one else would form an address ouf of it. Hence no need of DAD. > At most we could slightly amend this to ..."MUST be performed on all > unicast addresses prior to assigning them to an interface except a > loopback interface". That sounds reasonable for the loopback interface. Alex Even node-internal interfaces are not > necessarily safe to omit DAD on. For example, in a mobile device the > application processor and baseband processor might both be on the > same link, and because they are two separate processors running two > separate network stacks, they need to do DAD. > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Nov 13 05: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 4AE0F1A6FE7 for ; Fri, 13 Nov 2015 05:18:25 -0800 (PST) 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 WJkqnk7S9MIX for ; Fri, 13 Nov 2015 05:18:22 -0800 (PST) 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 58FEE1A6FD6 for ; Fri, 13 Nov 2015 05:18:21 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 944EA632D5 for ; Fri, 13 Nov 2015 14:18:19 +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 4F53E62D2C for ; Fri, 13 Nov 2015 14:18:19 +0100 (CET) Received: (qmail 95445 invoked by uid 1007); 13 Nov 2015 14:18:19 +0100 Date: Fri, 13 Nov 2015 14:18:19 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20151113131819.GP89490@Space.Net> References: <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sz/4MAOlM1c8JZ8/" 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] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 13:18:25 -0000 --Sz/4MAOlM1c8JZ8/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 13, 2015 at 01:49:13PM +0100, Philip Homburg wrote: > >Networks break further upstream, without the actual upstream being > >noticeable > >broken. Networks break certain paths, while others are working fine. > > > >We can do better than all-or-nothing. We should. >=20 > I don't think a host should try to figure out which paths work and which > don't. I disagree, and strongly so. Maybe not "probe all paths at the same time", but if one is not working, it would be silly not to try alternatives if they exist. [..] > I propose that routers just inform hosts which source prefixes are unusab= le > according to unspecified monitoring code running on the router. (Obviousl= y, > routers should also propate that knowledge over internal routing protocol= s in > setups with multiple routers). So, if you have upstreams A and B, and targets C and D, of which "C" cannot be reached over "A" and "D" not via "B" (not all that unlikely given the direction in which low-price SoHo ISPs and peering wars are developing), would you rather declare both broken, or just use B to reach C, and A to reach D? Defining "the upstream is broken" is actually fairly hard - the router might be perfectly happy about upstream A, because 99% of its monitoring targets work perfectly well - but if the user's 1% that he wants to talk to do not work (routing hickup, anycast cluster broken, peering overloaded), it is the wrong conclusion to declare "it is working, no need to try anything else"... 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 --Sz/4MAOlM1c8JZ8/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkXjG99WwGXkzn/FAQIdqA//dCRXRX35vggsMSE8z0/GLCOFs6W2C0N4 OpHJ4hW1i4jNtV2LqZS1PE7WYKjwn+sHwJMr58E0yedyr1SGZVKUtwTrhZEd57Mz T56JbnSiRIBEByMHrcPkDB8jNac6f4ERlSCDVwXHq4icLTY0AkJLwqTUqIxc6Q8H gVnRFL136iAIsOcu8vpHsxJrCU+eyJ/1mzh6vPRvLyUhTQiuf/xQMtCxC3Q+DPWK LmpqfVjJEfr+ceOKPtSnDKeaqFQAzNmvfQYugmnVFqrOVvcfdB09g0yhhBGmdtdh zPRsPqEIFm4wNVmAOl658OZSZwt8+6Ei3/cOBl6jgnfWid5UfmHxJmcHu6QpDLbk PBY7sCuKjyRDY/4eTPAx5UP4+0b8HWwbxJseTsy4Lq4iZ60+08hwGP+7GHssHWEk nTXbaBXLvcR2gZi//bdYomXWAjQ/Fa1LFqKqvsYvkWq9Nnu5bAoDn1OPFbCcGi0d h8FuQGOezIIOTh6Al8+e34dBf4i9vr6lcoVleG9cY/HMND4CIrCAh6YSXtaVPlSH QcbAgNNa+HPLF74OwgPgRA+N2LjXh+K/FU4RfDKIFdb+qOTKxGumiNbtR/2Z9lLJ WASDt8S6KyFRzNCVNmcobT7zZJGqI0Dt2owXQ9+cHfKesLCCFqFxa8CQq9s0bhnK DdAylFMerco= =mDs8 -----END PGP SIGNATURE----- --Sz/4MAOlM1c8JZ8/-- From nobody Fri Nov 13 05:23: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 960E31A86DF for ; Fri, 13 Nov 2015 05:23:35 -0800 (PST) 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 wXDGTacEgVdX for ; Fri, 13 Nov 2015 05:23:33 -0800 (PST) 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 D079C1A702E for ; Fri, 13 Nov 2015 05:23:33 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2C9E5D7884; Fri, 13 Nov 2015 05:23:33 -0800 (PST) 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=3HEaqiHVqPw6kWkSxnf38W9V3tU=; b= EO+55lYJvJTVG1z87cAlPUQF+ocRSm0RG/7PDBDigruYnxwZeae+Xah5XJukorW/ q1XCM0N3XhBXzrFFvvjxEaQdwFcdEPN6qVeYQ86BPkMnj4VhtjAXlcHDW3HqvkJp IXM3dJc1DRxrEXafdhZvrt0UzRjhBP/q91Q8+J70F6Q= 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=lJp/Kpj4JqirG3VpZnl7qpLDuQ 2PqcXtNLAOfcELchwQo8sIQNCpewk8eWw4wkMLpz07RqrS5zixEBn7axE1X2Gc7q mfZa6slxNh/H7WPiXuvaV/ExEOawr1W02QAnDL6XFBeB/y/XU16XtrsSi4nSGpav 3tHKzl97bouO0gLHg= Received: from h.hanazo.no (unknown [173.38.220.36]) (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 B9CB4D7883; Fri, 13 Nov 2015 05:23:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id AA3A199FD0D; Fri, 13 Nov 2015 14:23:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_71D552D8-99CB-47C8-B4F4-049E8FD55B62"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20151113131819.GP89490@Space.Net> Date: Fri, 13 Nov 2015 14:23:29 +0100 Message-Id: <19FF351D-1C3F-43B8-9F47-8E190A3843D2@employees.org> References: <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <20151113131819.GP89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 13:23:35 -0000 --Apple-Mail=_71D552D8-99CB-47C8-B4F4-049E8FD55B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gert, >>> Networks break further upstream, without the actual upstream being >>> noticeable >>> broken. Networks break certain paths, while others are working = fine. >>>=20 >>> We can do better than all-or-nothing. We should. >>=20 >> I don't think a host should try to figure out which paths work and = which >> don't. >=20 > I disagree, and strongly so. Maybe not "probe all paths at the same = time", > but if one is not working, it would be silly not to try alternatives = if > they exist. >=20 > [..] >> I propose that routers just inform hosts which source prefixes are = unusable >> according to unspecified monitoring code running on the router. = (Obviously, >> routers should also propate that knowledge over internal routing = protocols in >> setups with multiple routers). >=20 > So, if you have upstreams A and B, and targets C and D, of which "C" = cannot > be reached over "A" and "D" not via "B" (not all that unlikely given = the > direction in which low-price SoHo ISPs and peering wars are = developing), > would you rather declare both broken, or just use B to reach C, and A = to > reach D? >=20 > Defining "the upstream is broken" is actually fairly hard - the router = might > be perfectly happy about upstream A, because 99% of its monitoring = targets > work perfectly well - but if the user's 1% that he wants to talk to do = not > work (routing hickup, anycast cluster broken, peering overloaded), it = is > the wrong conclusion to declare "it is working, no need to try = anything > else"... exactly. the end-points has much more information about the end to end = path than the first-hop router has. unless you want it to be a DPI/layer violating/state-hogging middlebox. even having every router participate in global routing wouldn't help you = very much. global routing has convergence times measured in many = minutes. cheers, Ole --Apple-Mail=_71D552D8-99CB-47C8-B4F4-049E8FD55B62 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 iQIcBAEBCgAGBQJWReRSAAoJEL7aWKiYQt92ABsP/2yLgTc+yabIQdKhFLmpBI2Y 1tb3kfhErNYCivM7DnTXVqi/+xgFWCuW8PMsVJOeaOqJHSMBe7AGxBkf9ffsfINb zHi5q7zK4CAKbjYtxKC8C5saCIm9Sl0VOxIlV1uu7xQ2PE1PpjoNdvyo0Wthet6y Gg9k/s99CG/iRPvMVKYkg4wJe95IhlAti1odj2O2e3JytDg5dOvN9/TCJ5oBoKFl 9QCA81S6elbtvXuW4uNTlcpG0eCUDtfM2CDYGKjSmXHkXzzJoGyFYbeONNn1ZLf+ Q2RJU9yi/sh4maZnb0NAEpSutLba1ouVVckg3VzEXN1FHKEawhwzDjyeKBYzdrif 5i9EWaUL16ZFjf33dUhPwmUenm+e2PPe3Ptz1DhcQQZ+OAd4dki0E95rIgbOsPSn EQbQhLDk3ISqcEtlkvjf8xjNoVucnut99izMiRUGHtY+KoJZI0LeRAaAkTmPSlbA 3dui1LkH3HYEv5o7NzcJT9j/FvCwl+nFSP6TjwOryNkeuwxdeQJMsrtXpkhYNbQ9 2+J/ZE8Qi+FEwXKkTdX0LRVimMgBOFaHnZh1jyov9Gl3NtmFs0cuSBxl7diTj5WV Jk/xjIzyeot3G0dXCQGVW0HU4TYyLPj4+eCTPiVN8gTifg0+3+chuaXgBkfPiNob ZVfBGaCrUU5s0dA/1Z85 =Rd6M -----END PGP SIGNATURE----- --Apple-Mail=_71D552D8-99CB-47C8-B4F4-049E8FD55B62-- From nobody Fri Nov 13 05:27: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 4AFCF1A870F for ; Fri, 13 Nov 2015 05:27:29 -0800 (PST) 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 bf0ckNt84Dfb for ; Fri, 13 Nov 2015 05:27:28 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE88C1A8711 for ; Fri, 13 Nov 2015 05:27:27 -0800 (PST) Received: from [IPv6:2601:545:8200:e761:6aa8:6dff:fe54:e0a0] ([IPv6:2601:545:8200:e761:6aa8:6dff:fe54:e0a0]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id tADDRPUk029074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 08:27:26 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael H Lambert In-Reply-To: Date: Fri, 13 Nov 2015 08:27:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 13:27:29 -0000 > On 13 Nov 2015, at 07:49, Mikael Abrahamsson wrote: >=20 > Also, why should a core router in Europe have to care about an office = connection being affected by something on the other side of the globe? Indeed. Unless one is intentionally trying to design a chaotic system. Michael From nobody Fri Nov 13 05: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 C2C6E1A878C for ; Fri, 13 Nov 2015 05:40:37 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.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 vx-FVLqb15xw for ; Fri, 13 Nov 2015 05:40:33 -0800 (PST) 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 909011A87A1 for ; Fri, 13 Nov 2015 05:40:32 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZxEac-0000DKC; Fri, 13 Nov 2015 14:40:30 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <20151113131819.GP89490@Space.Net> In-reply-to: Your message of "Fri, 13 Nov 2015 14:18:19 +0100 ." <20151113131819.GP89490@Space.Net> Date: Fri, 13 Nov 2015 14:40:19 +0100 Archived-At: Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 13:40:37 -0000 >> I don't think a host should try to figure out which paths work and which >> don't. > >I disagree, and strongly so. Maybe not "probe all paths at the same time", >but if one is not working, it would be silly not to try alternatives if >they exist. Given the current interfaces in mainstream operating systems and lack of specified algorithms, I'm not holding my breath until this happens on a large scale. From nobody Fri Nov 13 05:43: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 038E21A87CA for ; Fri, 13 Nov 2015 05:43:17 -0800 (PST) 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 uftWjdYw_kMo for ; Fri, 13 Nov 2015 05:43:16 -0800 (PST) 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 D51571A87C6 for ; Fri, 13 Nov 2015 05:43:15 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E4CFA62E64 for ; Fri, 13 Nov 2015 14:43:13 +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 A9ABF60A87 for ; Fri, 13 Nov 2015 14:43:13 +0100 (CET) Received: (qmail 97674 invoked by uid 1007); 13 Nov 2015 14:43:13 +0100 Date: Fri, 13 Nov 2015 14:43:13 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20151113134313.GS89490@Space.Net> References: <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <20151113131819.GP89490@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dvhSTuvbbQltApUS" 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] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 13:43:17 -0000 --dvhSTuvbbQltApUS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 13, 2015 at 02:40:19PM +0100, Philip Homburg wrote: > >> I don't think a host should try to figure out which paths work and whi= ch > >> don't. > > > >I disagree, and strongly so. Maybe not "probe all paths at the same tim= e", > >but if one is not working, it would be silly not to try alternatives if > >they exist. >=20 > Given the current interfaces in mainstream operating systems and lack of > specified algorithms, I'm not holding my breath until this happens on a > large scale. "Not holding your breath" is sort of the wrong answer to "the IETF should g= et busy and solve this", no? 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 --dvhSTuvbbQltApUS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkXo8d9WwGXkzn/FAQKJxw/5Addzpezjox1CjTGp4Ubi1CyEbEHYEy7G hIiMneZ8i7uOeXYkahX5wt/OVBLNEqZyPN2GIVUK6cUEza/c5BO92+SaDIRTcIdo RRRwx8jY59FZQ8SW2mYOgHS8DJPtttaWSabxZF8C9fCCGxu9/r1UToxtA+hhAOj2 6Zk32XgKmlwQvBfC2VA0DlSmuu51+YzBQ+R43vTQxdL4LVAwemtbyT4pybass3sA ASyialVhIEK500uDf3I5bxWe20BSkGQv56gtOF/Ruw8+jFAseYBawkCiUKJTwOns 7fk6MupoH0f2pf2iFaGCiGbkCK5ygcSuh1MhmafHpK5zTxTxmW0Oy5vkgG9/EDna CXc65ftStZTbLMxfByuc1RZTRHmGbc9LmJw3mvAaODPgtZqvpztlQcpAF1CAKnGu ThhWE+3SkP2DZRg0FRXf75EaGHB2I9kXw35OlS6/RBZB733P1QoJRNigYN6GZfXF 22ZXTSFINJDEksv+qrqpld3gnVyXq1GSAR4kSoaJHR8O1by/mc308EKo61BBdSmG dfJDdEGKzx/0JE748UVoA+Nd11ipR5KZao30rR1sYeHKjR4ZFl8zrRJUCE5o6nFj 5hv3ACxSv7NZIatrASdqnteCutsYgb9VPIKSgmVhQYyXoDaSbdOhLAp885aKcnuS 1q4HWGBL9zE= =zxk1 -----END PGP SIGNATURE----- --dvhSTuvbbQltApUS-- From nobody Fri Nov 13 05:47: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 81E6A1A87E4 for ; Fri, 13 Nov 2015 05:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziA88LglyE7w for ; Fri, 13 Nov 2015 05:47:07 -0800 (PST) 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 E84C41A87E9 for ; Fri, 13 Nov 2015 05:47:05 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tADDl3qv043710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 13:47:03 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local To: Michael H Lambert , "v6ops@ietf.org WG" References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> From: Nick Hilliard Message-ID: <5645E9D7.4070009@foobar.org> Date: Fri, 13 Nov 2015 13:47:03 +0000 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: <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 13:47:09 -0000 On 13/11/2015 13:27, Michael H Lambert wrote: >> On 13 Nov 2015, at 07:49, Mikael Abrahamsson wrote: >> Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe? > > Indeed. Unless one is intentionally trying to design a chaotic system. The type of chaos which which involves most ASNs having a full view of the Internet is less bad than the type where only a handful of them do. Nick From nobody Fri Nov 13 05:50: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 500381A8836 for ; Fri, 13 Nov 2015 05:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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_SE=0.35, 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 tJ9ODgbi7mLL for ; Fri, 13 Nov 2015 05:50:18 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F76F1A8831 for ; Fri, 13 Nov 2015 05:50:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0430CA2; Fri, 13 Nov 2015 14:50:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1447422616; bh=uzooHDokiqihF8sijLxxhyOQ5sfKzItiZe9YoHgVs88=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=EXzbDCGE9EpTeISlPJt1hJBLIzTWZcOj3SRcjqoUKhHhhdZzrjh54kM3XegT8M6JX 3YMy0Hc7so49+QmAE+JBgy24Q6ajtekcICenxp6Guj9deqnIWLIL/9bUd7AZ1+aTdC dmiNlXa28fZl76FyuiWPctXhQr4+khTK5E71gH5U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F049DA1; Fri, 13 Nov 2015 14:50:15 +0100 (CET) Date: Fri, 13 Nov 2015 14:50:15 +0100 (CET) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <5645E9D7.4070009@foobar.org> Message-ID: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 13:50:20 -0000 On Fri, 13 Nov 2015, Nick Hilliard wrote: > On 13/11/2015 13:27, Michael H Lambert wrote: >>> On 13 Nov 2015, at 07:49, Mikael Abrahamsson wrote: >>> Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe? >> >> Indeed. Unless one is intentionally trying to design a chaotic system. > > The type of chaos which which involves most ASNs having a full view of the > Internet is less bad than the type where only a handful of them do. If the Internet will have 10x the number of routes it has today in the not-so-distant-future, there is a considerable risk that most smaller players won't be able to afford to have a full view. I already know people today who do route filtering because their devices might only have 256k TCAM slots. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Nov 13 05:58: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 990F21A8873 for ; Fri, 13 Nov 2015 05:58:06 -0800 (PST) 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 twDvaTcKvnJG for ; Fri, 13 Nov 2015 05:58:05 -0800 (PST) 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 939D01A886B for ; Fri, 13 Nov 2015 05:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=872; q=dns/txt; s=iport; t=1447423086; x=1448632686; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LydibOKI0IFWCl8b7tzkZIOiDSybmlPxREkuB6YXv0U=; b=cquRLSXQCJ3XIQsV8xaieSAV4aOSj8dica3aBZ37p1rwyF4eegt85bsm +hSG88ha1Sl6DE+XqxciGrd/qQrTDcGHmE/Sne0O54+rzkNgISdhbmh2W OCxT0LTfL84DAnpkNOSpsHFq1KggAsbSMAIC9IyrphnXBt1CuU//6UpD9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmAgAQ7EVW/5BdJa1egzuBQga+QAENgWWGEAIcgR44FAEBAQEBAQGBCoQ0AQEBBCMRUQQCAQgRBAEBAwIjAwICAjAUAQgIAgQBEgiIJrAokFYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGKUYd1gUQBBIdGjwIBjR+cSwEfAQFCghEdgVZyhDaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,287,1444694400"; d="scan'208";a="207231014" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 13 Nov 2015 13:58:06 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tADDw4cO016531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 13:58:04 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 08:58:03 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 08:58:04 -0500 From: "Hemant Singh (shemant)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puA= Date: Fri, 13 Nov 2015 13:58:04 +0000 Message-ID: <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> In-Reply-To: <5645DE07.3050605@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.86.241.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 13:58:06 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1DQpTZW50OiBG cmlkYXksIE5vdmVtYmVyIDEzLCAyMDE1IDc6NTcgQU0NClRvOiB2Nm9wc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gREFEIGFnYWluIFt3YXM6IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1h ZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uXQ0KDQoNCj5PbmUgd291bGRudCBjYXJlIGFib3V0 IERBRCBvbiBsb29wYmFjayBpbnRlcmZhY2UsIGJlY2F1c2UgaXQncyBub3Qgbm9pc2Ugb24gYSB3 aXJlLCBhbmQgaXQncyBub3QgdGltZSBjb25zdW1pbmcuDQoNClNvIGhvdyB3aWxsIHlvdSBkZWFs IHdpdGggYSBkdXBsaWNhdGUgSVB2NiBhZGRyZXNzIGNvbmZpZ3VyZWQgb24gYSBsb29wYmFjayBp bnRlcmZhY2U/ICBBcyBJIHNhaWQgaW4gbXkgZXhhbXBsZSwgYSByb3V0ZXIgaXMgdXNpbmcgdGhl IElQdjYgYWRkcmVzcyBvbiBhIGxvb3BiYWNrIGludGVyZmFjZSB0byBzb3VyY2UgcGFja2V0cyBh bmQgYSBkdXBsaWNhdGUgaXMgZGV0ZWN0ZWQgLSB0aGUgbmV0d29yayBicmVha3MgZG93bi4NCg0K SGVtYW50DQo= From nobody Fri Nov 13 06:08: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 A484E1A88DA for ; Fri, 13 Nov 2015 06:08:34 -0800 (PST) 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 gyxKMh9bDoZk for ; Fri, 13 Nov 2015 06:08:32 -0800 (PST) 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 A48521A886D for ; Fri, 13 Nov 2015 06:08:32 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C540960AA4 for ; Fri, 13 Nov 2015 15:08:30 +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 60EE46099E for ; Fri, 13 Nov 2015 15:08:30 +0100 (CET) Received: (qmail 99505 invoked by uid 1007); 13 Nov 2015 15:08:30 +0100 Date: Fri, 13 Nov 2015 15:08:30 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20151113140830.GT89490@Space.Net> References: <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 14:08:34 -0000 Hi, On Fri, Nov 13, 2015 at 01:58:04PM +0000, Hemant Singh (shemant) wrote: > >One wouldnt care about DAD on loopback interface, because it's not noise on a wire, and it's not time consuming. > > So how will you deal with a duplicate IPv6 address configured on a > loopback interface? We don't care. Loopbacks imply a routing table entry somewhere to make the packets actually reach this host - and this should ensure it's reaching only the intended host (or you have dns-root style anycasting) > As I said in my example, a router is using the IPv6 address on a loopback interface to source packets and a duplicate is detected - the network breaks down. The upstream router should reject packets coming from a downstream which is not permitted to use an IPv6 address. Otherwise, there is no way to ensure uniqueness on non-directly-connected interfaces - think "loopback on a router on the other side of the planet". 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 Nov 13 06:32: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 ABE631A8961 for ; Fri, 13 Nov 2015 06:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uEeVexykalgY for ; Fri, 13 Nov 2015 06:32:31 -0800 (PST) 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 E38971A895C for ; Fri, 13 Nov 2015 06:32:30 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tADEWJFR021015; Fri, 13 Nov 2015 14:32:19 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk tADEWJFR021015 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1447425139; bh=G7uBp1juz7JP13JlPcDilSr4L/Y=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=CisOMiiRc97smsHy/jKlLOZv9n3xizhntbUAeb6GkD07pa0uAxu0LKJdjQ6c8j5e+ OTHUEDieVmkFam0lrv40VROiWywk1thAI4p6VVfNuGXD5G/225KIWUh3ZOQy3c2vOD bbfSZVXjArFIK7rt33kr3MLjvRiUutepAWq9Udfk= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id rACEWJ20589352719W ret-id none; Fri, 13 Nov 2015 14:32:19 +0000 Received: from [IPv6:2001:630:d0:ed23:2039:28ea:7b19:56ae] ([IPv6:2001:630:d0:ed23:2039:28ea:7b19:56ae]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tADEWG46012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 14:32:16 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Tim Chown In-Reply-To: <564525C2.2080508@gmail.com> Date: Fri, 13 Nov 2015 14:32:18 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> <8AC68BA1-0BE4-484B-A3A6-396112859B6F@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.3096.5) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=rACEWJ205893527100; tid=rACEWJ20589352719W; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: tADEWJFR021015 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 14:32:36 -0000 > On 12 Nov 2015, at 23:50, Brian E Carpenter = wrote: >=20 > Thanks for that reference. My estimate of 10M was based on some = hand-waving > arguments about how many SMEs might seriously want to be multihomed; = IMHO > most of them will be perfectly happy with PA addressing because they = will > have anything that needs a stable address hosted anyway. Most SOHOs = just don't > care, and get renumbered without knowing it after power fails etc. = Homenet > takes this as a given, of course. Not sure that last point is strictly true=E2=80=A6 Tim= From nobody Fri Nov 13 06:47: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 B21161A8A4C for ; Fri, 13 Nov 2015 06:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8G90PDPsKwd9 for ; Fri, 13 Nov 2015 06:47:11 -0800 (PST) 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 6A3E31A8A0D for ; Fri, 13 Nov 2015 06:47:11 -0800 (PST) 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 tADEl4vE030587; Fri, 13 Nov 2015 14:47:04 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk tADEl4vE030587 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1447426025; bh=lboV6HFVZPy3ylTc8/44vGBMVpQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=gzBPVxETQbtyTmNoqaHmXQLKVn1i5JbDp5t6QOdp/dg+Ld/D6rK+Uuyr0EGE2zcAA FfvtEoFOjYSmKrP0gF1IGFnUN5Y/7rwQtcycA9LTqfJEK16g4NY8eMgcgP1Pxoqh/3 OPb6cnyXwiNANkLdYTfjk5Qa4ea+h21+B+krqvag= 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 rACEl42058936507gq ret-id none; Fri, 13 Nov 2015 14:47:05 +0000 Received: from [IPv6:2001:630:d0:ed23:2039:28ea:7b19:56ae] ([IPv6:2001:630:d0:ed23:2039:28ea:7b19:56ae]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tADEl0bo017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 14:47:01 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Tim Chown In-Reply-To: <19FF351D-1C3F-43B8-9F47-8E190A3843D2@employees.org> Date: Fri, 13 Nov 2015 14:47:02 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <20151113131819.GP89490@Space.Net> <19FF351D-1C3F-43B8-9F47-8E190A3843D2@employees.org> <1D7BC20F-C83C-489B-9429-B2B9C5283565@ecs.soton.ac.uk> To: otroan@employees.org X-Mailer: Apple Mail (2.3096.5) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=rACEl4205893650700; tid=rACEl42058936507gq; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: tADEl4vE030587 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 14:47:12 -0000 > On 13 Nov 2015, at 13:23, otroan@employees.org wrote: >=20 > Gert, >=20 >>>> Networks break further upstream, without the actual upstream being >>>> noticeable >>>> broken. Networks break certain paths, while others are working = fine. >>>>=20 >>>> We can do better than all-or-nothing. We should. >>>=20 >>> I don't think a host should try to figure out which paths work and = which >>> don't. >>=20 >> I disagree, and strongly so. Maybe not "probe all paths at the same = time", >> but if one is not working, it would be silly not to try alternatives = if >> they exist. >>=20 >> [..] >>> I propose that routers just inform hosts which source prefixes are = unusable >>> according to unspecified monitoring code running on the router. = (Obviously, >>> routers should also propate that knowledge over internal routing = protocols in >>> setups with multiple routers). >>=20 >> So, if you have upstreams A and B, and targets C and D, of which "C" = cannot >> be reached over "A" and "D" not via "B" (not all that unlikely given = the >> direction in which low-price SoHo ISPs and peering wars are = developing), >> would you rather declare both broken, or just use B to reach C, and A = to >> reach D? >>=20 >> Defining "the upstream is broken" is actually fairly hard - the = router might >> be perfectly happy about upstream A, because 99% of its monitoring = targets >> work perfectly well - but if the user's 1% that he wants to talk to = do not >> work (routing hickup, anycast cluster broken, peering overloaded), it = is >> the wrong conclusion to declare "it is working, no need to try = anything >> else"... >=20 > exactly. the end-points has much more information about the end to end = path than the first-hop router has. > unless you want it to be a DPI/layer violating/state-hogging middle = box. Which is a very important point, and a big argument for src+dst based = host decisions. And we=E2=80=99ve already seen some early demonstrators = in home net / hackathons in recent IETFs. Tim > even having every router participate in global routing wouldn't help = you very much. global routing has convergence times measured in many = minutes. >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 13 07:34: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 EBB711ACE2A for ; Fri, 13 Nov 2015 07:34:13 -0800 (PST) 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 iRtaALxeNuio for ; Fri, 13 Nov 2015 07:34:12 -0800 (PST) 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 9E5D21ACE29 for ; Fri, 13 Nov 2015 07:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1448; q=dns/txt; s=iport; t=1447428853; x=1448638453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KL+OAwT+IvdZTpy5qM6HjYO9PFvHrnrdHt2Jo4BwEW8=; b=MJuF7Amc2yRUxC8MfztV5GxLGxi5jm2ENUPDVfIJ+oXvGninR/zrsUX9 6G1Hib5XE2PJQNBO20frcyIZqasGdNGbbPpxvjffUoTco6vX9MuGBbIpS Re4cNeZ5CLNryD30jVDq3fPouE3lm/4igZeTx7Jv7fvhW1OOGFEkfhjf/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlAgALAkZW/40NJK1egzuBQga+QQENgWWGEAKBOzgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQOBQiIJsEiAQEBAQEBAQEBAQEBAQEBAQEBAQEBGItSiTkFlkgBjR+BYpZ4g3EBHwEBQoQEcoQ2gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,287,1444694400"; d="scan'208";a="207872381" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 13 Nov 2015 15:34:12 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tADFYBjM024591 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 15:34:11 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 10:34:11 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 10:34:11 -0500 From: "Hemant Singh (shemant)" To: Gert Doering Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAFduAP//wTpA Date: Fri, 13 Nov 2015 15:34:11 +0000 Message-ID: References: <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <20151113140830.GT89490@Space.Net> In-Reply-To: <20151113140830.GT89490@Space.Net> 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.77.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 15:34:14 -0000 -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Friday, November 13, 2015 9:09 AM To: Hemant Singh (shemant) Cc: Alexandre Petrescu; v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] >The upstream router should reject packets coming from a downstream which i= s not permitted to use an IPv6 address. Based on what? ACL or DAD detection on the upstream router? For certain ro= uting cases, your point is reasonable. However, two routers may have their= interfaces in the same routed domain in which case the interface responds = to ND address resolution messages. Anytime an interface responds to ND add= ress resolution messages, the interface performs DAD for its IPv6 address(e= s).=20 RFC4862 also supports DupAddrDetectTransmits to be zero for certain links. = Why not use this variable to disable DAD for interfaces on certain links. >Otherwise, there is no way to ensure uniqueness on non-directly-connected = interfaces - think "loopback on a router on the other side of the planet". The router on the other side of the planet has a tunnel to the upstream rou= ter and thus the two routers are in the same routed domain. In the same ro= uted domain, an interface on a router responds to ND NS messages for addres= s resolution. Thus the interface has to also perform DAD for its IPv6 addr= ess(es). Hemant From nobody Fri Nov 13 07:43: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 A9F1A1ACE66 for ; Fri, 13 Nov 2015 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, 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 4ZA7zh_7oEtd for ; Fri, 13 Nov 2015 07:43:22 -0800 (PST) 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 D8C5A1ACE5C for ; Fri, 13 Nov 2015 07:43:21 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D032162D3E for ; Fri, 13 Nov 2015 16:43:19 +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 9BAF360788 for ; Fri, 13 Nov 2015 16:43:19 +0100 (CET) Received: (qmail 6184 invoked by uid 1007); 13 Nov 2015 16:43:19 +0100 Date: Fri, 13 Nov 2015 16:43:19 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20151113154319.GX89490@Space.Net> References: <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <20151113140830.GT89490@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IWOW6f13lWWiH/hK" 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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 15:43:23 -0000 --IWOW6f13lWWiH/hK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 13, 2015 at 03:34:11PM +0000, Hemant Singh (shemant) wrote: > >Otherwise, there is no way to ensure uniqueness on non-directly-connecte= d interfaces - think "loopback on a router on the other side of the planet". >=20 > The router on the other side of the planet has a tunnel to the upstream r= outer and thus the two routers are in the same routed domain. In the same = routed domain, an interface on a router responds to ND NS messages for addr= ess resolution. Thus the interface has to also perform DAD for its IPv6 ad= dress(es). Well, if you take an address that belongs to a connected /64 and glue that to your loopback interface, what you say is true - there will be ND NS queries for that address, and you better should do DAD. In the normal case for loopback interfaces, these intentionally are *not* numbered out of connected networks, but coming out of separately assigned number space (like, DHCPv6PD, or manually configured). Why would anyone send a ND NS for such an address in the first place? Nobody knows that it "could be on a link here". And no, the router on the other side of the planet has no "tunnel" to=20 your routing domain. It's just a router having a loopack address,=20 chosen to show that your concerns about loopback address DAD are a bit unrealistic. 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 --IWOW6f13lWWiH/hK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkYFF99WwGXkzn/FAQIPFBAAnfKshfICpA0R+gY6+GHX1p+IlVqEYPh7 F40eXRjCRa0jZes4a6YR+HSAlNTuEMoGGylSKknAofKxSzLdKUjI3owSoWM0f5ZZ +/efW/vml0ywAJOB6pK4iaeHy6nU+t67tC2MY2Yddu8ogbKwsepnR8yJN+VElQef zSH3Pwq78ETdL4g0Lkvwu2mzxiZ2Zasa5cztvrPyXBBB/2UGoPPeculljbshSYLr 3ddL/6llLIgx0C5Du8vVjCGyM37duKGchuaRPzCu9N6NAlPuh6xWATai7AXUpL8Y iAmAJTNGIp7NjpS04JJeTvw4EEL5Q9X3Dv48kRDh0F7eyTtzhYsUUQNvtKhac24q FS3Gk5uTxYH+nLGJDoI+LvPhDEnLycNCBzYd1OW/bhcMh41rX1nPxvEoh2F2aOyC 3roZaW5kfufi0W7eQK1sNvSI/QBQixlz4w+TstGkgpF4Qc7Pm7AbTXS3Ze3CKATP JnE5bQLHddNS+4H5QR6W/ydIKAakAooPPBOwjs8E7/Oj6y67N8P9G3Xlm1hNVLZp DyVITIgQhMnLWgnBmouTibRijfHY3HiI4ctQzUTz3riy6YIIcxBIQHnkVSIj76Bh 0DYNmNXgRYKbS86hZ3jSmXbvxCvldTbRotI9ugn0zb4xXQbVrusI9kc3nABcyrg8 QrOcxEDOOwk= =hNej -----END PGP SIGNATURE----- --IWOW6f13lWWiH/hK-- From nobody Fri Nov 13 07:53: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 8612B1ACEEA for ; Fri, 13 Nov 2015 07:53:17 -0800 (PST) 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 pQtEoga6L0Gq for ; Fri, 13 Nov 2015 07:53:16 -0800 (PST) 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 0B2041ACED5 for ; Fri, 13 Nov 2015 07:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1447429996; x=1448639596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ixCRTVurE+LYtul+mDYtfjFU5LZFTdHkqjxGpYxTH/Y=; b=AH6UY6xscC6sUSGaOvqGlue2aGcxitsDe27xVNkDMjqHo5gqw5PkP3lG rPM2spyDR4YhoSVsR1bsBzD9xtW1tD9MZOk7A5Z/dwg6XbtyV2ETNklBx XkfGRNEpVWRdlDgZq1ommzRTh5tL/fbMENFF3nRC9a/gia9m0PQZBD/F7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnAgAuB0ZW/49dJa1dgztTb75HAQ2BZRcKhW8CHIEfOBQBAQEBAQEBgQqENAEBAQMBAQEBIBE6CwULAgEIDgoCAiYCAgIlCxUQAgQOBYgmCA2wK5BWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYVTghCCboQqEQEdGIMEL4EVBZZIAY0mnEQBHwEBQoQEcoN8gUEBAQE X-IronPort-AV: E=Sophos;i="5.20,288,1444694400"; d="scan'208";a="208244442" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2015 15:53:02 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tADFr2KE014837 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 15:53:02 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 09:53:01 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 09:53:01 -0600 From: "Pascal Thubert (pthubert)" To: Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRHhHNtcDH7FteNky3GAi2sZ2oFZ6aVoEAgAAFfoCAAADlgIAAEE0A Date: Fri, 13 Nov 2015 15:53:01 +0000 Message-ID: <06405D43-82A6-4B85-BD98-567CD2E073BB@cisco.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <840504075E3B2240A41F886761F66EC1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 15:53:17 -0000 QW5vdGhlciB1c2FnZSBmb3Igb3V0IEdQVT8NCg0KUGFzY2FsDQoNCj4gTGUgMTMgbm92LiAyMDE1 IMOgIDE0OjUwLCBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+IGEgw6ljcml0 IDoNCj4gDQo+PiBPbiBGcmksIDEzIE5vdiAyMDE1LCBOaWNrIEhpbGxpYXJkIHdyb3RlOg0KPj4g DQo+PiBPbiAxMy8xMS8yMDE1IDEzOjI3LCBNaWNoYWVsIEggTGFtYmVydCB3cm90ZToNCj4+Pj4g T24gMTMgTm92IDIwMTUsIGF0IDA3OjQ5LCBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20u cHAuc2U+IHdyb3RlOg0KPj4+PiBBbHNvLCB3aHkgc2hvdWxkIGEgY29yZSByb3V0ZXIgaW4gRXVy b3BlIGhhdmUgdG8gY2FyZSBhYm91dCBhbiBvZmZpY2UgY29ubmVjdGlvbiBiZWluZyBhZmZlY3Rl ZCBieSBzb21ldGhpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIGdsb2JlPw0KPj4+IA0KPj4+ IEluZGVlZC4gIFVubGVzcyBvbmUgaXMgaW50ZW50aW9uYWxseSB0cnlpbmcgdG8gZGVzaWduIGEg Y2hhb3RpYyBzeXN0ZW0uDQo+PiANCj4+IFRoZSB0eXBlIG9mIGNoYW9zIHdoaWNoIHdoaWNoIGlu dm9sdmVzIG1vc3QgQVNOcyBoYXZpbmcgYSBmdWxsIHZpZXcgb2YgdGhlDQo+PiBJbnRlcm5ldCBp cyBsZXNzIGJhZCB0aGFuIHRoZSB0eXBlIHdoZXJlIG9ubHkgYSBoYW5kZnVsIG9mIHRoZW0gZG8u DQo+IA0KPiBJZiB0aGUgSW50ZXJuZXQgd2lsbCBoYXZlIDEweCB0aGUgbnVtYmVyIG9mIHJvdXRl cyBpdCBoYXMgdG9kYXkgaW4gdGhlIG5vdC1zby1kaXN0YW50LWZ1dHVyZSwgdGhlcmUgaXMgYSBj b25zaWRlcmFibGUgcmlzayB0aGF0IG1vc3Qgc21hbGxlciBwbGF5ZXJzIHdvbid0IGJlIGFibGUg dG8gYWZmb3JkIHRvIGhhdmUgYSBmdWxsIHZpZXcuDQo+IA0KPiBJIGFscmVhZHkga25vdyBwZW9w bGUgdG9kYXkgd2hvIGRvIHJvdXRlIGZpbHRlcmluZyBiZWNhdXNlIHRoZWlyIGRldmljZXMgbWln aHQgb25seSBoYXZlIDI1NmsgVENBTSBzbG90cy4NCj4gDQo+IC0tIA0KPiBNaWthZWwgQWJyYWhh bXNzb24gICAgZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2 Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo= From nobody Fri Nov 13 09:34: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 BE1801B2E2B for ; Fri, 13 Nov 2015 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, 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 SuL5ClHWZtLV for ; Fri, 13 Nov 2015 09:34:36 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C56D51B2E24 for ; Fri, 13 Nov 2015 09:34:33 -0800 (PST) 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 tADHVPmc023091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 09:31:26 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_926F368E-6C7B-4F37-BB41-DA81A41EEF78" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Fri, 13 Nov 2015 09:31:24 -0800 Message-Id: <7F92C0D6-A6A6-4226-A479-849BF4F07A8A@delong.com> References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <564537A7! .90102@si6networks.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 17:34:37 -0000 --Apple-Mail=_926F368E-6C7B-4F37-BB41-DA81A41EEF78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 13, 2015, at 03:16 , Eric Vyncke (evyncke) = wrote: >=20 >>=20 >> Absolutely. There are firewalls that only allow through pink packets = on Tuesdays. But checking the sequence number won't help with UDP. >=20 >=20 > And yellow packets on Fridays. And, the absence of 'states' in UDP = packet is one reason why some edge security policy block UDP=20 And yet DNS almost always works and you can already find open source = software that implements a full dual-stack tunnel capability in the form = of DNS request/response packets. Run that on a public DNS server somewhere, register it as authoritative = for some random zone and the firewall is out the window. If you allow outbound connections and someone on the inside wants to = allow inbound connections, they can, whether you like it or not. Owen --Apple-Mail=_926F368E-6C7B-4F37-BB41-DA81A41EEF78 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    On Nov 13, 2015, at 03:16 , Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:


    Absolutely. There are firewalls that only allow through pink packets on Tuesdays. But checking the sequence number won't help with UDP.

    And yellow packets on Fridays. And, the absence of 'states' in UDP packet is one reason why some edge security policy block UDP 

    And yet DNS almost always works and you can already find open source software that implements a full dual-stack tunnel capability in the form of DNS request/response packets.

    Run that on a public DNS server somewhere, register it as authoritative for some random zone and the firewall is out the window.

    If you allow outbound connections and someone on the inside wants to allow inbound connections, they can, whether you like it or not.

    Owen

    --Apple-Mail=_926F368E-6C7B-4F37-BB41-DA81A41EEF78-- From nobody Fri Nov 13 09:40: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 2EA411B2F13 for ; Fri, 13 Nov 2015 09:40:41 -0800 (PST) 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 sbKAV21LKxhJ for ; Fri, 13 Nov 2015 09:40:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C910C1B2F12 for ; Fri, 13 Nov 2015 09:40:39 -0800 (PST) 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 tADHdZNh024159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 09:39:36 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Fri, 13 Nov 2015 09:39:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 17:40:41 -0000 > I'm sure we can design routers that can handle 10x the prefixes they = can today, but at what cost? >=20 > Also, why should a core router in Europe have to care about an office = connection being affected by something on the other side of the globe? = IP has become successful because the core doesn't have to keep state for = L4 connections, but if we radically increase the state needed to be kept = for L3 destinations, we will most likely run into problems. Yes, they = might be solved, but currently we do not know how. >=20 > So I would very much like to stay away from an architecture that = suggests "PI for everybody". The alternative perspective is that because we=E2=80=99ve been able to = avoid this issue by treating most of the internet users as second-class = citizens, we have chosen not to put resources into solving it. Perhaps it is time to stop treating internet users as second-class = citizens and actually put resources into solving this problem in a = meaningful way. It is truly unfortunate that the IETF deliberately punted on this issue = during the development of IPv6. I believe this decision was driven by a = number of the larger ISPs of the day (carriers) pushing to maintain CIDR = as a mechanism of customer lock-in and exacerbated by sheer laziness = from others. I believe that an extra 32-bit field in the IPv6 header could have = provided a significant step towards solving this problem by encoding the = destination transit AS in the packet at the first router capable of = resolving that information and then routing on that basis in the IDR = realm. In that case, stub networks (non-transit autonomous systems) = would not need to be visible in BGP and we would not need to track = prefix state beyond the closest transit ASNs. A separate map of = Prefix->Candidate Transit ASNs could be maintained through a mechanism = somewhat similar to DNS. Unfortunately, we don=E2=80=99t have the bits to do this in the IPv6 = header and the solution will now be harder. Owen From nobody Fri Nov 13 09:46: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 B1C1F1B4035 for ; Fri, 13 Nov 2015 09:46:09 -0800 (PST) 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 HW0lDQGWUb12 for ; Fri, 13 Nov 2015 09:46:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1C1B4034 for ; Fri, 13 Nov 2015 09:46:08 -0800 (PST) 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 tADHh395024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 09:43:04 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> Date: Fri, 13 Nov 2015 09:43:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 17:46:09 -0000 > On Nov 13, 2015, at 05:58 , Hemant Singh (shemant) = wrote: >=20 >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre = Petrescu > Sent: Friday, November 13, 2015 7:57 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >=20 >> One wouldnt care about DAD on loopback interface, because it's not = noise on a wire, and it's not time consuming. >=20 > So how will you deal with a duplicate IPv6 address configured on a = loopback interface? As I said in my example, a router is using the IPv6 = address on a loopback interface to source packets and a duplicate is = detected - the network breaks down. >=20 How is it possible to have a duplicate address on a loopback interface? If you assign an address to a loopback interface, the address is present = on the interface. If you attempt to assign it there again, it should be = a no-op. To the best of my knowledge, it is impossible to assign the same address = to the same interface twice. The duplicate address case applies when two systems on the same link = have the same address. Since there is never more than one system on a = loopback link by definition, it seems to me that the scenario you = propose is impossible by definition. Owen From nobody Fri Nov 13 10:20: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 293B51B29EF for ; Fri, 13 Nov 2015 10:20:06 -0800 (PST) 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 Gm55mer0lyr6 for ; Fri, 13 Nov 2015 10:20:03 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 5C8701B29F4 for ; Fri, 13 Nov 2015 10:20:03 -0800 (PST) Received: by pabfh17 with SMTP id fh17so107256680pab.0 for ; Fri, 13 Nov 2015 10:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized_org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=FuW5kfTegs8VTS3XjnImB1TCcIFvROVp3qZQtdAE+XM=; b=K1bpvMOcCyrdcBTfTTQ3Nt2MkaVFiQFNaMEmLMBOP4OC2yj9EQNx7Sk5itHQ84BqD9 mFtU7XtNtiXRwILvHrjYWUd8y5nRacC3Wo8ZKu/UItVoIfgSUpwbZds0dZmI3pluSeD9 vyTsATch+3YQTJmO9R3dbTkiLlJUCka9I2WpAvrSgcvW/Y/PwYNxkw/N4D5YMdjeZ95X llW2aKBLmemlZDAotrUQgTITBfjAaUEVh8xGGGr0YN3W/fvqcVD9HFbOBTCELAwsMQV8 0UKjHp2euvqmNPHxk7RhQi485brZTMmG+cTajJV70lPSicaK9vKKq6xuy3ozroX/f57v JAqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FuW5kfTegs8VTS3XjnImB1TCcIFvROVp3qZQtdAE+XM=; b=LsZxa1TCJfLjX2mO8fBGwEc37N852lS5Jm7+/rg3UuoY2HD4JKY0GVvDn4NAlVV5C3 rb4azNE2g/IiE5QSV7gDRJ191TwJaqxu6gPHIaXbjyHdqi9Ndluki9MiEow9u4paJkk3 K44piXgRmGu4pDdA9Max9Ley08ehVkq31KUpKVu69yxPhhmw34iDDwBK5OgWMtIKn3sr 5lQzShkLdXhPr884BGasZnBXxtyBUrgQzd+zAXXBZEZ/4T7bniGgVMfvjzfz6edxvhQD YiXaXpLulqcPLhHLVd6sydA/0/KlAy+gbVjpy3gaxcYBHc4ybpeMq6v3xd1xC/38Dq97 Hc6g== X-Gm-Message-State: ALoCoQmuac/NrBW64U+WbTrwZMkohvug0x8KPCvdDAUIi948MT/m0ukCK/QT5AOBmTLfogupxHHS X-Received: by 10.68.242.105 with SMTP id wp9mr34182024pbc.49.1447438802976; Fri, 13 Nov 2015 10:20:02 -0800 (PST) Received: from ?IPv6:2601:647:4300:6ed2:4447:a010:e116:9884? ([2601:647:4300:6ed2:4447:a010:e116:9884]) by smtp.gmail.com with ESMTPSA id an5sm21676478pbd.45.2015.11.13.10.20.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Nov 2015 10:20:01 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C71595B9-CE27-4F76-A4A4-BF43552947C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: David Conrad In-Reply-To: Date: Fri, 13 Nov 2015 10:20:02 -0800 Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 18:20:06 -0000 --Apple-Mail=_C71595B9-CE27-4F76-A4A4-BF43552947C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I doubt that all but a small fraction of those SMEs actually need = multihoming. Really? This strikes me as IPv4-think. Given the migration to the cloud, = the availability of multiple layer 2 infrastructures (particularly in = the wireless space) which will likely drive down costs, and the = increasing dependence upon "the cloud" for everything from traditional = Internet services to the "Internet of Things" (whatever that means), I = would think the future will be rife with multihoming for = reliability/resiliency reasons, and not just by Es (SM or otherwise), = but by residentials as well. > But even for those that do - we should be working on making it = possible to multihome using src+dst routing, not NPT66 or NAT66. Since renumbering remains "hard" (for some value of that variable), I = personally think the largest driver for NPT66/NAT66 is people not = wanting to be locked into an ISP and not wanting to bother with the RIR = nonsense and cos, not multihoming (currently)t. When the cost of = getting a PI prefix is significantly higher than what you pay for = Internet connectivity, PA+NAT is a natural outcome for IPv6, just as it = was for IPv4. Regards, -drc --Apple-Mail=_C71595B9-CE27-4F76-A4A4-BF43552947C2 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 iQEcBAEBCgAGBQJWRinSAAoJENV6ebf0/4rXH/MIAN5TXbN2Rl8sYP/ErX9y2H0r F0u7dVqxuPne7kDPi956KLJRuSam/p1MJ3M07B8SfZKB4wmhfOtR76nQxT8/xC6m kRUYr58m2qc+0Y32ylquphvs047aqDeyEZ/71e4faotzHyuxRsps+DDFOzQ1t5Pu 6pZTfCoSL2mUkoN3IFALrshz28bRXi/zRmsRNE01IELWSp30fA+2aJ47Cc6Pajpa C8mAJmigxSdciemezeTkY5P0mgrlHFWs/0q/qS5ePq7KhrnENu17BLTAYdPn3ugx YD6JKLfcU19zxvFI3fr1owgO9GsMvC5kCFVfiC2D9zOjHom25KZdQl2U7en5klA= =08jr -----END PGP SIGNATURE----- --Apple-Mail=_C71595B9-CE27-4F76-A4A4-BF43552947C2-- From nobody Fri Nov 13 10:41: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 A0B111B2B1F for ; Fri, 13 Nov 2015 10:41:56 -0800 (PST) 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 i2gRuKPhJYuU for ; Fri, 13 Nov 2015 10:41:54 -0800 (PST) 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 E49D21B2B18 for ; Fri, 13 Nov 2015 10:41:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5EF3862EFF for ; Fri, 13 Nov 2015 19:41:51 +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 245FC60788 for ; Fri, 13 Nov 2015 19:41:51 +0100 (CET) Received: (qmail 15218 invoked by uid 1007); 13 Nov 2015 19:41:51 +0100 Date: Fri, 13 Nov 2015 19:41:51 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151113184151.GD89490@Space.Net> References: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 18:41:56 -0000 Hi, On Fri, Nov 13, 2015 at 09:39:35AM -0800, Owen DeLong wrote: > I believe that an extra 32-bit field in the IPv6 header could have provided a significant step towards solving this problem by encoding the destination transit AS in the packet at the first router capable of resolving that information and then routing on that basis in the IDR realm. In that case, stub networks (non-transit autonomous systems) would not need to be visible in BGP and we would not need to track prefix state beyond the closest transit ASNs. A separate map of Prefix->Candidate Transit ASNs could be maintained through a mechanism somewhat similar to DNS. So you're in the LISP "we noticed that route caches do not scale, but we try again and again" camp now? 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 Nov 13 10:55: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 8181D1B2F9F for ; Fri, 13 Nov 2015 10:55:35 -0800 (PST) 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 0ZG6qgDo619Z for ; Fri, 13 Nov 2015 10:55:34 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 648F21B2B79 for ; Fri, 13 Nov 2015 10:55:33 -0800 (PST) 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 tADIsVh2002418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 10:54:32 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151113184151.GD89490@Space.Net> Date: Fri, 13 Nov 2015 10:54:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8B6940FB-C0B0-47C3-8780-9B7412F0D583@delong.com> References: <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> <20151113184151.GD89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 18:55:35 -0000 > On Nov 13, 2015, at 10:41 , Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Nov 13, 2015 at 09:39:35AM -0800, Owen DeLong wrote: >> I believe that an extra 32-bit field in the IPv6 header could have = provided a significant step towards solving this problem by encoding the = destination transit AS in the packet at the first router capable of = resolving that information and then routing on that basis in the IDR = realm. In that case, stub networks (non-transit autonomous systems) = would not need to be visible in BGP and we would not need to track = prefix state beyond the closest transit ASNs. A separate map of = Prefix->Candidate Transit ASNs could be maintained through a mechanism = somewhat similar to DNS. >=20 > So you're in the LISP "we noticed that route caches do not scale, but = we > try again and again" camp now? >=20 Who said anything about a route cache? Owen From nobody Fri Nov 13 10:58: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 9F9931B2FC1 for ; Fri, 13 Nov 2015 10:58:30 -0800 (PST) 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 eErIeCVGjOHp for ; Fri, 13 Nov 2015 10:58:29 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 68D641B2FC3 for ; Fri, 13 Nov 2015 10:58:29 -0800 (PST) Received: by pabfh17 with SMTP id fh17so108164232pab.0 for ; Fri, 13 Nov 2015 10:58:29 -0800 (PST) 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=kdazx/3WNk3M/VkmPH955wJiH2CPL5WqkOp9U6EG8uw=; b=F9o7sLvKAmxYsF/GGoP4t/cPN+I8B1mmFNUTWL7++zbgk6nqoDjK6BP+AK+DSyG1+P DS0lPWxrlA+zJrorAUKHH+8rzQ+x4duPtdcRcYLRykbdtgzoc71C/RlFaevCtHMsQ2VI QEA9j7oIDe+IJ81mELvpH0Hu1KZOFxzFnl4A/mEP75197wKzocVEjNaqQ4j+3gHPQoYk MrzN1j4k0ZF/YHUXGUS4RRcfqmkW5r2fyhqIm/o30+2arNBsPEFrUmhjfXv/higxINCD dxuxnVTZ/A4RulX5qTQBNomW9ZIiiLkcqNc+OmdaFg5l0fXyIa8nKtyaYwW/bLnociOJ 8Rqw== X-Received: by 10.68.234.166 with SMTP id uf6mr34329418pbc.126.1447441109110; Fri, 13 Nov 2015 10:58:29 -0800 (PST) Received: from ?IPv6:2406:e007:7309:1:28cc:dc4c:9703:6781? ([2406:e007:7309:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ia3sm21810398pbb.5.2015.11.13.10.58.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 10:58:27 -0800 (PST) To: Tim Chown References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <564525C2.2080508@gmail.com> <8AC68BA1-0BE4-484B-A3A6-396112859B6F@ecs.soton.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <564632DC.4020400@gmail.com> Date: Sat, 14 Nov 2015 07:58: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy 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, 13 Nov 2015 18:58:30 -0000 On 14/11/2015 03:32, Tim Chown wrote: >> On 12 Nov 2015, at 23:50, Brian E Carpenter wrote: >> >> Thanks for that reference. My estimate of 10M was based on some hand-w= aving >> arguments about how many SMEs might seriously want to be multihomed; I= MHO >> most of them will be perfectly happy with PA addressing because they w= ill >> have anything that needs a stable address hosted anyway. Most SOHOs ju= st don't >> care, and get renumbered without knowing it after power fails etc. Hom= enet >> takes this as a given, of course. >=20 > Not sure that last point is strictly true=E2=80=A6 Well, it seems implicit in HNCP to me. Brian From nobody Fri Nov 13 11:01: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 871851B2FFB for ; Fri, 13 Nov 2015 11:01:57 -0800 (PST) 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 Ox4p9N1NuRTz for ; Fri, 13 Nov 2015 11:01:56 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 DF4621B2FFA for ; Fri, 13 Nov 2015 11:01:55 -0800 (PST) Received: by pacej9 with SMTP id ej9so1348581pac.2 for ; Fri, 13 Nov 2015 11:01:55 -0800 (PST) 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=I70k5IVWAdPMJemUK5gASItx+mr9oqIIEISwTBRCL3Q=; b=SAfZ3J/ZybWqjWHbiEZrRw95JMDbz/IBtZq4DtqmWKvHualCHC4RtzxkufcOwTR2GG uSYgu3dGWFmaMWKAxvfhpPSzETDk7AcRJRRaBSdtH3WtsO2H2PbEs9kFpFuK2Mr0hYT3 fIlDfVYNr4jheFS4Bt1G4RKPTgDMDUaVZYcYBgua6lyrufXolfIeTLGHLrkUZemIWH0h GDENpz/k2wteKIzJfCGHaWRP7dVOOuDvHKQpsNwAx5XH8upjNEoxo/wI40qqVJlDd3Wy Lt/3lHsU8r7ZPZ/vDL1RK2bezUiNKv9RoJVsGvN+D7DxnsMpe0zeUKn7xilQtGwNC7Xj dEFQ== X-Received: by 10.66.150.5 with SMTP id ue5mr19990044pab.42.1447441315596; Fri, 13 Nov 2015 11:01:55 -0800 (PST) Received: from ?IPv6:2406:e007:7309:1:28cc:dc4c:9703:6781? ([2406:e007:7309:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rv8sm4274165pbc.84.2015.11.13.11.01.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 11:01:54 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <564633AB.9000509@gmail.com> Date: Sat, 14 Nov 2015 08:02:03 +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] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 19:01:57 -0000 On 14/11/2015 01:49, Philip Homburg wrote: >> Networks break further upstream, without the actual upstream being >> noticeable >> broken. Networks break certain paths, while others are working fine. >> >> We can do better than all-or-nothing. We should. > > I don't think a host should try to figure out which paths work and which > don't. > > Maybe somebody can come up with a simple algorithm that generalises > happy-eyeballs and that is compatible with today's host operating systems. > But I doubt it. We tried. It's called shim6. Firewalls break it. Brian > > So while we wait for hosts to magically figure out what works and what doesn't > (and for mobile hosts, in any possible context, even when there is > high packet loss on the local link, etc), > > I propose that routers just inform hosts which source prefixes are unusable > according to unspecified monitoring code running on the router. (Obviously, > routers should also propate that knowledge over internal routing protocols in > setups with multiple routers). > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Fri Nov 13 11:19: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 8AED51B422E for ; Fri, 13 Nov 2015 11:19:24 -0800 (PST) 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 7Y_ow2UtcV4E for ; Fri, 13 Nov 2015 11:19:22 -0800 (PST) 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 389C01B422A for ; Fri, 13 Nov 2015 11:19:22 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZxJsW-0000GnC; Fri, 13 Nov 2015 20:19:20 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> In-reply-to: Your message of "Sat, 14 Nov 2015 08:02:03 +1300 ." <564633AB.9000509@gmail.com> Date: Fri, 13 Nov 2015 20:19:19 +0100 Archived-At: Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 19:19:24 -0000 >> I don't think a host should try to figure out which paths work and which >> don't. >> >> Maybe somebody can come up with a simple algorithm that generalises >> happy-eyeballs and that is compatible with today's host operating systems. >> But I doubt it. > >We tried. It's called shim6. Firewalls break it. I'd call shim6 a protocol and not an algorithm. Happy eyeballs is quite compatible with firewalls, NAT, etc. No problem there. I'm sure happy eyeballs-like approaches can be tried for the multiple-prefix case. The problem I ran into is that by the time my happy eyeballs implementation did everything I wanted it do, it was way to complex. Adding support for many source prefixes would just be too much. Now, maybe somebody can come up with an approach that doesn't have that problem. Don't know. Mean while, I have something that works with every operating system today. It may not be perfect. So I'm not terribly motivated to add more host complexity to solve those edge cases. From nobody Fri Nov 13 11:21: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 A35861B4232 for ; Fri, 13 Nov 2015 11:21:49 -0800 (PST) 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 5g6Ar5zWS8Om for ; Fri, 13 Nov 2015 11:21:47 -0800 (PST) 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 965DB1B422C for ; Fri, 13 Nov 2015 11:21:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6CD6B62EFF for ; Fri, 13 Nov 2015 20:21:42 +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 0DE2760A87 for ; Fri, 13 Nov 2015 20:21:42 +0100 (CET) Received: (qmail 16637 invoked by uid 1007); 13 Nov 2015 20:21:41 +0100 Date: Fri, 13 Nov 2015 20:21:41 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151113192141.GE89490@Space.Net> References: <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> <20151113184151.GD89490@Space.Net> <8B6940FB-C0B0-47C3-8780-9B7412F0D583@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FgDZqiUnJxahzcFD" Content-Disposition: inline In-Reply-To: <8B6940FB-C0B0-47C3-8780-9B7412F0D583@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 19:21:49 -0000 --FgDZqiUnJxahzcFD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 13, 2015 at 10:54:31AM -0800, Owen DeLong wrote: > > On Nov 13, 2015, at 10:41 , Gert Doering wrote: > >=20 > > On Fri, Nov 13, 2015 at 09:39:35AM -0800, Owen DeLong wrote: > >> I believe that an extra 32-bit field in the IPv6 header could have pro= vided a significant step towards solving this problem by encoding the desti= nation transit AS in the packet at the first router capable of resolving th= at information and then routing on that basis in the IDR realm. In that cas= e, stub networks (non-transit autonomous systems) would not need to be visi= ble in BGP and we would not need to track prefix state beyond the closest t= ransit ASNs. A separate map of Prefix->Candidate Transit ASNs could be main= tained through a mechanism somewhat similar to DNS. > >=20 > > So you're in the LISP "we noticed that route caches do not scale, but we > > try again and again" camp now? >=20 > Who said anything about a route cache? So you want to do the map lookup every time a packet traverses one of these routers? Or should the Prefix->Candidate Transit ASNs map be distributed everywhere, like, with BGP, so all these routers get to hold 100M map entries all the time? 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 --FgDZqiUnJxahzcFD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkY4Rd9WwGXkzn/FAQJf8BAAiLPsKtPMjAonMRjR/rHwNI3xcavtBo0X GPbyMdbQEH0VNZ5d6pmKWD6peVl186/BE2o7fh7PiuT8jHEh+jRIM7jjBjtDjl5e Oq3tkR13kLQfrw5HxTA77/nHRZF1ok6QEvsqsZ8sc/QbawdmUzdIXb4x1QoytlMO LDaWvnnpFJUvN30zN97/Oiz+r1OVJvzT/niMAY+41quN7zAAJv62uuH7LVLeTpEA //GWwpfI9WW1yBGLD4L2axR31ZIvrhFLUpROjXHjNaU/9Gqw5zGJAvBDBmadu//O V7KM/3RG3Le4YQJiZbQpXqwVTyvWpBYgVmI2j9rPCmVRoND6itB11mcumn93ojau 558fLYyz6G2JRO01+nxUhDrx61sQjSXts+O9HlUXg8BXpKXeVh9azgms3Dy2fPRJ GTgc1C7b21S2oF4h2luqbtWuvZwG3u3otVl2vk6dI27OcBf4ObMbeNLv/NRBCGu0 y56db653q6EKg25jdkY2RgtUeC6rRmUrVf9oCDHLjNgcnkF3Fi915+JohU41I36Q /vw5hS2eFl0cxcvcnjXPB6ol5jwEahGhpUMg7oeUyvRjFEC5HZL0079/vS7boT8w iGaWDTad6B0Ea7gItGKBvwS19uNYyfc8oMBW3T9jC9OJszFensuL5lN1gVP1IEuS 0RdynhIvdn8= =nsot -----END PGP SIGNATURE----- --FgDZqiUnJxahzcFD-- From nobody Fri Nov 13 11: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 81FE91B4281 for ; Fri, 13 Nov 2015 11:36:27 -0800 (PST) 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 c94AHR1EzmzG for ; Fri, 13 Nov 2015 11:36:23 -0800 (PST) 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 405471B4282 for ; Fri, 13 Nov 2015 11:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=848; q=dns/txt; s=iport; t=1447443384; x=1448652984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TELnsHQUEpMjYlXX0ZkSJZO79AdbFcZ7NvxwMRSFhaA=; b=TcILVRtB1N5JygNUM8usN6T9KiRdKifPsd1REXzHPQTnXke8pb1DKm+3 ZDPu8k5EuttorMLPyVSWJm74s6+tn/LoLoO0PHZ9MtY+PssC7fY8WsZeZ McaVlWir5u+pV8gwbTYdcLRlVucxSOCWF+XZxTGAKU4h4F+itwUDaV6uL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlAgCMOkZW/4kNJK1egzuBQga+QQENgWWGEAKBPjgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQOBQiIJsA2AQEBAQEBAQEBAQEBAQEBAQEBAQEBGItSiTkBBJZIAY0fnEsBHwEBQoQEcoQ2gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="207340569" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 13 Nov 2015 19:36:23 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tADJaMZK013283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 19:36:22 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 14:36:21 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 14:36:21 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfw Date: Fri, 13 Nov 2015 19:36:21 +0000 Message-ID: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.77.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 19:36:27 -0000 -----Original Message----- From: Owen DeLong [mailto:owen@delong.com]=20 Sent: Friday, November 13, 2015 12:43 PM To: Hemant Singh (shemant) Cc: Alexandre Petrescu; v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] >How is it possible to have a duplicate address on a loopback interface? A router configures a loopback interface and provisions an IPv6 address on = the interface. The is a LAN in the router downstream port which the router= destines packets to using the source as the IPv6 address on the loopback. = The LAN segment may have a duplicate unless the loopback IPv6 address is d= isjoint from any IPv6 prefix on the router and router LAN/WAN segment. An= other use case is already mentioned in this thread - two routers directly c= onnected. Hemant=20 From nobody Fri Nov 13 11:42: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 B963A1B42B6 for ; Fri, 13 Nov 2015 11:41:58 -0800 (PST) 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 bGMsuV5qKSHL for ; Fri, 13 Nov 2015 11:41:57 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB4231B42B2 for ; Fri, 13 Nov 2015 11:41:54 -0800 (PST) X-SENDER-IP: 10.64.163.154 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,289,1444708800"; d="scan'208";a="883937063" Received: from unknown (HELO exchpapp13.corp.twcable.com) ([10.64.163.154]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 13 Nov 2015 14:33:36 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp13.corp.twcable.com (10.64.163.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 14:41:52 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 14:41:52 -0500 From: "Howard, Lee" To: Owen DeLong , Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? Thread-Index: AQHRFU89fgZyr/YcA06ueb9nvYwyhp6JxBoAgACOEYD//769AIAACpaAgAAHdwCAAItVAIACvqMAgACUfYD//4XHAIABSq0AgAAWYICAAAZ9gIAKK3YAgAAD0YCAAA3wAIAAAg2AgAALdYD//8O9igAPm/UAAABM5AAAGgW2AAAKInGA///OV4A= Date: Fri, 13 Nov 2015 19:41:52 +0000 Message-ID: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> In-Reply-To: <2B03B738-F348-4A69-B2F5-881820B615FB@delong.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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21938.005 x-tm-as-result: No--43.710100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0CC1310DB2D47C49B56A0D1FBB238CD6@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 19:41:58 -0000 I apologize for not continuing to ride herd on this thread since returning from the IETF meeting. Please, let us focus on this document in this thread. Other IPv6 operational issues should get a different subject line. Proposals for maintenance updates to the IPv6 protocol should go to 6man. Proposals for fundamental changes should go to the IESG or IAB. Lee On 11/13/15, 12:39 PM, "v6ops on behalf of Owen DeLong" wrote: >> I'm sure we can design routers that can handle 10x the prefixes they >>can today, but at what cost? >> >> Also, why should a core router in Europe have to care about an office >>connection being affected by something on the other side of the globe? >>IP has become successful because the core doesn't have to keep state for >>L4 connections, but if we radically increase the state needed to be kept >>for L3 destinations, we will most likely run into problems. Yes, they >>might be solved, but currently we do not know how. >> >> So I would very much like to stay away from an architecture that >>suggests "PI for everybody". > >The alternative perspective is that because we=B9ve been able to avoid thi= s >issue by treating most of the internet users as second-class citizens, we >have chosen not to put resources into solving it. > >Perhaps it is time to stop treating internet users as second-class >citizens and actually put resources into solving this problem in a >meaningful way. > >It is truly unfortunate that the IETF deliberately punted on this issue >during the development of IPv6. I believe this decision was driven by a >number of the larger ISPs of the day (carriers) pushing to maintain CIDR >as a mechanism of customer lock-in and exacerbated by sheer laziness from >others. > >I believe that an extra 32-bit field in the IPv6 header could have >provided a significant step towards solving this problem by encoding the >destination transit AS in the packet at the first router capable of >resolving that information and then routing on that basis in the IDR >realm. In that case, stub networks (non-transit autonomous systems) would >not need to be visible in BGP and we would not need to track prefix state >beyond the closest transit ASNs. A separate map of Prefix->Candidate >Transit ASNs could be maintained through a mechanism somewhat similar to >DNS. > >Unfortunately, we don=B9t have the bits to do this in the IPv6 header and >the solution will now be harder. > >Owen > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Fri Nov 13 12:41: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 E02681B30CF for ; Fri, 13 Nov 2015 12:40:59 -0800 (PST) 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 TqNgiT62OzWL for ; Fri, 13 Nov 2015 12:40:58 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5735A1B30CC for ; Fri, 13 Nov 2015 12:40:57 -0800 (PST) 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 tADKdu6g015013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 12:39:56 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151113192141.GE89490@Space.Net> Date: Fri, 13 Nov 2015 12:39:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> <20151113184151.GD89490@Space.Net> <8B6940FB-C0B0-47C3-8780-9B7412F0D583@delong.com> <20151113192141.GE89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 20:41:00 -0000 > On Nov 13, 2015, at 11:21 , Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Nov 13, 2015 at 10:54:31AM -0800, Owen DeLong wrote: >>> On Nov 13, 2015, at 10:41 , Gert Doering wrote: >>>=20 >>> On Fri, Nov 13, 2015 at 09:39:35AM -0800, Owen DeLong wrote: >>>> I believe that an extra 32-bit field in the IPv6 header could have = provided a significant step towards solving this problem by encoding the = destination transit AS in the packet at the first router capable of = resolving that information and then routing on that basis in the IDR = realm. In that case, stub networks (non-transit autonomous systems) = would not need to be visible in BGP and we would not need to track = prefix state beyond the closest transit ASNs. A separate map of = Prefix->Candidate Transit ASNs could be maintained through a mechanism = somewhat similar to DNS. >>>=20 >>> So you're in the LISP "we noticed that route caches do not scale, = but we >>> try again and again" camp now? >>=20 >> Who said anything about a route cache? >=20 > So you want to do the map lookup every time a packet traverses one of > these routers? Or should the Prefix->Candidate Transit ASNs map be > distributed everywhere, like, with BGP, so all these routers get to = hold > 100M map entries all the time? There=E2=80=99s a difference between caching part of a map in RAM for = active flows and having to cache an entire routing table for all possible destinations = with full path information and multiple alternatives. One is a very large data structure for each possible path. Also, the lookup doesn=E2=80=99t have to be performed by every router in = the path, just the first IDR capable router in the path. So this is very different from the LISP approach. Owen From nobody Fri Nov 13 12:44: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 019421B30ED for ; Fri, 13 Nov 2015 12:44:26 -0800 (PST) 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 waGGIuyH31JF for ; Fri, 13 Nov 2015 12:44:24 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id BCFF81B30EB for ; Fri, 13 Nov 2015 12:44:24 -0800 (PST) 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 tADKfFIZ015257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 12:41:15 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Fri, 13 Nov 2015 12:41:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 20:44:26 -0000 > On Nov 13, 2015, at 11:36 , Hemant Singh (shemant) = wrote: >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, November 13, 2015 12:43 PM > To: Hemant Singh (shemant) > Cc: Alexandre Petrescu; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >> How is it possible to have a duplicate address on a loopback = interface? >=20 > A router configures a loopback interface and provisions an IPv6 = address on the interface. The is a LAN in the router downstream port = which the router destines packets to using the source as the IPv6 = address on the loopback. The LAN segment may have a duplicate unless = the loopback IPv6 address is disjoint from any IPv6 prefix on the router = and router LAN/WAN segment. Another use case is already mentioned in = this thread - two routers directly connected. >=20 > Hemant=20 Sure, but in such a case, DAD on the LAN interface wouldn=E2=80=99t = detect the loopback nor would DAD on the loopback interface. Owen From nobody Fri Nov 13 12:50: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 77C361B3131 for ; Fri, 13 Nov 2015 12:50:45 -0800 (PST) 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 rSCc2kGCs33F for ; Fri, 13 Nov 2015 12:50:42 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 25FCD1B312D for ; Fri, 13 Nov 2015 12:50:41 -0800 (PST) Received: (qmail 54354 invoked from network); 13 Nov 2015 20:50:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Nov 2015 20:50:39 -0000 Date: Fri, 13 Nov 2015 21:50:39 +0100 (CET) Message-Id: <20151113.215039.74722090.sthaug@nethelp.no> To: owen@delong.com From: sthaug@nethelp.no In-Reply-To: References: <8B6940FB-C0B0-47C3-8780-9B7412F0D583@delong.com> <20151113192141.GE89490@Space.Net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 20:50:45 -0000 > > So you want to do the map lookup every time a packet traverses one of > > these routers? Or should the Prefix->Candidate Transit ASNs map be > > distributed everywhere, like, with BGP, so all these routers get to hold > > 100M map entries all the time? > > There$,1ry(Bs a difference between caching part of a map in RAM for active flows and > having to cache an entire routing table for all possible destinations with full path > information and multiple alternatives. Caching active flows has been tried before, repeatedly, and unfortunately it doesn't scale. Steinar Haug, AS 2116 From nobody Fri Nov 13 13:10: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 A57D51B2B54 for ; Fri, 13 Nov 2015 13:10:57 -0800 (PST) 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 TD8kWztcz0RW for ; Fri, 13 Nov 2015 13:10:56 -0800 (PST) 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 2926F1B2B23 for ; Fri, 13 Nov 2015 13:10:56 -0800 (PST) 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 A85F63493DE; Fri, 13 Nov 2015 21:10:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EEE59160032; Fri, 13 Nov 2015 21:10:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E0F08160085; Fri, 13 Nov 2015 21:10:56 +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 hbFTjvoTP8B8; Fri, 13 Nov 2015 21:10:56 +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 98325160032; Fri, 13 Nov 2015 21:10:56 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AE1FF3CA1678; Sat, 14 Nov 2015 08:10:15 +1100 (EST) To: Philip Homburg From: Mark Andrews References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> In-reply-to: Your message of "Fri, 13 Nov 2015 20:19:19 +0100." Date: Sat, 14 Nov 2015 08:10:15 +1100 Message-Id: <20151113211015.AE1FF3CA1678@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 13 Nov 2015 21:10:57 -0000 In message , Philip Homburg writes: > >> I don't think a host should try to figure out which paths work and which > >> don't. > >> > >> Maybe somebody can come up with a simple algorithm that generalises > >> happy-eyeballs and that is compatible with today's host operating systems. > >> But I doubt it. > > > >We tried. It's called shim6. Firewalls break it. > > I'd call shim6 a protocol and not an algorithm. Happy eyeballs is quite > compatible with firewalls, NAT, etc. No problem there. I'm sure happy > eyeballs-like approaches can be tried for the multiple-prefix case. > > The problem I ran into is that by the time my happy eyeballs implementation > did everything I wanted it do, it was way to complex. Adding support for > many source prefixes would just be too much. > > Now, maybe somebody can come up with an approach that doesn't have that > problem. Don't know. > > Mean while, I have something that works with every operating system today. > It may not be perfect. So I'm not terribly motivated to add more host > complexity to solve those edge cases. The simplest way will probably be to extend getaddrinfo to return pairs of address and just work down the list until you get a working connection starting new ones relatively quickly after waiting 50 ms or so between first few to reduce the number of embryonic connects that you kill when you get success. It adds one more system call to the default loop when starting a tcp connection. socket, fcntl, fcntl, bind, connect, select/poll vs socket, fcntl, fcntl, connect, select/poll For subsequent connections to the same node from the same application for the same session you just re-use the discovered pair of addresses. Mark > _______________________________________________ > 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 Nov 13 13:39: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 05CE21B32D8 for ; Fri, 13 Nov 2015 13:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uat9WsAz1cVR for ; Fri, 13 Nov 2015 13:39:43 -0800 (PST) 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 B0F591B32CC for ; Fri, 13 Nov 2015 13:39:42 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tADLddfJ056641 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 21:39:40 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local To: Mikael Abrahamsson References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> From: Nick Hilliard Message-ID: <5646589B.7060703@foobar.org> Date: Fri, 13 Nov 2015 21:39:39 +0000 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: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 13 Nov 2015 21:39:45 -0000 On 13/11/2015 13:50, Mikael Abrahamsson wrote: > If the Internet will have 10x the number of routes it has today in the > not-so-distant-future, there is a considerable risk that most smaller > players won't be able to afford to have a full view. the dfz is growing linearly at ~50k prefixes/year. On this basis, 10x the number of prefixes is a very long way away. Nick From nobody Fri Nov 13 14:00: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 C08BE1B3326 for ; Fri, 13 Nov 2015 14:00:11 -0800 (PST) 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 OtexKvEVYD9D for ; Fri, 13 Nov 2015 14:00:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DBD1B3322 for ; Fri, 13 Nov 2015 14:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1447452010; x=1448661610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RdmaVt7TZMTaskHCqtUwRk1q8TQaXh2qXwFehywklR4=; b=XMeYcHLhWaZRO8KdovQSYm7a97bZq95IewfN50NZv1v4Y0EWGzRPm8UR UlmJGzbUVzFQ15EL6vpQFrvs4sRgnK/aQGKkft3tSeHRzXiHTF4ONc8iT +v9I3BXOslmjVzXvFGp8nh9fVKDlTTxLYpx53YeyS/SaVgvDNdgKlXWAQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgBHXEZW/49dJa1dgzuBQga+RgENg?= =?us-ascii?q?WSGEAIcgSI4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUIiCawAJA3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGEQoMzgUQFl?= =?us-ascii?q?kgBjR+cSwEfAQFChARyhDaBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="49484314" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 13 Nov 2015 22:00:09 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tADM09k1001022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 22:00:09 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 17:00:08 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 17:00:08 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIA== Date: Fri, 13 Nov 2015 22:00:08 +0000 Message-ID: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 22:00:11 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT3dlbiBEZUxvbmcgW21haWx0bzpv d2VuQGRlbG9uZy5jb21dIA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxMywgMjAxNSAzOjQxIFBN DQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KQ2M6IEFsZXhhbmRyZSBQZXRyZXNjdTsgdjZv cHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIERBRCBhZ2FpbiBbd2FzOiBkcmFmdC1p ZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbl0NCg0KDQo+U3VyZSwg YnV0IGluIHN1Y2ggYSBjYXNlLCBEQUQgb24gdGhlIExBTiBpbnRlcmZhY2Ugd291bGRu4oCZdCBk ZXRlY3QgdGhlIGxvb3BiYWNrIG5vciB3b3VsZCBEQUQgb24gdGhlIGxvb3BiYWNrIGludGVyZmFj ZS4NCg0KSWYgdGhlIGxvb3BiYWNrIGludGVyZmFjZSBpc3N1ZXMgYSBEQUQgcHJvYmUgYW5kIGlm IHRoZSByb3V0ZXIgc2VuZHMgdGhlIHByb2JlIG91dCB0aGUgb3V0Ym91bmQgaW50ZXJmYWNlLCBh bm90aGVyIGhvc3Qgb24gdGhlIExBTiBzZWdtZW50IGRvZXMgc2VlIHRoZSBEQUQgcHJvYmUuICBP biBkZXRlY3RpbmcgYSBkdXBsaWNhdGUsIGFub3RoZXIgbm9kZSBzZW5kcyBhbiBOQSB0byBzaWdu YWwgYSBEdXAuICBUaGUgTkEgZG9lcyByZWFjaCB0aGUgcm91dGVyJ3Mgb3V0Ym91bmQgaW50ZXJm YWNlIGFuZCB0aGVuIHRoZSByb3V0ZXIga25vd3MgdGhlIElQdjYgYWRkcmVzcyBwcm92aXNpb25l ZCBvbiB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIGFuZCB0aHVzIGNhbm5vdCBiZSB1c2VkDQoNCkFu IGFwcCBzdWNoIGFzIHRmdHB2NiBvciBOVFB2NiB1c2VzIElQdjYgZ2xvYmFsIGFkZHJlc3Mgb2Yg dGhlIGxvb3BiYWNrIGludGVyZmFjZSBhcyBzb3VyY2UgSVB2NiBhZGRyZXNzLiAgIElmIGEgZHVw bGljYXRlIGV4aXN0cyBpbiB0aGUgTEFOIHNlZ21lbnQsIGNvdWxkbid0IHRoZSB0ZnRwdjYgb3Ig TlRQdjYgc2VydmVyIHJlc3BvbnNlcyBoZWFkIHRvIHRoZSBkdXAgaW4gdGhlIExBTiBpbnN0ZWFk IG9mIHRoZSBsb29wYmFjayBpbnRlcmZhY2Ugb24gdGhlIHJvdXRlcj8NCg0KSWYgYSBsb29wYmFj ayBpbnRlcmZhY2UgZG9lcyBub3QgcGVyZm9ybSBEQUQsIHRoZW4gdXNlIGEgY29uZmlndXJhdGlv biBvbiB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIHRvIHNldCBEdXBBZGRyRGV0ZWN0VHJhbnNtaXRz IHRvIHplcm8uICBXaHkgY2hhbmdlIG90aGVyIHRleHQgaW4gUkZDNDg2MSB0byBzcGVjaWFsLWNh c2UgYSBsb29wYmFjayBpbnRlcmZhY2UgdG8gYmUgZXhjbHVkZWQgZm9yIERBRC4NCg0KSGVtYW50 IA0K From nobody Fri Nov 13 14:52: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 B3E341B33E1 for ; Fri, 13 Nov 2015 14:52:09 -0800 (PST) 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 bYA0NgJ94Q2a for ; Fri, 13 Nov 2015 14:52:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 170F11B33DF for ; Fri, 13 Nov 2015 14:52:07 -0800 (PST) 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 tADMn0Ot031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 14:49:01 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> Date: Fri, 13 Nov 2015 14:49:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 22:52:09 -0000 > On Nov 13, 2015, at 14:00 , Hemant Singh (shemant) = wrote: >=20 >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, November 13, 2015 3:41 PM > To: Hemant Singh (shemant) > Cc: Alexandre Petrescu; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >=20 >> Sure, but in such a case, DAD on the LAN interface wouldn=E2=80=99t = detect the loopback nor would DAD on the loopback interface. >=20 > If the loopback interface issues a DAD probe and if the router sends = the probe out the outbound interface, another host on the LAN segment = does see the DAD probe. On detecting a duplicate, another node sends an = NA to signal a Dup. The NA does reach the router's outbound interface = and then the router knows the IPv6 address provisioned on the loopback = interface and thus cannot be used Sure, but you=E2=80=99re talking about this like the interface is = autonomous from the operating system in this process which is absurd. An interface doesn=E2=80=99t issue a DAD probe, the operating system = does. The operating system, further, sends those out on the interface = where the address in question is to be configured. I suppose if the interface is a member of a bridge group (e.g. lo0 and = eth0 are both members of br125 and the address in question is being = configured on br125), then you would see the DAD request sent to both = eth0 and lo0 as they are part of a common link (from the OS perspective, = it is sent to br0 which in turn invokes the bridging driver which would = deliver the packets in question to lo0 and eth0 as a result of the = bridge group definition). Short of that, however, the behavior you describe doesn=E2=80=99t match = my understanding of the reality in any modern operating system with = which I am familiar. In most circumstances, it=E2=80=99s far from desirable to have addresses = from the same subnet on different links separated by a router. (lo0 is = separated from eth0 by the host in question which is acting as a router = if it accepts packets on eth0 for destination address(es) configured on = lo0 whether you want to admit this to yourself or not). In fact, most = properly designed routers will flag such configurations as an error and = refuse to install them. > An app such as tftpv6 or NTPv6 uses IPv6 global address of the = loopback interface as source IPv6 address. If a duplicate exists in = the LAN segment, couldn't the tftpv6 or NTPv6 server responses head to = the dup in the LAN instead of the loopback interface on the router? You=E2=80=99re talking about a strange corner case with a misconfigured = router. Not sure why we should waste time engineering for such = brokenness in the first place. > If a loopback interface does not perform DAD, then use a configuration = on the loopback interface to set DupAddrDetectTransmits to zero. Why = change other text in RFC4861 to special-case a loopback interface to be = excluded for DAD. I would argue that DAD on a lo interface is an absurd concept. By = definition the addresses on a lo interface should not be outside of the = exclusive control of the host in question and it should know all = addresses in use on the lo interface. The lo interface should not be sharing addresses with other interfaces = unless they are members of a common bridge interface in which case the = address would not apply to lo but would, instead, apply to the bridge = group. DAD is required on a bridge group interface. There is no need for DAD on a loopback interface in any sane = configuration. Owen From nobody Fri Nov 13 15:06: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 913F11B3450 for ; Fri, 13 Nov 2015 15:06:25 -0800 (PST) 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 1_tjj-yENFdz for ; Fri, 13 Nov 2015 15:06:24 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633551B3429 for ; Fri, 13 Nov 2015 15:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1306; q=dns/txt; s=iport; t=1447455984; x=1448665584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hzg0LF7vqWB6UBTLUmJoSunncMq5D+epmNHe1O+DYUU=; b=J68FZBE52qE5NTgsE3QDP6/N/QNNMCo8+ziS5PNsveLiLNOYWf7l0YkL I6DzhuR52VrgmyF+6Qiew1mloFJqgRmYN8+YIWsOX17jLN7BxN/TzG3SF CKjeTIn7TD39PBfPo0gM1thkh0iwVs80ayMBlYYc8FcJhZtPmNgmKNa4B Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDLa0ZW/5BdJa1egzuBQga+RgENg?= =?us-ascii?q?WSGEAIcgSI4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUIiCawFZA7AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGHdYFEBZZIA?= =?us-ascii?q?Y0fnEsBHwEBQoIRHYFWcoQ2gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="208356783" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2015 23:06:23 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tADN6NF4024135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 23:06:23 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 18:06:22 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 18:06:22 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4A= Date: Fri, 13 Nov 2015 23:06:22 +0000 Message-ID: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> In-Reply-To: <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.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.82.255.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 23:06:25 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPd2VuIERlTG9uZyBbbWFpbHRv Om93ZW5AZGVsb25nLmNvbV0gDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEzLCAyMDE1IDU6NDkg UE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQpDYzogQWxleGFuZHJlIFBldHJlc2N1OyB2 Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gREFEIGFnYWluIFt3YXM6IGRyYWZ0 LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uXQ0KDQoNCj5JIHdv dWxkIGFyZ3VlIHRoYXQgREFEIG9uIGEgbG8gaW50ZXJmYWNlIGlzIGFuIGFic3VyZCBjb25jZXB0 LiBCeSBkZWZpbml0aW9uIHRoZSBhZGRyZXNzZXMgb24gYSBsbyBpbnRlcmZhY2Ugc2hvdWxkIG5v dCBiZSBvdXRzaWRlIG9mIHRoZSBleGNsdXNpdmUgY29udHJvbCBvZiB0aGUgaG9zdCBpbiBxdWVz dGlvbiBhbmQgaXQgc2hvdWxkIGtub3cgYWxsID5hZGRyZXNzZXMgaW4gdXNlIG9uIHRoZSBsbyBp bnRlcmZhY2UuDQoNCldoZXJlIGRvZXMgdGhlIGJ1Y2sgc3RvcD8gSWYgdGhlIGxvIGludGVyZmFj ZSBkb2VzIG5vdCBwZXJmb3JtIERBRCwgdGhlIGludGVyZmFjZSBzaG91bGQgbm90IGpvaW4gdGhl IGFsbC1ub2RlcyBhbmQgaXRzIHNvbGljaXRlZC1ub2RlIG11bHRpY2FzdCBhZGRyZXNzPyAgIFRo ZSBsbyBpbnRlcmZhY2Ugc2hvdWxkIG5vdCBzdXBwb3J0IE5EIGFkZHJlc3MgcmVzb2x1dGlvbiBl aXRoZXIuICBUaGUgaW50ZXJmYWNlcyBlbmRzIHVwIG5vdCBzdXBwb3J0aW5nIGFueSBORCBub3Ig YW55IERBRC4NCg0KSWYgdGhlIGxvIGludGVyZmFjZSBkb2VzIG5vdCBwZXJmb3JtIERBRCwgYXMg SSBzYWlkIGJlZm9yZSwgc2V0IHRoZSBEdXBBZGRyRGV0ZWN0VHJhbnNtaXRzIHZhcmlhYmxlIGZv ciB0aGUgaW50ZXJmYWNlIHRvIGJlIHplcm8uIA0KDQpIZW1hbnQNCg0K From nobody Fri Nov 13 15:18: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 0825E1B34BB for ; Fri, 13 Nov 2015 15:18:55 -0800 (PST) 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 C_z8iiDIqlhr for ; Fri, 13 Nov 2015 15:18:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5D41B34BC for ; Fri, 13 Nov 2015 15:18:52 -0800 (PST) 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 tADNFm3J001655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 15:15:48 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Fri, 13 Nov 2015 15:15:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 23:18:55 -0000 > On Nov 13, 2015, at 15:06 , Hemant Singh (shemant) = wrote: >=20 >=20 >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, November 13, 2015 5:49 PM > To: Hemant Singh (shemant) > Cc: Alexandre Petrescu; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >=20 >> I would argue that DAD on a lo interface is an absurd concept. By = definition the addresses on a lo interface should not be outside of the = exclusive control of the host in question and it should know all = >addresses in use on the lo interface. >=20 > Where does the buck stop? If the lo interface does not perform DAD, = the interface should not join the all-nodes and its solicited-node = multicast address? The lo interface should not support ND address = resolution either. The interfaces ends up not supporting any ND nor any = DAD. Let me try and be more clear since you seem determined to follow = reductio ad absurdum. A LO interface may, but does not need to perform DAD as far as I am = concerned. Sure, if it=E2=80=99s convenient for the coders, the = performance impact is negligible and it keeps code paths consistent = reducing the potential for bugs. However, there=E2=80=99s no benefit. An LO address can=E2=80=99t have = any address on it not assigned under the exclusive control of the host = on which the LO interface is being managed, by definition, so it=E2=80=99s= impossible for there to be a duplicate. However, that does not mean that those addresses don=E2=80=99t need to = work with ND correctly as it may well be that application A binds to one = address on LO and communicates with an entirely different address also = on LO to carry out transactions with application B. As a result, A will = need to be able to discover the link layer address for B, effectively. Arguably, ND isn=E2=80=99t necessary since the LO binding should take = care of this, but most operating systems don=E2=80=99t bother to special = case this as the effort offers little reward and substantial complexity. > If the lo interface does not perform DAD, as I said before, set the = DupAddrDetectTransmits variable for the interface to be zero.=20 I have no problem with that. Just saying that there=E2=80=99s no need = for LO to perform DAD in any sane configuration. Probably no reason for = LO not to default to DupAddrDetectTransmits=3D0 as well. Owen From nobody Fri Nov 13 15:37: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 6A6CB1B3544 for ; Fri, 13 Nov 2015 15:37:09 -0800 (PST) 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, 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 iPeJvJBmfZ_2 for ; Fri, 13 Nov 2015 15:37:08 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 241131B3543 for ; Fri, 13 Nov 2015 15:37:08 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Fri, 13 Nov 2015 17:37:04 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by iouu10 with SMTP id u10so105761555iou.0 for ; Fri, 13 Nov 2015 15:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=angLgQt10EGlQyTAfItiN0w+qwh855SpEeTuzD8j/mg=; b=HDuSh4B9YQMfdMwr57dB7nlxzAx340s7JZR3LsPwsCkJYtMx72aCWEG4LedIIK/0dK 17+tM5vjTt+YxZZHz0VnHoo8akYZngRlltNeAbXGxJMzK93bACYjwRnmZFhBjywFivLm qeKRBNERIRK4/7Az/ePrL9GLPNe1in62BvGbg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=angLgQt10EGlQyTAfItiN0w+qwh855SpEeTuzD8j/mg=; b=OtO0TSJzNQDRGtNPIKBxWbyZ+s5oJztQPz7C34OmMt2Lmt57s2UhbEVSMhFzOdQI5o nMdHMEpr02BXDBIR+kQoI7kkmZ7Jk3tECCMO3BlH+OSX++JXx8UQb6/3ZUlH0vTw3W3j 9UBi1K0Rk38lRXARpaW1Dd79nHrxTX4ovN+1a6tQ3Mg4v0WK73CUF5QHVUlndtfz18RF asN3OLRPe5GaQ8lWVRujMkjQDDwfD06fAPKrJTWdDdajXs5HyytxzPyG5C7fh6mOGO9I QkaqHRZ0btAPJ+u3PgfOHHcWA5Y8TK82/RGMpcFv9l05HN86mPBqKZIzn1sjQqFEFJtU n/Wg== X-Gm-Message-State: ALoCoQli90x7W8MX4rfDcDiuIpsMQp7eaQekFZMQ1qiMrxY6llb9/qIk52RVtjnLH7s9r9pgG8K4lmHo+FaziM1pYv9qP+DH08vvX3pMUwGn/kkPgTqxjAKq3v1P/ZDOqSPPvEh1ClWV X-Received: by 10.107.36.208 with SMTP id k199mr26859354iok.147.1447457824391; Fri, 13 Nov 2015 15:37:04 -0800 (PST) X-Received: by 10.107.36.208 with SMTP id k199mr26859345iok.147.1447457824219; Fri, 13 Nov 2015 15:37:04 -0800 (PST) Received: from x-10-104-136-138.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:7568:bc65:ae67:6397]) by smtp.gmail.com with ESMTPSA id c92sm7696169iod.0.2015.11.13.15.37.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 15:37:02 -0800 (PST) References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <2B03B738-F348-4A69-B2F5-881820B615FB@delong.com> To: "Howard, Lee" From: David Farmer Organization: University of Minnesota Message-ID: <5646741E.5040900@umn.edu> Date: Fri, 13 Nov 2015 17:37:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 23:37:09 -0000 On 11/13/15 13:41 , Howard, Lee wrote: > I apologize for not continuing to ride herd on this thread since returning > from the IETF meeting. > > Please, let us focus on this document in this thread. So, I think we are going with some from of "NPT66 and NAT66 are not recommended" along with pointers to what breaks if you use NPT66 or NAT66, section 5 of RFC6296, RFC4864, RFC2993, etc... What about addressing solutions to the issues that are driving some to consider NPT, which I think are multihoming, provider lock in, and fundamentally renumbering. So maybe reference LISP (RFC6830), ILNP (RFC6740), renumbering (RFC5887), and maybe the Home Net architecture (RFC7368). Other suggestions? It's not an effective argument to say; "Don't do that, because we said so, and we don't know what you should do, just not that." To be effective besides telling people "don't do that", we need to tell them "why they shouldn't" and probably more important "what the alternatives are". So "NAT is harmful" is not an effective argument. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Fri Nov 13 15:44: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 4A69A1B3573 for ; Fri, 13 Nov 2015 15:44:39 -0800 (PST) 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 Cv2YxmVNbr4M for ; Fri, 13 Nov 2015 15:44:37 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5CB1B3570 for ; Fri, 13 Nov 2015 15:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1447458277; x=1448667877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k3SMc0bnhaPtUb7r0ytYZwuAGSPIAlcUhpdBdK4eNz4=; b=gtUKK4K+SlPBdCf1O0XFCGj4+6ogz1jtWXH+9lJdpdVQzfGvqQyP26lO B4xYldRmDl9Mnd8mZVIeLQDtQGNPzQyyvcrfYSsweDH0FjtVf1GHNFR1Y HVzpcdu/MdJZcnAPIkyqpwRD4Fyfigo32RzWv9fVwN965nnZ50FuZ2Nxx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgAbdUZW/5JdJa1egzuBQga+RQENg?= =?us-ascii?q?WSGEAIcgRo4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUIiCawCJA3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGHdYFEBZZIA?= =?us-ascii?q?Y0fgWKEQJYpAR8BAUKCER2BVnKENoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="49508878" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 13 Nov 2015 23:44:36 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tADNiaos027478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 23:44:36 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 18:44:35 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 18:44:35 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA Date: Fri, 13 Nov 2015 23:44:35 +0000 Message-ID: <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> In-Reply-To: <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.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.82.255.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 13 Nov 2015 23:44:39 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPd2VuIERlTG9uZyBbbWFpbHRv Om93ZW5AZGVsb25nLmNvbV0gDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEzLCAyMDE1IDY6MTYg UE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQpDYzogQWxleGFuZHJlIFBldHJlc2N1OyB2 Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gREFEIGFnYWluIFt3YXM6IGRyYWZ0 LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uXQ0KDQoNCj5BIExP IGludGVyZmFjZSBtYXksIGJ1dCBkb2VzIG5vdCBuZWVkIHRvIHBlcmZvcm0gREFEIGFzIGZhciBh cyBJIGFtIGNvbmNlcm5lZC4gU3VyZSwgaWYgaXTigJlzIGNvbnZlbmllbnQgZm9yIHRoZSBjb2Rl cnMsIHRoZSBwZXJmb3JtYW5jZSBpbXBhY3QgaXMgbmVnbGlnaWJsZSBhbmQgaXQga2VlcHMgY29k ZSBwYXRocyBjb25zaXN0ZW50IHJlZHVjaW5nID50aGUgcG90ZW50aWFsIGZvciBidWdzLg0KDQpQ bGVhc2UgcmVwbHkgdG8gbXkgY29tbWVudCB3aGVyZSBJIHNhaWQgaWYgdGhlIGxvIGRvZXMgbm90 IHBlcmZvcm0gREFELCB0aGVuIHRoZSBsbyBkb2VzIG5vdCBoYXZlIHRvIGpvaW4gdGhlIGFsbC1u b2RlcyBhbmQgdGhlIHNvbGljaXRlZC1ub2RlIG11bHRpY2FzdCBhZGRyZXNzZXMuICAgT25lIGhh cyB0byBsb29rIGF0IHRoZSBjb21wcmVoZW5zaXZlIHBpY3R1cmUuICAgQSBOQSBzaWduYWxpbmcg YSBEQUQgZHVwIGlzIGRlc3RpbmVkIHRvIHRoZSBhbGwtbm9kZXMgbXVsdGljYXN0IGRlc3RpbmF0 aW9uIC0gYnV0IHRoZSBsbyBpbnRlcmZhY2UgaGFzIGRpc2FibGVkIERBRC4gICBTbyB3aHkgam9p biB0aGUgYWxsLW5vZGVzIGFkZHJlc3Mgb3IgdGhlIHNvbGljaXRlZC1ub2RlIG11bHRpY2FzdCBh ZGRyZXNzPyAgSWYgdGhlIGludGVyZmFjZSBpcyBhbHNvIG5vdCBpbml0aWF0aW5nIG5vciByZXBs eWluZyB0byBhbnkgYWRkcmVzcyByZXNvbHV0aW9uLCB0aGVyZSBpcyBub3QgTkQgb3BlcmF0aW9u IHJlcXVpcmVkIG9uIHRoaXMgbG8gaW50ZXJmYWNlLg0KDQo+SG93ZXZlciwgdGhhdCBkb2VzIG5v dCBtZWFuIHRoYXQgdGhvc2UgYWRkcmVzc2VzIGRvbuKAmXQgbmVlZCB0byB3b3JrIHdpdGggTkQg Y29ycmVjdGx5IGFzIGl0IG1heSB3ZWxsIGJlIHRoYXQgYXBwbGljYXRpb24gQSBiaW5kcyB0byBv bmUgYWRkcmVzcyBvbiBMTyBhbmQgY29tbXVuaWNhdGVzIHdpdGggYW4gZW50aXJlbHkgZGlmZmVy ZW50ID5hZGRyZXNzIGFsc28gb24gTE8gdG8gY2Fycnkgb3V0IHRyYW5zYWN0aW9ucyB3aXRoIGFw cGxpY2F0aW9uIEIuIEFzIGEgcmVzdWx0LCBBIHdpbGwgbmVlZCB0byBiZSBhYmxlIHRvIGRpc2Nv dmVyIHRoZSBsaW5rIGxheWVyIGFkZHJlc3MgZm9yIEIsIGVmZmVjdGl2ZWx5Lg0KDQpOby4gIFRo ZSBsbyBpbnRlcmZhY2UgZm9yd2FyZHMgYSBwYWNrZXQgdG8gdGhlIG91dGJvdW5kIGludGVyZmFj ZSB3aGljaCBwZXJmb3JtcyBhbnkgTkQgYWRkcmVzcyByZXNvbHV0aW9uLiANCg0KPkFyZ3VhYmx5 LCBORCBpc27igJl0IG5lY2Vzc2FyeSBzaW5jZSB0aGUgTE8gYmluZGluZyBzaG91bGQgdGFrZSBj YXJlIG9mIHRoaXMsIGJ1dCBtb3N0IG9wZXJhdGluZyBzeXN0ZW1zIGRvbuKAmXQgYm90aGVyIHRv IHNwZWNpYWwgY2FzZSB0aGlzIGFzIHRoZSBlZmZvcnQgb2ZmZXJzIGxpdHRsZSByZXdhcmQgYW5k IHN1YnN0YW50aWFsIGNvbXBsZXhpdHkuDQoNClBsZWFzZSBub3RlIElQdjYgTkQgYW5kIERBRCBh cmUgaW50ZXJmYWNlLXNjb3BlZC4gICBBbiBPUyBoYXMgdG8gY29uZmlybSB0byBpbnRlcmZhY2Ut c3BlY2lmaWMgSVB2NiBEQUQgYW5kIE5EIHByb3BlcnRpZXMuIA0KDQpIZW1hbnQNCg== From nobody Fri Nov 13 16: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 6C06B1B362A for ; Fri, 13 Nov 2015 16:09:21 -0800 (PST) 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 sIPBXndCgsBu for ; Fri, 13 Nov 2015 16:09:20 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0094B1B3629 for ; Fri, 13 Nov 2015 16:09:19 -0800 (PST) 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 tAE06D86007973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 16:06:14 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> Date: Fri, 13 Nov 2015 16:06:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 00:09:21 -0000 > On Nov 13, 2015, at 15:44 , Hemant Singh (shemant) = wrote: >=20 >=20 >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, November 13, 2015 6:16 PM > To: Hemant Singh (shemant) > Cc: Alexandre Petrescu; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >=20 >> A LO interface may, but does not need to perform DAD as far as I am = concerned. Sure, if it=E2=80=99s convenient for the coders, the = performance impact is negligible and it keeps code paths consistent = reducing >the potential for bugs. >=20 > Please reply to my comment where I said if the lo does not perform = DAD, then the lo does not have to join the all-nodes and the = solicited-node multicast addresses. One has to look at the = comprehensive picture. A NA signaling a DAD dup is destined to the = all-nodes multicast destination - but the lo interface has disabled DAD. = So why join the all-nodes address or the solicited-node multicast = address? If the interface is also not initiating nor replying to any = address resolution, there is not ND operation required on this lo = interface. Depending on the implementation, it may be needed for neighbor = discovery/reachability, though admittedly this is unlikely. Solicited Node and all-nodes are used for several things besides just = DAD. I don=E2=80=99t see the relationship that you are seeing or at least I = don=E2=80=99t see it as being the only relationship in question. >=20 >> However, that does not mean that those addresses don=E2=80=99t need = to work with ND correctly as it may well be that application A binds to = one address on LO and communicates with an entirely different >address = also on LO to carry out transactions with application B. As a result, A = will need to be able to discover the link layer address for B, = effectively. >=20 > No. The lo interface forwards a packet to the outbound interface = which performs any ND address resolution.=20 Not in any implementation I am aware of. Why would you expect such a = thing? Why would the LO address be on the same subnet as any =E2=80=9Coutbound=E2= =80=9D interface? Your argument here appears nonsensical to me. >> Arguably, ND isn=E2=80=99t necessary since the LO binding should take = care of this, but most operating systems don=E2=80=99t bother to special = case this as the effort offers little reward and substantial complexity. >=20 > Please note IPv6 ND and DAD are interface-scoped. An OS has to = confirm to interface-specific IPv6 DAD and ND properties.=20 Yes=E2=80=A6 hence my confusion about your statements and questions = above. Even though they are interface-scoped, every interface on the system may = use the same code paths for ND and DAD, in which case the LO interface = may (unnecessarily) implement ND and/or DAD for convenience. Owen From nobody Fri Nov 13 16:36: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 5A3C41B3683 for ; Fri, 13 Nov 2015 16:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 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_64=0.6, J_CHICKENPOX_75=0.6, 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 nLFtqVA1ayUT for ; Fri, 13 Nov 2015 16:36:05 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48071B368D for ; Fri, 13 Nov 2015 16:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1447461364; x=1448670964; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NOCgtRI+s88ketOy2lrxk3ejwgr/JbGBjsX4JpRf0Vk=; b=UNZsQhOXgWhCqUy6eF7jajCQt4LJauaEZu/+plwMBvo7+Pk5Zbl4qFJu 3MYIn9wmlcJQ72E+R9CsYavPYfRXVKy0/T64xx9rHhTM52MVUfuYFbpxT oTNP9ekdAHNxdDQiNUfd2HX0QkGeqQaObvkf7llGBombnkMdrJmkgZIim Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDQgEZW/5NdJa1egzuBQga+RQENg?= =?us-ascii?q?WSGEAIcgRo4FAEBAQEBAQGBCoQ0AQEBAwEjEUUFBwQCAQgRBAEBAwIjAwICAjA?= =?us-ascii?q?UAQgIAgQOBQiIHgivd5A3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGEKhEBN?= =?us-ascii?q?YMEgUQFlkgBjR+BYoRAlikBHwEBQoIRHYFWcoN8OoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="46722686" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 14 Nov 2015 00:36:04 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAE0a3U7018839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Nov 2015 00:36:04 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 19:36:03 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 19:36:03 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA///AA4CAAE9HQA== Date: Sat, 14 Nov 2015 00:36:03 +0000 Message-ID: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 00:36:06 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPd2VuIERlTG9uZyBbbWFpbHRv Om93ZW5AZGVsb25nLmNvbV0gDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEzLCAyMDE1IDc6MDYg UE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQpDYzogQWxleGFuZHJlIFBldHJlc2N1OyB2 Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gREFEIGFnYWluIFt3YXM6IGRyYWZ0 LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uXQ0KDQo+IFNvbGlj aXRlZCBOb2RlIGFuZCBhbGwtbm9kZXMgYXJlIHVzZWQgZm9yIHNldmVyYWwgdGhpbmdzIGJlc2lk ZXMganVzdCBEQUQuDQoNCkkgYWxyZWFkeSBzYWlkIHRoZSBsbyBpbnRlcmZhY2UgZG9lcyBub3Qg cGVyZm9ybSBEQUQgbm9yIGFueSBORCBvcGVyYXRpb25zLiAgIElmIHRoZSBsbyBpbnRlcmZhY2Ug ZG9lcyBub3QgcGVyZm9ybSBEQUQgbm9yIGFueSBORCBhZGRyZXNzIHJlc29sdXRpb24sIG5vciBp c3N1ZSBhbnkgcmVkaXJlY3RzLCB3aHkgaXMgdGhlIGludGVyZmFjZSBwZXJmb3JtaW5nIE5VRD8g IFBsZWFzZSBkaXNjdXNzIHN1Y2ggaXNzdWVzIGluIHRoZSA2bWFuIG1haWxlci4gDQoNCj4+IE5v LiAgVGhlIGxvIGludGVyZmFjZSBmb3J3YXJkcyBhIHBhY2tldCB0byB0aGUgb3V0Ym91bmQgaW50 ZXJmYWNlIHdoaWNoIHBlcmZvcm1zIGFueSBORCBhZGRyZXNzIHJlc29sdXRpb24uIA0KDQo+Tm90 IGluIGFueSBpbXBsZW1lbnRhdGlvbiBJIGFtIGF3YXJlIG9mLiBXaHkgd291bGQgeW91IGV4cGVj dCBzdWNoIGEgdGhpbmc/DQoNClRoaXMgaXMgbXkgbGFzdCBlbWFpbCBvbiB0aGUgc3ViamVjdC4g ICBBbnkgZnVydGhlciBkaXNjdXNzaW9uIHNob3VsZCBiZSBtb3ZlZCB0byB0aGUgNm1hbiBXRyBp biB0aGUgSUVURiwgbm90IHY2b3BzLCBzaW5jZSBwcm90b2NvbCBjaGFuZ2VzIHRvIFJGQzQ4NjIg YXJlIGJlaW5nIGRpc2N1c3NlZCAtIEkgYWdyZWUgd2l0aCBKaW5tZWkncyByZXBseSB0byB0aGlz IHRocmVhZC4gICBGb3IgZXhhbXBsZSwgdGhlIHJvdXRlciBpcyBwcm92aXNpb25lZCBmb3IgdGhl IHRmdHB2NiBjbGllbnQgYXBwIHRvIHVzZSB0aGUgbG8gaW50ZXJmYWNlIGZvciBzb3VyY2UgSVB2 NiBhZGRyZXNzLiAgVGhlIG91dGJvdW5kIGludGVyZmFjZSBpcyBldGgwLiAgIFdoZW4gdGhlIHRm dHB2NiBjbGllbnQgc2VuZHMgYSByZXEgcGFja2V0IG91dCBldGgwLCBpZiB0aGUgZGVzdGluYXRp b24gb2YgdGhlIHBhY2tldCBpcyBhbiBpbmNvbXBsZXRlIG5vciBub24tZXhpc3RlbnQgZW50cnkg aW4gdGhlIG5laWdoYm9yIGNhY2hlLCB0aGUgb3V0Ym91bmQgaW50ZXJmYWNlIGlzc3VlcyBhIE5E IGFkZHJlc3MgcmVzb2x1dGlvbi4gIEkgY2xlYXJlZCB0aGUgbmVpZ2hib3IgY2FjaGUgb24gbXkg cm91dGVyIGFuZCB0aGVuIGlzc3VlZCBhIHBpbmcgdG8gYSBub3J0aGJvdW5kIG5vZGUgYW5kIHVz ZWQgdGhlIHNvdXJjZSBvZiB0aGUgcGluZyBhcyB0aGUgbG8gaW50ZXJmYWNlLiANCg0Kcm91dGVy aSNzaCBpcHY2IGludCBiciBsbzANCkxvb3BiYWNrMCAgICAgICAgICAgICAgW3VwL3VwXQ0KICAg IEZFODA6OkM2MTQ6M0NGRjpGRTE3OjFDMDANCiAgICAyMDA0OjoxDQpyb3V0ZXJpI2NsZWFyIGlw djYgbmVpZ2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpyb3V0ZXJpIw0Kcm91 dGVyI3BpbmcgMjAwMTpkYjg6MzgwMDo4MDA6MjUwOjU2RkY6RkVCMjpGMTFEIHNvdXJjZSBsbzAN ClR5cGUgZXNjYXBlIHNlcXVlbmNlIHRvIGFib3J0Lg0KU2VuZGluZyA1LCAxMDAtYnl0ZSBJQ01Q IEVjaG9zIHRvIDIwMDE6ZGI4OjM4MDA6ODAwOjI1MDo1NkZGOkZFQjI6RjExRCwgdGltZW91dCBp cyAyIHNlY29uZHM6DQpQYWNrZXQgc2VudCB3aXRoIGEgc291cmNlIGFkZHJlc3Mgb2YgMjAwNDo6 MQ0KISEhISENClN1Y2Nlc3MgcmF0ZSBpcyAxMDAgcGVyY2VudCAoNS81KSwgcm91bmQtdHJpcCBt aW4vYXZnL21heCA9IDEvMS8xIG1zDQpyb3V0ZXIjDQoNCkhlbWFudA0K From nobody Fri Nov 13 17:54: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 31EE61B36C7 for ; Fri, 13 Nov 2015 17:54:43 -0800 (PST) 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 RQHpzgQdT-Ai for ; Fri, 13 Nov 2015 17:54:42 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 36D7E1B36DF for ; Fri, 13 Nov 2015 17:54:42 -0800 (PST) Received: by ykdr82 with SMTP id r82so175808595ykd.3 for ; Fri, 13 Nov 2015 17:54:41 -0800 (PST) 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=tftzoyk+G8zJkxzmSRMS/z0BBM96BqpN6JSYTtHYNOA=; b=l0zjPRpsyb1dDCwprUNzku4FPZIiAauEoqRabg5m6TKzek4bRhsbHCX1aOctDQTaDU QIpPKnPOHYzBSNmmillUNHAiLZlZDEG6r1D7RWWdomo7x5YfwLsoeyXVproFFs0Mdzjc dBQ0xJNDlvlcc//g3O7Yj7UXIjGqIjllzP6L9ZIkkH7+a3d1FWKJpz3EoQm3jTnklKsS OoEIXxME0lzdiu/bgx8bMGsD4KJGI8WS/5sqPSjViUrUpOZIVVUfrgUIebfvoU4L1iEe 5rOs06UcOgTG2XL6+mlI87ALnwi6SAgZfhs/AhNKFKilIpom6XgY2TjTnRQzhU1VwErL jo5Q== 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=tftzoyk+G8zJkxzmSRMS/z0BBM96BqpN6JSYTtHYNOA=; b=OG+e+vq7qqDqMEm2NuYAj1zRAs8J1LO3l2cWB48igk+Tg2YeG+/UJLsFSSjYwxQQlr /WgnKGEeBBwHi+p3UN+r9aJ6S6DnkmOtADvWFwDMkfu5vCg76JBgsBbYpaNjifoMNlP+ GyEagYCqGvgnZhvUdzF921ltrVauWjitbWDPErODCuA6lcocNB0b2UPuuWsbbZDTx6SV 2ELAqv9it/dw4csraHS62DY7WYPNujTSTxcz3SvdJmOxhrbInNBCBsdomkZTxU4SZ+86 9p7yLANjtU5gHSKAMQwryeqzuTSRVoLrmc8QlX6nY64mDJhXSwEUehbePd7d1aXKqPzA IKWg== X-Gm-Message-State: ALoCoQk9e+MR6OvTwu0ILajSCuQotUxdjdGpNihCDiwnf1Cmul8A8woIxBXu+Yz66v6VJet4Ekah X-Received: by 10.129.136.5 with SMTP id y5mr26768722ywf.35.1447466081355; Fri, 13 Nov 2015 17:54:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Fri, 13 Nov 2015 17:54:21 -0800 (PST) In-Reply-To: <20151113211015.AE1FF3CA1678@rock.dv.isc.org> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> <20151113211015.AE1FF3CA1678@rock.dv.isc.org> From: Lorenzo Colitti Date: Sat, 14 Nov 2015 10:54:21 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a114effba9b01ba05247675f7 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 14 Nov 2015 01:54:43 -0000 --001a114effba9b01ba05247675f7 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 14, 2015 at 6:10 AM, Mark Andrews wrote: > It adds one more system call > to the default loop when starting a tcp connection. > > socket, fcntl, fcntl, bind, connect, select/poll > ... until you realize that bind() doesn't actually affect routing. --001a114effba9b01ba05247675f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On S= at, Nov 14, 2015 at 6:10 AM, Mark Andrews <marka@isc.org> wrote:=
    It adds one more system call
    to the default loop when starting a tcp connection.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 socket, fcntl, fcntl, bind, connect, select/pol= l

    ... until you realize that bind() doe= sn't actually affect routing.=C2=A0
    --001a114effba9b01ba05247675f7-- From nobody Fri Nov 13 18:40: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 E2EFB1B3784 for ; Fri, 13 Nov 2015 18:40:21 -0800 (PST) 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 dhsb4c1K-EEt for ; Fri, 13 Nov 2015 18:40:20 -0800 (PST) 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 23B651B377A for ; Fri, 13 Nov 2015 18:40:20 -0800 (PST) Received: by vkgy188 with SMTP id y188so2704352vkg.1 for ; Fri, 13 Nov 2015 18:40:19 -0800 (PST) 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=+dGFOq3gGzlE8PS6AdvPTexQlRjP8CzP6vIF5KZUcSs=; b=CY32kB0d6pKMutyKOQhoM7datpsCSD31MlvjOF5AyohBodjLPhD9HgIgnGH+LEekbS gyS4p4NFqk4ukqQuFsLC3zR+n73+efbV1EbCOiFCRM5vab5v2CW7e8X3VOLLX6CbouHo SeU0j6Mf3BDJKbo2z1T51NmC/AerztsxcXYg2ZBi0ouYyptyGc1yYljrZPA0Bb+qLmu+ oG+vj+Q6hbkclDx//PhxAUrlLS2RK1di9/LLP/lg5Q4NbZIdIMH6oXzSPsI0AgmBpMqx 0kDfDikA/uVOFjkVf0j5YZmpWarv704EqKPSF95sf6PyFcWwCI5EBsmz/cphi5GZvD6D NT6Q== X-Received: by 10.31.0.197 with SMTP id 188mr1055057vka.102.1447468819211; Fri, 13 Nov 2015 18:40:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.45.198 with HTTP; Fri, 13 Nov 2015 18:39:49 -0800 (PST) In-Reply-To: <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> From: Mark Smith Date: Sat, 14 Nov 2015 13:39:49 +1100 Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 02:40:22 -0000 On 13 Nov 2015 8:43 AM, "Owen DeLong" wrote: > > > > On Nov 12, 2015, at 12:08 , Mark Smith wrote: > > > > On 13 November 2015 at 05:32, Owen DeLong wrote: > >> > >>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote: > >>> > > >> > >> Please explain exactly what circumstances make it too difficult for an= y company > >> to acquire a /48 PI as I would consider this a brokenness in the relev= ant RIR=E2=80=99s > >> policy and would happily work to resolve the issue. > >> > (d) use whatever string of {32,48,64} bits you want and pretend it=E2=80= =99s > an IPv6 prefix. > That's stealing space and will most certainly happen if there is no proper local and free address space to use instead. (I'd have done that if there weren't site-locals when I first wanted to run up IPv6 at home just to get some experience with it.) > Please explain what benefit (b) offers over (d) in such a case. You=E2=80= =99re going > to end up renumbering when you attach to the internet either way. > > > I think that if (a) was the only choice, it is in effect creating an > > annual tax or license fee on the use of IPv6 technology, because (in > > theory) you wouldn't be able to use IPv6 unless you paid an RIR and > > waited for them to give you your space. Of course, the other choice > > would be that some people would steal space to use instead to build an > > IPv6 network, like the documentation prefix. Absence of a local use > > address space encourages stealing of other address spaces if you don't > > have time to get a proper one or don't have the financial means or > > financial incentive to get some. > > I=E2=80=99m all for providing a lower cost alternative to having a legiti= mate registry > for addresses for smaller users. > Zero cost is what is needed. You can only charge money for magic numbers because of the magic, not the numbers. The numbers themselves are free, because anybody can make them up. The magic you're buying or renting when you get RIR space is: - actively managed global uniqueness (although not absolutely guaranteed, because of the human error factor) - implicit acceptance of routes for that space by networks that carry the DFZ route table The first property is really a requirement and necessity demanded by the second one. If people don't need the magic of implicit acceptance in the DFZ, why should they have to pay for it? That is the unnecessary tax or cost on enabling IPv6 that you're creating by saying people should be required to use RIR space, even if they have no intention of having the corresponding local address space routes in the DFZ. If people later need the magic of implicit acceptance in the DFZ, they can get PA or PI, and most importantly add it to their existing ULA addressed network. Renumbering is not required to add PA/PI, and that is where IPv6 provides a much better alternative than IPv4 - IPv4 demanded an exclusive or between PA/PI address space and RFC1918s, and RFC1918s were perceived to be cheaper and easier for a variety of reasons, including because a 'magic translation box' could be used between RFC1918s and PA/PI needed to reach the Internet. In other words, in IPv4 we're forced into serial address spaces, where as in IPv6 we have the opportunity for multiple parallel ones. > > Humans don't incur costs on themselves unless they see or perceive > > some equivalent benefit. Making something available for "free", in > > this case a local yet globally unique network address space, > > significantly lowers the barrier to IPv6 adoption. If you've bought > > the equipment to build your network, and it comes IPv6 enabled for > > "free", you can then immediately build an IPv6 network using ULA > > spa > Except that ULA isn=E2=80=99t globally unique, it=E2=80=99s just =E2=80= =9Cprobably unique=E2=80=9D for various > relatively high values of =E2=80=9Cprobably=E2=80=9D depending on how you= go about choosing > your ULA prefix. Were ULA globally unique, you=E2=80=99d have the double = edge sword > of: > > 1. It=E2=80=99s good because it=E2=80=99s free PI address sp= ace. It isn't "free PI address space", because it doesn't have the magic that real PI address space has - implicit acceptance by all carriers of the DFZ route table. The only similar properties between PI and ULAs are the (statistical/managed) global uniqueness. > 2. It=E2=80=99s bad because it=E2=80=99s a free end-run arou= nd the RIR policy processes. > Not if you can't successfully get it globally routed. Here's the challenge for you. Show us how easy it is for you to get a ULA of your choosing permanently accepted in all ASes who accept the DFZ route table, at a cost and effort that is lower than using RIR PI space instead. > > If at a later date a ULA addressed network connects to the Internet > > they would add PA or PI space to be able to access external > > destinations, because IPv6 is designed to fully support parallel > > address spaces (i.e., so having ULAs on your network doesn't > > automatically imply using NAT66). > > Except for all the problems previously noted in such installations with v= arious > issues around source address selection, etc. > I've been running ULAs here at home more than 4 years, both with 6to4 IPv6 connectivity, and for the last 4 years native connectivity. I haven't seen any issues, or if there have been any, they've been overcome transparently via such things as Happy Eyeballs. (with the caveat that all my hosts are fundamentally Linux, although various distros - Fedora, Android, Chromecast and Chrome OS.) More recently, anybody who has been running IPv6 on OpenWRT since BarrierBreaker 14.07, released on 30th of September 2014, has had an ULA prefix automatically generated and announced to hosts on the LAN interfaces. Via a few Internet searches, I can't find any reports of issues relating to OpenWRT and automatic ULAs in the last 2 years. Regards, Mark. From nobody Fri Nov 13 18:47: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 E7E2B1B3798 for ; Fri, 13 Nov 2015 18:47:45 -0800 (PST) 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 1EHSPestO13j for ; Fri, 13 Nov 2015 18:47:41 -0800 (PST) Received: from sobre.alvarezp.com (sobre.alvarezp.com [173.230.155.94]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF81B378F for ; Fri, 13 Nov 2015 18:47:41 -0800 (PST) Received: from [IPv6:2806:220:2:4:541f:a6cb:1383:3b51] (unknown [IPv6:2806:220:2:4:541f:a6cb:1383:3b51]) by sobre.alvarezp.com (Postfix) with ESMTPSA id 385CE614E; Fri, 13 Nov 2015 21:47:40 -0500 (EST) To: Philip Homburg References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> From: Octavio Alvarez Message-ID: <5646A0CB.4020406@alvarezp.ods.org> Date: Fri, 13 Nov 2015 18:47:39 -0800 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 14 Nov 2015 02:47:46 -0000 On 13/11/15 11:19, Philip Homburg wrote: >>> I don't think a host should try to figure out which paths work and which >>> don't. >>> >>> Maybe somebody can come up with a simple algorithm that generalises >>> happy-eyeballs and that is compatible with today's host operating systems. >>> But I doubt it. >> >> We tried. It's called shim6. Firewalls break it. > > I'd call shim6 a protocol and not an algorithm. Happy eyeballs is quite > compatible with firewalls, NAT, etc. No problem there. I'm sure happy > eyeballs-like approaches can be tried for the multiple-prefix case. > > The problem I ran into is that by the time my happy eyeballs implementation > did everything I wanted it do, it was way to complex. Adding support for > many source prefixes would just be too much. > > Now, maybe somebody can come up with an approach that doesn't have that > problem. Don't know. > > Mean while, I have something that works with every operating system today. > It may not be perfect. So I'm not terribly motivated to add more host > complexity to solve those edge cases. Can you elaborate on your approach? Thanks. From nobody Fri Nov 13 18:50: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 E8E4D1B379A for ; Fri, 13 Nov 2015 18:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 cFTb3mS3bnIs for ; Fri, 13 Nov 2015 18:50:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B880C1B371B for ; Fri, 13 Nov 2015 18:50:48 -0800 (PST) Received: from [192.168.1.28] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAE2oDgo028375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 18:50:14 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6B3CFE14-22F6-45D2-9D09-47E4DEFD73D6 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Fri, 13 Nov 2015 18:50:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> <20151113211015.AE1FF3CA1678@rock.dv.isc.org> To: Lorenzo Colitti X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 14 Nov 2015 02:50:50 -0000 --Apple-Mail-6B3CFE14-22F6-45D2-9D09-47E4DEFD73D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > On Nov 13, 2015, at 5:54 PM, Lorenzo Colitti wrote: > >> On Sat, Nov 14, 2015 at 6:10 AM, Mark Andrews wrote: >> It adds one more system call >> to the default loop when starting a tcp connection. >> >> socket, fcntl, fcntl, bind, connect, select/poll > > ... until you realize that bind() doesn't actually affect routing. Routing can be source dependent, e.g., policy routing. Joe --Apple-Mail-6B3CFE14-22F6-45D2-9D09-47E4DEFD73D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


    On Nov 13, 2015, at 5:54 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

    On Sat, Nov 14, 2015 at 6:10 AM, Mark Andrews <marka@isc.org> wrote:
    It adds one more system call
    to the default loop when starting a tcp connection.

            socket, fcntl, fcntl, bind, connect, select/poll

    ... until you realize that bind() doesn't actually affect routing. 

    Routing can be source dependent, e.g., policy routing. 

    Joe
    --Apple-Mail-6B3CFE14-22F6-45D2-9D09-47E4DEFD73D6-- From nobody Fri Nov 13 19: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 83A801B37D2 for ; Fri, 13 Nov 2015 19:20:41 -0800 (PST) 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 mhz1SXKsPtsg for ; Fri, 13 Nov 2015 19:20:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 64B6D1B37C3 for ; Fri, 13 Nov 2015 19:20:38 -0800 (PST) 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 tAE3IZlx026041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 19:18:36 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Fri, 13 Nov 2015 19:18:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> To: Mark Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 03:20:41 -0000 >>=20 >> I=E2=80=99m all for providing a lower cost alternative to having a = legitimate registry >> for addresses for smaller users. >>=20 >=20 > Zero cost is what is needed. I think a nominal fee (say US$25/year) wouldn=E2=80=99t represent a = significant barrier. >=20 > You can only charge money for magic numbers because of the magic, not > the numbers. The numbers themselves are free, because anybody can make > them up. >=20 > The magic you're buying or renting when you get RIR space is: >=20 > - actively managed global uniqueness (although not absolutely > guaranteed, because of the human error factor) To the best of my knowledge there are all of 3 instances of = non-uniqueness temporarily resulting from such errors in all of internet history and = all in IPv4 or ASNs. > - implicit acceptance of routes for that space by networks that carry > the DFZ route table Really? I don=E2=80=99t think so. > The first property is really a requirement and necessity demanded by > the second one. Certainly the second cannot function with the first, yes, but the first property is oh so desirable for so many other reasons. > If people don't need the magic of implicit acceptance in the DFZ, why > should they have to pay for it? That is the unnecessary tax or cost on > enabling IPv6 that you're creating by saying people should be required > to use RIR space, even if they have no intention of having the > corresponding local address space routes in the DFZ. If it isn=E2=80=99t connecting to the global internet than it doesn=E2=80=99= t matter what numbers you make up or whether they are unique or how you go about making them up. It=E2=80=99s not stealing space, it=E2=80=99s just using random = numbers that aren=E2=80=99t actually internet addresses because you happen to be running the same protocol on your disconnected network as most networks run on the internet. > If people later need the magic of implicit acceptance in the DFZ, they > can get PA or PI, and most importantly add it to their existing ULA > addressed network. With all the attendant problems that have been repeatedly discussed. > Renumbering is not required to add PA/PI, and that is where IPv6 > provides a much better alternative than IPv4 - IPv4 demanded an > exclusive or between PA/PI address space and RFC1918s, and RFC1918s > were perceived to be cheaper and easier for a variety of reasons, > including because a 'magic translation box' could be used between > RFC1918s and PA/PI needed to reach the Internet. I can put an RFC1918 address and a GUA IPv4 address on the same interface on any modern host as well. This is no different from IPv6. There is no meaningful difference in this regard. ULA is just RFC1918 with more addresses available for stupid host tricks. > In other words, in IPv4 we're forced into serial address spaces, where > as in IPv6 we have the opportunity for multiple parallel ones. This statement is not reality on any modern system. >>> Humans don't incur costs on themselves unless they see or perceive >>> some equivalent benefit. Making something available for "free", in >>> this case a local yet globally unique network address space, >>> significantly lowers the barrier to IPv6 adoption. If you've bought >>> the equipment to build your network, and it comes IPv6 enabled for >>> "free", you can then immediately build an IPv6 network using ULA >>> spa >=20 >> Except that ULA isn=E2=80=99t globally unique, it=E2=80=99s just = =E2=80=9Cprobably unique=E2=80=9D for various >> relatively high values of =E2=80=9Cprobably=E2=80=9D depending on how = you go about choosing >> your ULA prefix. Were ULA globally unique, you=E2=80=99d have the = double edge sword >> of: >>=20 >> 1. It=E2=80=99s good because it=E2=80=99s free PI address = space. >=20 > It isn't "free PI address space", because it doesn't have the magic > that real PI address space has - implicit acceptance by all carriers > of the DFZ route table. Neither does real PI space. This is a figment of your imagination. > The only similar properties between PI and ULAs are the > (statistical/managed) global uniqueness. Not at all true=E2=80=A6 In fact, those are arguably the only differences. They are both prefixes of 128 bit numbers, usually in /48 chunks. They are both intended for numbering interfaces on devices running the = IPv6 protocol. They are both capable of being forward by routers. Both can be described and routes distributed via OSPFv3, ISIS, and = BGPv4. The only real difference between ULA and PI is the convention of not = routing ULA across borders where administrators choose to enforce and/or abide = by said convention and the fact that anyone can make up whatever ULA = address they want, where there is an expectation that PI is coordinated through = an RIR, though there is enough history of hijacking in IPv4 prefixes that I see = no reason to believe this will not occur with IPv6. >> 2. It=E2=80=99s bad because it=E2=80=99s a free end-run = around the RIR policy processes. >=20 > Not if you can't successfully get it globally routed. I assert that this is simply a matter of the right number of = =E2=80=9Cwombats=E2=80=9D placed in the right pockets. (To use a term coined by Jan Zorz). > Here's the challenge for you. Show us how easy it is for you to get a > ULA of your choosing permanently accepted in all ASes who accept the > DFZ route table, at a cost and effort that is lower than using RIR PI > space instead. The cost for the first people to do it will be extraordinarily high. As = it becomes more common practice, the price will drop. >>> If at a later date a ULA addressed network connects to the Internet >>> they would add PA or PI space to be able to access external >>> destinations, because IPv6 is designed to fully support parallel >>> address spaces (i.e., so having ULAs on your network doesn't >>> automatically imply using NAT66). >>=20 >> Except for all the problems previously noted in such installations = with various >> issues around source address selection, etc. >>=20 >=20 > I've been running ULAs here at home more than 4 years, both with 6to4 > IPv6 connectivity, and for the last 4 years native connectivity. I > haven't seen any issues, or if there have been any, they've been > overcome transparently via such things as Happy Eyeballs. (with the > caveat that all my hosts are fundamentally Linux, although various > distros - Fedora, Android, Chromecast and Chrome OS.) As has been repeatedly pointed out to you, the use in your home does not constitute a comprehensive study of all possible or even all likely = environments. I have had multiple issues with source address selection in IPv6 in my = environment, especially on Apple equipment, even without using ULA. ULA would only = make the problem 10x worse. > More recently, anybody who has been running IPv6 on OpenWRT since > BarrierBreaker 14.07, released on 30th of September 2014, has had an > ULA prefix automatically generated and announced to hosts on the LAN > interfaces. Via a few Internet searches, I can't find any reports of > issues relating to OpenWRT and automatic ULAs in the last 2 years. I briefly had a router that did that to my network. That option was = quickly turned off to resolve the myriad problems it created. Subsequently, that router = was abandoned in favor of a router I didn=E2=80=99t have to keep beating = about the head and shoulders to prevent it from damaging the network in unexpected = ways. Owen From nobody Fri Nov 13 21:52: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 677171B3977 for ; Fri, 13 Nov 2015 21:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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_SE=0.35, 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 nQtn2qo4pT12 for ; Fri, 13 Nov 2015 21:52:12 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611B41B3972 for ; Fri, 13 Nov 2015 21:52:11 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8028DA2; Sat, 14 Nov 2015 06:52:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1447480328; bh=QeObwpavW42d3gd7Q4BNM+nBgRlYR5nk6kWKe9/mGFk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=aU7DDpQDopPtoZ+GEKjgCXk0IQN0untuCWAXoeVXI3FjyA6xeXqKwDUJ3HvV4RVXl QFTad29RtFYjaL3qVywAP84Hk1C0z+Ki/nJOiaRVuEdSKH4+SKudK2fxAqozZuoFzP r7JoVc1+9w3UkyxhhQfnYcSVSbPrUorQq3huoFzM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 77657A1; Sat, 14 Nov 2015 06:52:08 +0100 (CET) Date: Sat, 14 Nov 2015 06:52:08 +0100 (CET) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <5646589B.7060703@foobar.org> Message-ID: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 05:52:14 -0000 On Fri, 13 Nov 2015, Nick Hilliard wrote: > On 13/11/2015 13:50, Mikael Abrahamsson wrote: >> If the Internet will have 10x the number of routes it has today in the >> not-so-distant-future, there is a considerable risk that most smaller >> players won't be able to afford to have a full view. > > the dfz is growing linearly at ~50k prefixes/year. On this basis, 10x the > number of prefixes is a very long way away. And you think this is going to continue in the future if we say "PI is the preferred way to multihome and please RIRs, make it as easy as possible for people to do this" ? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Nov 14 03:06: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 4A5581B61C9 for ; Sat, 14 Nov 2015 03:06:14 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -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 wFMoupi1k1AH for ; Sat, 14 Nov 2015 03:06:12 -0800 (PST) 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 EF8351B61C7 for ; Sat, 14 Nov 2015 03:06:10 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZxYeh-0000CkC; Sat, 14 Nov 2015 12:06:03 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> In-reply-to: Your message of "Sat, 14 Nov 2015 06:52:08 +0100 (CET) ." Date: Sat, 14 Nov 2015 12:05:54 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 11:06:14 -0000 In your letter dated Sat, 14 Nov 2015 06:52:08 +0100 (CET) you wrote: >On Fri, 13 Nov 2015, Nick Hilliard wrote: > >> On 13/11/2015 13:50, Mikael Abrahamsson wrote: >>> If the Internet will have 10x the number of routes it has today in the >>> not-so-distant-future, there is a considerable risk that most smaller >>> players won't be able to afford to have a full view. >> >> the dfz is growing linearly at ~50k prefixes/year. On this basis, 10x the >> number of prefixes is a very long way away. > >And you think this is going to continue in the future if we say "PI is the >preferred way to multihome and please RIRs, make it as easy as possible >for people to do this" ? PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't sound like a barrier to obtaining some. Of course, having PI space is useless if your ISP doesn't want to announce it for you. From nobody Sat Nov 14 03:14: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 D4B2C1B6211 for ; Sat, 14 Nov 2015 03:14:16 -0800 (PST) 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 WMsMs-Tz1PZa for ; Sat, 14 Nov 2015 03:14:15 -0800 (PST) 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 0AA461B620F for ; Sat, 14 Nov 2015 03:14:14 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D491B62E00 for ; Sat, 14 Nov 2015 12:14:12 +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 909F060409 for ; Sat, 14 Nov 2015 12:14:12 +0100 (CET) Received: (qmail 52514 invoked by uid 1007); 14 Nov 2015 12:14:12 +0100 Date: Sat, 14 Nov 2015 12:14:12 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20151114111412.GG89490@Space.Net> References: <56453026.3090607@gmail.com> <20151113080508.GB89490@Space.Net> <20151113112141.GN89490@Space.Net> <564633AB.9000509@gmail.com> <20151113211015.AE1FF3CA1678@rock.dv.isc.org> 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 WG" Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?] 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, 14 Nov 2015 11:14:17 -0000 Hi, On Sat, Nov 14, 2015 at 10:54:21AM +0900, Lorenzo Colitti wrote: > On Sat, Nov 14, 2015 at 6:10 AM, Mark Andrews wrote: > > > It adds one more system call > > to the default loop when starting a tcp connection. > > > > socket, fcntl, fcntl, bind, connect, select/poll > > ... until you realize that bind() doesn't actually affect routing. It totally does, at least in the context we're discussing here (dual-/48 style multihoming with src-dependent routing). 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 Sat Nov 14 03:19: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 439C41B624E for ; Sat, 14 Nov 2015 03:19:37 -0800 (PST) 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 eor8aJTREJL1 for ; Sat, 14 Nov 2015 03:19:36 -0800 (PST) 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 403431B624D for ; Sat, 14 Nov 2015 03:19:35 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 16AC562D3E for ; Sat, 14 Nov 2015 12:19:34 +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 CA86E60352 for ; Sat, 14 Nov 2015 12:19:33 +0100 (CET) Received: (qmail 52683 invoked by uid 1007); 14 Nov 2015 12:19:33 +0100 Date: Sat, 14 Nov 2015 12:19:33 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20151114111933.GH89490@Space.Net> References: <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> 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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 11:19:37 -0000 Hi, On Sat, Nov 14, 2015 at 12:05:54PM +0100, Philip Homburg wrote: > PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't sound like > a barrier to obtaining some. Having to deal with that every year is a hassle unless you really want PI - in which case, it is not. It's actually a nicely balanced hurdle. Making it free would encourage everyone and their dog to get a block, whether they need it or not. 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 Sat Nov 14 03:29: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 807E81B62AE for ; Sat, 14 Nov 2015 03:29:45 -0800 (PST) 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 kqCpFhK5bX8d for ; Sat, 14 Nov 2015 03:29:44 -0800 (PST) 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 EEFB41B62AD for ; Sat, 14 Nov 2015 03:29:43 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZxZ1b-0000CgC; Sat, 14 Nov 2015 12:29:43 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> <20151114111933.GH89490@Space.Net> In-reply-to: Your message of "Sat, 14 Nov 2015 12:19:33 +0100 ." <20151114111933.GH89490@Space.Net> Date: Sat, 14 Nov 2015 12:29:38 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 11:29:45 -0000 >On Sat, Nov 14, 2015 at 12:05:54PM +0100, Philip Homburg wrote: >> PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't sound like >> a barrier to obtaining some. > >Having to deal with that every year is a hassle unless you really want >PI - in which case, it is not. It's actually a nicely balanced hurdle. > >Making it free would encourage everyone and their dog to get a block, >whether they need it or not. It struck me that PI in the RIPE region is similar to getting a DNS domain. There is a registry (for PI in the RIPE region that would be the RIPE NCC) and there are registrars (that would be the LIRs in the RIPE region) For a DNS domain, registrars have completely automated process where you pick the name, fill in the nameservers, pay, etc. Usually you can pay for multiple years in advance, so doesn't take too much time. It seems to me that the same model could apply to PI if it would get popular. Though I have to admit, I never bothered to look into the actual procedures for getting PI space. Maybe you have to show up in person in Amsterdam :-) From nobody Sat Nov 14 04:05: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 66B801B6588 for ; Sat, 14 Nov 2015 04:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.111 X-Spam-Level: X-Spam-Status: No, score=-8.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, GB_I_LETTER=-2, 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 N9SrMH1UEEZ5 for ; Sat, 14 Nov 2015 04:05:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDA1B6587 for ; Sat, 14 Nov 2015 04:05:18 -0800 (PST) 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 tAEC4HOG000606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 04:04:17 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Sat, 14 Nov 2015 04:04:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> To: Philip Homburg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 12:05:20 -0000 > On Nov 14, 2015, at 03:05 , Philip Homburg = wrote: >=20 > In your letter dated Sat, 14 Nov 2015 06:52:08 +0100 (CET) you wrote: >> On Fri, 13 Nov 2015, Nick Hilliard wrote: >>=20 >>> On 13/11/2015 13:50, Mikael Abrahamsson wrote: >>>> If the Internet will have 10x the number of routes it has today in = the >>>> not-so-distant-future, there is a considerable risk that most = smaller >>>> players won't be able to afford to have a full view. >>>=20 >>> the dfz is growing linearly at ~50k prefixes/year. On this basis, = 10x the >>> number of prefixes is a very long way away. >>=20 >> And you think this is going to continue in the future if we say "PI = is the=20 >> preferred way to multihome and please RIRs, make it as easy as = possible=20 >> for people to do this" ? >=20 > PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't = sound like > a barrier to obtaining some. >=20 > Of course, having PI space is useless if your ISP doesn't want to = announce > it for you. HE will announce anyone=E2=80=99s PI /48 for free on request if they = have an ASN. Owen From nobody Sat Nov 14 10:10: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 0F6A11A1A1D for ; Sat, 14 Nov 2015 10:10:31 -0800 (PST) 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 o8vimWhBshMi for ; Sat, 14 Nov 2015 10:10:29 -0800 (PST) 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 6FB991A046D for ; Sat, 14 Nov 2015 10:10:29 -0800 (PST) Received: by padhx2 with SMTP id hx2so131607234pad.1 for ; Sat, 14 Nov 2015 10:10:29 -0800 (PST) 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=CZWT/YzwLtGXdZsUJeQBsrFVeGRh/oCVgMrrIPa1kJ8=; b=Bd4G5MtlMOD9zJ/ipxPZ4RGh3RDX88rEYgX8tQZkydSFTvwEOXdcWL89hedWKqwovp FrAlcrJphqrCCsSZ02g0/uGgXQA5GCN6zn2CPmyJlUpw1/mKet4ZOF/11O/kWe2tFBIy bFzQjmUJwNgraHQnZgFD1gZ6EsqREYnPBzsG3I85K6XmgWWd+WyI6CIRnxdeEiNjClOU ELjk4pWGaoV3cLBNUWjARLgEsWbjISbhXIDi4IQgVyBdn80gwBAPgH3u6AO051VoR019 HHOPZQyzjg3Qt3wfg8Aq/aQtR8H5uFR7XlnnWH4cwfVnfTrLWxtJwZDuJSKBg8IDcdoU O2Pw== X-Received: by 10.68.129.133 with SMTP id nw5mr41135536pbb.18.1447524629043; Sat, 14 Nov 2015 10:10:29 -0800 (PST) Received: from ?IPv6:2406:e007:4edd:1:28cc:dc4c:9703:6781? ([2406:e007:4edd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ia3sm27086716pbb.5.2015.11.14.10.10.26 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Nov 2015 10:10:27 -0800 (PST) To: v6ops@ietf.org References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5647790B.6020500@gmail.com> Date: Sun, 15 Nov 2015 07:10: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: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 18:10:31 -0000 On 15/11/2015 01:04, Owen DeLong wrote: >=20 >> On Nov 14, 2015, at 03:05 , Philip Homburg wrote: >> >> In your letter dated Sat, 14 Nov 2015 06:52:08 +0100 (CET) you wrote: >>> On Fri, 13 Nov 2015, Nick Hilliard wrote: >>> >>>> On 13/11/2015 13:50, Mikael Abrahamsson wrote: >>>>> If the Internet will have 10x the number of routes it has today in = the >>>>> not-so-distant-future, there is a considerable risk that most small= er >>>>> players won't be able to afford to have a full view. >>>> >>>> the dfz is growing linearly at ~50k prefixes/year. On this basis, 1= 0x the >>>> number of prefixes is a very long way away. >>> >>> And you think this is going to continue in the future if we say "PI i= s the=20 >>> preferred way to multihome and please RIRs, make it as easy as possib= le=20 >>> for people to do this" ? >> >> PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't soun= d like >> a barrier to obtaining some. >> >> Of course, having PI space is useless if your ISP doesn't want to anno= unce >> it for you. >=20 > HE will announce anyone=E2=80=99s PI /48 for free on request if they ha= ve an ASN. Explain how that works when there are ten million of them. Brian From nobody Sat Nov 14 10:12: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 DB4211A6F28 for ; Sat, 14 Nov 2015 10:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 qn_d6PNwToXW for ; Sat, 14 Nov 2015 10:12:43 -0800 (PST) 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 0D7781A21A0 for ; Sat, 14 Nov 2015 10:12:43 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 30EE362EFF for ; Sat, 14 Nov 2015 19:12:41 +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 EF7A360739 for ; Sat, 14 Nov 2015 19:12:40 +0100 (CET) Received: (qmail 63249 invoked by uid 1007); 14 Nov 2015 19:12:40 +0100 Date: Sat, 14 Nov 2015 19:12:40 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20151114181240.GI89490@Space.Net> References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 18:12:45 -0000 Hi, On Sat, Nov 14, 2015 at 12:36:03AM +0000, Hemant Singh (shemant) wrote: > routeri#clear ipv6 neigh > routeri# > router#ping 2001:db8:3800:800:250:56FF:FEB2:F11D source lo0 > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:db8:3800:800:250:56FF:FEB2:F11D, timeout is 2 seconds: > Packet sent with a source address of 2004::1 > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms > router# This, actually, is a totally meaningless example. I can send packets round the world with any source address I choose, and it has no significance for on-link NS or DAD with the *on-link* address of intermediate network segments. If you look more closely at your box, you'll see that it will not use the 2004::1 source address for ND on the next-hop lan interface. 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 Sat Nov 14 10:14: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 E058A1A8734 for ; Sat, 14 Nov 2015 10:14:06 -0800 (PST) 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 Q8RhYYsObCMi for ; Sat, 14 Nov 2015 10:14:05 -0800 (PST) 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 4528D1A6F8C for ; Sat, 14 Nov 2015 10:14:05 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C505F6099E for ; Sat, 14 Nov 2015 19:14: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 8D28A600FD for ; Sat, 14 Nov 2015 19:14:03 +0100 (CET) Received: (qmail 63292 invoked by uid 1007); 14 Nov 2015 19:14:03 +0100 Date: Sat, 14 Nov 2015 19:14:03 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20151114181403.GJ89490@Space.Net> References: <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> <20151114111933.GH89490@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q32ofrQ8UfzBLMEG" 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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 18:14:07 -0000 --q32ofrQ8UfzBLMEG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 14, 2015 at 12:29:38PM +0100, Philip Homburg wrote: > It struck me that PI in the RIPE region is similar to getting a DNS domai= n. > There is a registry (for PI in the RIPE region that would be the RIPE NCC) > and there are registrars (that would be the LIRs in the RIPE region) >=20 > For a DNS domain, registrars have completely automated process where you > pick the name, fill in the nameservers, pay, etc. Usually you can pay for > multiple years in advance, so doesn't take too much time. >=20 > It seems to me that the same model could apply to PI if it would get=20 > popular. Though I have to admit, I never bothered to look into the=20 > actual procedures for getting PI space. Maybe you have to show up in=20 > person in Amsterdam :-) It is similar to the DNS process. And, as you might have noticed, not every Internet user in the world has their own domain. qed. :) 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 --q32ofrQ8UfzBLMEG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkd5699WwGXkzn/FAQJeUA/9ExD+GTRO1Mijnm30ljrvUaUUwj8VPLlr Kc/a+G2tWikgwKa3y5vuGq3A/7p7Die5SQQhQQQiEoHr0OR+ZQ0jUpyJvfjD6Bys OFgnmywMQy2ohWRQWS9jdV+eFc12LZ8gx8BlAvRfQa2JGPFheEK04nc4CC6/vEME yk5hs2IPhyhmZA2Z44zTJVyvn9f+pWE7h6kYWHF6gP/WH89YxH0gUmpudbYCAKCy CBzoFWIOeGWIoUvLDNRT4Ha1iFa87kGZpF+gmVE+3MFXg0Zv1bLnuuWlMYOdPH1s ZjXmczHdzUauLAZbWXliljnNNb95aoY5c7qh1YRLhaMtjVKCkqWiDgZ+VQ6pyfUj FUrPID6ggsHdCPKyH1yIOMVrP7Tyh3hJegekG7Z/3jdansjJ50Tyqmcy3J3aVxRA p187cJjFytbGLa7kcqK5wWZ4vKF5rJ5Mskp1XMUifEdh7w+eAostgBWIBIbwLx1T Cg0hu3UsxazREM+8OGefMz6Keo25tAhoO7i1Px8bEP0ax5jTwlwNrsbZFx/zs3CG +xiTct+QW6NkEmLBGbs7T2reW4tktMaxNzc4fFm+AwtD7VwHAknpFC5sSy/N8lZq lQMki9BkTlj7RfqJmxocZICh/1AhvJeAvbv/1EayK8SgxJeQASl/INmRSnP0kX7D teVswKNzX/s= =SkBn -----END PGP SIGNATURE----- --q32ofrQ8UfzBLMEG-- From nobody Sat Nov 14 10:15: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 208931A89C6 for ; Sat, 14 Nov 2015 10:15:41 -0800 (PST) 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 HtVKNa3ZgaLO for ; Sat, 14 Nov 2015 10:15:40 -0800 (PST) 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 2F2D81A899E for ; Sat, 14 Nov 2015 10:15:39 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5240560AA4 for ; Sat, 14 Nov 2015 19:15:38 +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 13E696099E for ; Sat, 14 Nov 2015 19:15:38 +0100 (CET) Received: (qmail 63380 invoked by uid 1007); 14 Nov 2015 19:15:38 +0100 Date: Sat, 14 Nov 2015 19:15:38 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20151114181538.GK89490@Space.Net> References: <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> 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] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 18:15:41 -0000 Hi, On Sat, Nov 14, 2015 at 04:04:17AM -0800, Owen DeLong wrote: > HE will announce anyone???s PI /48 for free on request if they have an ASN. So, where can I order a DSL circuit to my home from HE, for competitive pricing, with the /48 added in for free? See how absurd that argument is? PI that I have to get someone to tunnel to me over IPv4 (which I might not even have anymore) is not exactly useful. 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 Sat Nov 14 10:48: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 E894F1ACED2 for ; Sat, 14 Nov 2015 10:48:09 -0800 (PST) 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 PMKUx1eQrN34 for ; Sat, 14 Nov 2015 10:48:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811571ACEBD for ; Sat, 14 Nov 2015 10:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1658; q=dns/txt; s=iport; t=1447526888; x=1448736488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6LLSeXcqzvLvs0d/qWew8vIvbQB7qKlgN1kA6c7FtJk=; b=Uf8MIgALeYNc+Uy376PI17viXDG4nBoty5RyAnrARPV7phQ8tUN35DWo 0hbPaWSfOdzDVYXI4WV6DJuepRxGtoMOCQGMrRjwirsNYEdVf/xKbEmWn fg8a9TO8Ed+SeHP+GSsPrMhT9iCX2ZYy4/TMUFn8rj3axd57rpCvtR59n E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCKgEdW/49dJa1egzuBQga+RwENg?= =?us-ascii?q?WSGEAKBKzgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQOBQi?= =?us-ascii?q?IJro+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGItSiTkFlkgBjR+BYpZ4g3EBHwEBQ?= =?us-ascii?q?oIRHYFWcoREgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,294,1444694400"; d="scan'208";a="49665383" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 14 Nov 2015 18:48:07 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAEIm7lB012999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Nov 2015 18:48:07 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 Nov 2015 13:48:06 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sat, 14 Nov 2015 13:48:06 -0500 From: "Hemant Singh (shemant)" To: Gert Doering Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA///AA4CAAE9HQIAA4EYAgABMFPA= Date: Sat, 14 Nov 2015 18:48:06 +0000 Message-ID: <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> In-Reply-To: <20151114181240.GI89490@Space.Net> 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.82.243.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 18:48:10 -0000 -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Saturday, November 14, 2015 1:13 PM To: Hemant Singh (shemant) Cc: Owen DeLong; v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] >This, actually, is a totally meaningless example. Not it's not since Owen ask that the lo interface is not in the same subnet= at the outbound interface, so how is data forwarding working with ND if an= address resolution is needed? I proved data forwarding works. I sure cou= ld have added to the example a log of the ND address resolution but any ND = log is very copious due to NUD and thus I skipped the ND log.=20 >I can send packets round the world with any source address I choose, and i= t has no significance for on-link NS or DAD with the *on-link* address of i= ntermediate network segments. >If you look more closely at your box, you'll see that it will not use the >2004::1 source address for ND on the next-hop lan interface. Correct. This is what my point to Owen was. The lo interface IPv6 addre= ss can be used to source packets out the router, and if the outbound interf= ace has an incomplete or nonexistent entry in the neighbor cache, the outbo= und interfaces issues a ND address resolution and if the address resolution= is completed, the packet is forwarded out. I did issue "clear ipv6 neigh= " on my router to clear the neighbor cache to force a ND address resolution= . The ND address resolution NS can use the link-local address or the globa= l address of the outbound interface for sourcing the NS. Hemant From nobody Sat Nov 14 10:50: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 8FD331ACEDF for ; Sat, 14 Nov 2015 10:50:56 -0800 (PST) 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 cNzEAgeZ6c_d for ; Sat, 14 Nov 2015 10:50:54 -0800 (PST) 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 60EE51ACED9 for ; Sat, 14 Nov 2015 10:50:54 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B0A4360409 for ; Sat, 14 Nov 2015 19:50:52 +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 520EA60A87 for ; Sat, 14 Nov 2015 19:50:52 +0100 (CET) Received: (qmail 64131 invoked by uid 1007); 14 Nov 2015 19:50:52 +0100 Date: Sat, 14 Nov 2015 19:50:52 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20151114185052.GM89490@Space.Net> References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jobRqqe4Hp8P9iE7" Content-Disposition: inline In-Reply-To: <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 18:50:56 -0000 --jobRqqe4Hp8P9iE7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 14, 2015 at 06:48:06PM +0000, Hemant Singh (shemant) wrote: > >If you look more closely at your box, you'll see that it will not use the > >2004::1 source address for ND on the next-hop lan interface. >=20 > Correct. This is what my point to Owen was. The lo interface IPv6=20 > address can be used to source packets out the router,=20 Right... > and if the outbound interface has an incomplete or nonexistent entry=20 > in the neighbor cache, the outbound interfaces issues a ND address=20 > resolution and if the address resolution is completed, the packet is=20 > forwarded out. =20 Also right. But: the outbound interface will NOT use the lo0 source address for the ND activity. It will use the *interface* IP for ND, and the link-local one for that. There is no difference for the router between "send out a packet with a=20 lo0 source to lan" and "send out a packet sourced by someone else to lan", as far as ND activity on the LAN activity is concerned. Surely you're not asking for a router to do DAD for every single IPv6 address that could be coming *through* that router? > I did issue "clear ipv6 neigh" on my router to clear the neighbor cache t= o force a ND address resolution. The ND address resolution NS can use the = link-local address or the global address of the outbound interface for sour= cing the NS. "the global address of the outbound interface" is NOT the lo0 source addres= s. 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 --jobRqqe4Hp8P9iE7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkeCjN9WwGXkzn/FAQKcCQ//X2oZnuV+mRSg6UBMcqovM4IVMcMLcy6m 3YzNjesg62dJmPiizTmATQ+9qJ9GU7UPhrBrAY0jdgEMWaeLQHcgbjFl4zsGgWXt +lD0nivTDXGZWYWkT+Lpm1nn/Nf0zNDZfkybdpd5a4goypTb1kmJExSmrUWZESdB LHynUr2bjuux325UxotzhMNx7apQATZeouQMTZFWxuirzPfWBWYBOT9ZE0QkFuSD xxrgK2WpnO65dL6Yaj+NGdmGEueoMKC9B+ZMuvulElVImkViI5rWt7L0MlkuDZ0x fnBlL8NzyxRurjWhyF6Qs/pOjm24I5om2wVLs/nWXUt3H7fDw0twK+2eKg0+/4+m o52JSBd1oVkfuXG6cfJPcYob2LIrB9QSkLSsjIrt8lVvnj6RX/IkX/wMdy+OKQ86 pTjtNaLot1mj2c5pArgItjUm3gHYBADJElnnvQveGwaaYixivpNS2A5BnBOsUGW3 zl4VmZ+lgytWbM67eiDQCe3Zr6X+4FIHywI+cc/vO54MF0dTXY6Sq4+CtbBkz4Xw h50f2nWiQE1dKqNi7mhjLNaoY08dHfo0+O8D2o8BgLskWBAjE6ceLi6bNh/Wb4zu zAiQlSs0wnprZZiuAnrgUbc0zecBERqbFTgWSJjRBG6AMfhP4/UofrEKsL2+9rKe 5dg75R7LJ5s= =0oZO -----END PGP SIGNATURE----- --jobRqqe4Hp8P9iE7-- From nobody Sat Nov 14 11:03: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 E37D11AD059 for ; Sat, 14 Nov 2015 11:03:02 -0800 (PST) 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 4HuZVA-2Qvje for ; Sat, 14 Nov 2015 11:03:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B205F1AD04E for ; Sat, 14 Nov 2015 11:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1521; q=dns/txt; s=iport; t=1447527781; x=1448737381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LDU1cM8RCa2VrHKdQrNFY2TpmIBDyJok9ggFhAkewFY=; b=VUNUTWvHmsqUZVxJ/wNEsIuZ3bYJP+E7XUxqUr2T7+b1LstfEgEFOVe4 T2nLhbRT7k2ANE8FQKodEso32w5knXSijyuAohJOap6FaMYipPUN+9/yb iXIE4AEcuCgawBX71iXbQvaZt5HhqBcm/WC8/pVVELAB2A5GoqkYX6kQH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBQhEdW/4YNJK1egzuBQga+RwENg?= =?us-ascii?q?WSGEAKBKzgUAQEBAQEBAYEKhDQBAQEDATo/DAQCAQgRBAEBHwkHMhQJCAIEDgU?= =?us-ascii?q?IiB4Itn0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYi1KEKhEBhH0FlkgBjR+BYoRAk?= =?us-ascii?q?jiDcQEfAQFCghEdgVZyhAo6gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,294,1444694400"; d="scan'208";a="50551940" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2015 19:03:00 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tAEJ305r021258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Nov 2015 19:03:00 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 Nov 2015 14:02:59 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sat, 14 Nov 2015 14:03:00 -0500 From: "Hemant Singh (shemant)" To: Gert Doering Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA///AA4CAAE9HQIAA4EYAgABMFPD//76YAIAAU2XA Date: Sat, 14 Nov 2015 19:03:00 +0000 Message-ID: <421a65641cb64b45abd75a911a877b0f@XCH-RTP-005.cisco.com> References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> <20151114185052.GM89490@Space.Net> In-Reply-To: <20151114185052.GM89490@Space.Net> 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.82.243.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 19:03:03 -0000 -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Saturday, November 14, 2015 1:51 PM To: Hemant Singh (shemant) Cc: Gert Doering; Owen DeLong; v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] >But: the outbound interface will NOT use the lo0 source address for the ND= activity. It will use the *interface* IP for ND, and the link-local one f= or that. I already said that in my previous email. >Surely you're not asking for a router to do DAD for every single IPv6 addr= ess that could be coming *through* that router? No. A router forwards packets and if the router egress interfaces fails = L2-destination lookup, the interface issues a L2 address resolution. Note= , however, once a source IPv6 address of a lo interface is active to send d= ata and the downstream LAN segment somehow has a dup, the dup issue cannot = be fixed unless the router support ND Proxy which can respond. >> I did issue "clear ipv6 neigh" on my router to clear the neighbor cache = to force a ND address resolution. The ND address resolution NS can use the= link-local address or the global address of the outbound interface for sou= rcing the NS. >"the global address of the outbound interface" is NOT the lo0 source addre= ss. Right - what is your point? Please also see rfc5942 and section 6. No sou= rce IPv6 address in a ND message can be used to make on on-link determinati= on. Hemant From nobody Sat Nov 14 11:27: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 94A4A1AD365 for ; Sat, 14 Nov 2015 11:27:46 -0800 (PST) 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 s15450tnV_P1 for ; Sat, 14 Nov 2015 11:27:44 -0800 (PST) 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 795EC1AD362 for ; Sat, 14 Nov 2015 11:27:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 155D262EFF for ; Sat, 14 Nov 2015 20:27:41 +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 BB67260736 for ; Sat, 14 Nov 2015 20:27:40 +0100 (CET) Received: (qmail 65131 invoked by uid 1007); 14 Nov 2015 20:27:40 +0100 Date: Sat, 14 Nov 2015 20:27:40 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20151114192740.GN89490@Space.Net> References: <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> <20151114185052.GM89490@Space.Net> <288282e703ee45d1940da65afb49e2c8@XCH-RTP-005.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dZflLWwKqQHwno8z" Content-Disposition: inline In-Reply-To: <288282e703ee45d1940da65afb49e2c8@XCH-RTP-005.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 14 Nov 2015 19:27:46 -0000 --dZflLWwKqQHwno8z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 14, 2015 at 07:14:28PM +0000, Hemant Singh (shemant) wrote: > I will be out for next few hours. I will reply to any mails after that. = I don't have any issue to disable DAD for a lo interface. Jinmei wants = due diligence because rfc4862 is being changed and the 6man WG has to take = a look. The draft is not just a v6ops issue any more. I also have anothe= r issue in that if DAD is disabled, what else makes sense to disable on the= lo interface so that the interface has even more reduced processing to dea= l with.=20 You do not need to disable DAD on lo. Do it all you want. But don't do DAD for interface A address on interface B. This is the point everybody has been making. So, if you have an address on lo, there is no reason to do DAD for that on eth0, eth1, pos3/4, or anything else in your box - as you wouldn't do DAD for the eth0 address on eth1. Unrelated interfaces. And on lo0, there is no other party to conflict with, so do DAD if you=20 want, or do not do DAD. Nobody cares. 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 --dZflLWwKqQHwno8z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVkeLLN9WwGXkzn/FAQIa5BAAimz7Bjbm6yT4xJXNQ4gH5kv/og3VCLwr i5ksjOjwKOy9Me2X/ttQFwrgr+jdBoaH83lqREwDmE4exQREcbMb2pv9EUT/jd+F NmejVID9i7ANGR1BSLLNb+s6Fu86IKnZYmLrwjr/7nLNzlPdZNzQ6quklmnx6HKc 1g+0Z23CtAsoh/eQ7vtsVgqDSqRX4kfcInnRPiKm69tin9KGSs10fxBUQy0RxR/L zWb8Id5TQG0L8P50uzvxA3fSj2j72wFjtbePfPdGSDAOSpcguSOSmL3s+MF+5cGF Zg8/q0ZR7DA1cU6+zP9iTJGeJW8R2ecluAj7x1YQqxEY7+TQuCJV4bEsOEL28Eaa b7b333FMyT36WH1zRC3rZ0WZGRXlptJIYSxglbSIkbuYXpdbTxmWX3Nioxy6BQIh 74el7XDAbsBXECuONKIygk+IACjhROhIfkGwGHPGejGLVrkCsIW3Vjc+3yTMzibP 7N4PkAPy8K2x/KBSSBUlniOpYvdNeCyOvGhSy3tucCWIU2Zd9ch870hsrg4gZG7u 8aZWcabrmFlRvdnHylS1N7dLCehlXtt8WSqdp2baHQrWQ9kwtOWLt3PsOsgInYz/ x4/2wcZ5jPgjlNBP/+t7sWjSkcq8PLmlRyI/GtnRbytYLGgnMDOKAGUB4FaVnO/n MGptvr8ChtA= =kVlt -----END PGP SIGNATURE----- --dZflLWwKqQHwno8z-- From nobody Sat Nov 14 11:48: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 EE4BC1B2A63 for ; Sat, 14 Nov 2015 11:48:16 -0800 (PST) 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 Yoa8XARgGDFu for ; Sat, 14 Nov 2015 11:48:15 -0800 (PST) Received: from sobre.alvarezp.com (sobre.alvarezp.com [IPv6:2600:3c01::f03c:91ff:fe96:8fec]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3B1B2A4E for ; Sat, 14 Nov 2015 11:48:15 -0800 (PST) Received: from [IPv6:2001:470:d:872:e2ca:94ff:fe6c:f55e] (unknown [IPv6:2001:470:d:872:e2ca:94ff:fe6c:f55e]) by sobre.alvarezp.com (Postfix) with ESMTPSA id 921256151; Sat, 14 Nov 2015 14:48:15 -0500 (EST) To: Philip Homburg References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> From: Octavio Alvarez Message-ID: <56478FFF.1060708@alvarezp.ods.org> Date: Sat, 14 Nov 2015 11:48:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/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 Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 14 Nov 2015 19:48:17 -0000 On 11/14/2015 03:05 AM, Philip Homburg wrote: > > PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't sound like > a barrier to obtaining some. Unfortunately that is not the same in the LACNIC region. Assignment is 2,500 USD + 600 USD yearly. This doesn't consider the ASN. It is definitely for enterprises and large organizations only. Best regards. From nobody Sat Nov 14 16:28: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 5BE051B2E8C for ; Sat, 14 Nov 2015 16:28:22 -0800 (PST) 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 1d2bNGb79eGL for ; Sat, 14 Nov 2015 16:28:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20231B2E8B for ; Sat, 14 Nov 2015 16:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1711; q=dns/txt; s=iport; t=1447547300; x=1448756900; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p5Hdjs7vTfykBqKn26WXyLuEXXLyyVaFpdLjFIU4Ra0=; b=YtNK/klYV+R5kxpzZL1jsmCVqFZD8LPI586/HUNO4st+vD/UvW71PhFc CDSJOaP0VCk+SOemOZs6EqIvk0ZQs04DAXAWvLhyMdEOlWjRF02BcYYi9 Xwl4uFXhujdvMfz0Wb+uuc+5wJhZj+ha0SakVVa247/r5hjv9K/2itxMc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgB00EdW/5pdJa1egzuBQga+RQENg?= =?us-ascii?q?WSGEAKBJzgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEBHgkHMhQJCAIEDgU?= =?us-ascii?q?IiCa2bQEBAQEBAQEBAQEBAQEBAQEBAQEBARiLUok5BZJng2EBjR+BYpZ4g3EBH?= =?us-ascii?q?wEBQoQEcoREgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,295,1444694400"; d="scan'208";a="44903635" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 15 Nov 2015 00:28:19 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tAF0SJ84014501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 00:28:19 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 Nov 2015 19:28:18 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sat, 14 Nov 2015 19:28:18 -0500 From: "Hemant Singh (shemant)" To: Gert Doering Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA///AA4CAAE9HQIAA4EYAgABMFPD//76YAIAATkKg//+8BgD////gEA== Date: Sun, 15 Nov 2015 00:28:18 +0000 Message-ID: References: <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> <20151114185052.GM89490@Space.Net> <288282e703ee45d1940da65afb49e2c8@XCH-RTP-005.cisco.com> <20151114192740.GN89490@Space.Net> In-Reply-To: <20151114192740.GN89490@Space.Net> 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.82.243.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 15 Nov 2015 00:28:22 -0000 Agreed. Hemant -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Saturday, November 14, 2015 2:28 PM To: Hemant Singh (shemant) Cc: Gert Doering; v6ops@ietf.org Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] Hi, On Sat, Nov 14, 2015 at 07:14:28PM +0000, Hemant Singh (shemant) wrote: > I will be out for next few hours. I will reply to any mails after that. = I don't have any issue to disable DAD for a lo interface. Jinmei wants = due diligence because rfc4862 is being changed and the 6man WG has to take = a look. The draft is not just a v6ops issue any more. I also have anothe= r issue in that if DAD is disabled, what else makes sense to disable on the= lo interface so that the interface has even more reduced processing to dea= l with.=20 You do not need to disable DAD on lo. Do it all you want. But don't do DAD for interface A address on interface B. This is the point= everybody has been making. So, if you have an address on lo, there is no reason to do DAD for that on = eth0, eth1, pos3/4, or anything else in your box - as you wouldn't do DAD f= or the eth0 address on eth1. Unrelated interfaces. And on lo0, there is no other party to conflict with, so do DAD if you want= , or do not do DAD. Nobody cares. 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 Sat Nov 14 16:54: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 8E90F1B2EED for ; Sat, 14 Nov 2015 16:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 fZZfVoMUnux3 for ; Sat, 14 Nov 2015 16:54:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E51B2EEB for ; Sat, 14 Nov 2015 16:54:18 -0800 (PST) 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 tAF0qDL3013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 16:52:13 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_7485BB55-F46A-4EA6-AC78-E37E97933391" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <5647790B.6020500@gmail.com> Date: Sat, 14 Nov 2015 16:52:12 -0800 Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> <5647790B.6020500@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 15 Nov 2015 00:54:20 -0000 --Apple-Mail=_7485BB55-F46A-4EA6-AC78-E37E97933391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 14, 2015, at 10:10 , Brian E Carpenter = wrote: >=20 > On 15/11/2015 01:04, Owen DeLong wrote: >>=20 >>> On Nov 14, 2015, at 03:05 , Philip Homburg = wrote: >>>=20 >>> In your letter dated Sat, 14 Nov 2015 06:52:08 +0100 (CET) you = wrote: >>>> On Fri, 13 Nov 2015, Nick Hilliard wrote: >>>>=20 >>>>> On 13/11/2015 13:50, Mikael Abrahamsson wrote: >>>>>> If the Internet will have 10x the number of routes it has today = in the >>>>>> not-so-distant-future, there is a considerable risk that most = smaller >>>>>> players won't be able to afford to have a full view. >>>>>=20 >>>>> the dfz is growing linearly at ~50k prefixes/year. On this basis, = 10x the >>>>> number of prefixes is a very long way away. >>>>=20 >>>> And you think this is going to continue in the future if we say "PI = is the=20 >>>> preferred way to multihome and please RIRs, make it as easy as = possible=20 >>>> for people to do this" ? >>>=20 >>> PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't = sound like >>> a barrier to obtaining some. >>>=20 >>> Of course, having PI space is useless if your ISP doesn't want to = announce >>> it for you. >>=20 >> HE will announce anyone=E2=80=99s PI /48 for free on request if they = have an ASN. >=20 > Explain how that works when there are ten million of them. I don=E2=80=99t know, but I don=E2=80=99t think that=E2=80=99s a = realistic number in any sort of immediate timeframe. My guess would be that it will take quite some time before we face that = issue and that by then if we haven=E2=80=99t figured it out, we=E2=80=99re going to have some = pretty big problems regardless of whether or not SMEs are using PI /48s. Owen --Apple-Mail=_7485BB55-F46A-4EA6-AC78-E37E97933391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 14, 2015, at 10:10 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    On 15/11/2015 01:04, Owen DeLong = wrote:

    On = Nov 14, 2015, at 03:05 , Philip Homburg <pch-v6ops-3@u-1.phicoh.com> wrote:

    In your letter dated Sat, 14 Nov 2015 06:52:08 +0100 (CET) = you wrote:
    On Fri, 13 = Nov 2015, Nick Hilliard wrote:

    On 13/11/2015 13:50, Mikael Abrahamsson = wrote:
    If the = Internet will have 10x the number of routes it has today in the
    not-so-distant-future, there is a considerable risk that most = smaller
    players won't be able to afford to have a full = view.

    the dfz is growing = linearly at ~50k prefixes/year.  On this basis, 10x the
    number of prefixes is a very long way away.

    And you think this is going to = continue in the future if we say "PI is the 
    preferred = way to multihome and please RIRs, make it as easy as possible 
    for people = to do this" ?

    PI space is EUR = 50 per year in the RIPE region, isn't it? Doesn't sound like
    a barrier to obtaining some.

    Of = course, having PI space is useless if your ISP doesn't want to = announce
    it for you.

    HE will announce anyone=E2=80=99s PI /48 for free on request = if they have an ASN.

    Explain how that works when there are ten = million of them.

    I don=E2=80=99= t know, but I don=E2=80=99t think that=E2=80=99s a realistic number in = any sort of immediate timeframe.

    My guess would be that it will take quite some time before we = face that issue and that by then
    if we haven=E2=80=99= t figured it out, we=E2=80=99re going to have some pretty big problems = regardless of whether
    or not SMEs are using PI = /48s.

    Owen

    = --Apple-Mail=_7485BB55-F46A-4EA6-AC78-E37E97933391-- From nobody Sat Nov 14 16:55: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 55AE51B2EF2 for ; Sat, 14 Nov 2015 16:55:24 -0800 (PST) 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 tjeZ1SlOoEUy for ; Sat, 14 Nov 2015 16:55:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE211B2EEE for ; Sat, 14 Nov 2015 16:55:23 -0800 (PST) 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 tAF0sLZA013492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 16:54:21 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <20151114181538.GK89490@Space.Net> Date: Sat, 14 Nov 2015 16:54:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9483F70D-E0E0-47FF-9045-D72268D52811@delong.com> References: <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> <20151114181538.GK89490@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 15 Nov 2015 00:55:24 -0000 > On Nov 14, 2015, at 10:15 , Gert Doering wrote: >=20 > Hi, >=20 > On Sat, Nov 14, 2015 at 04:04:17AM -0800, Owen DeLong wrote: >> HE will announce anyone???s PI /48 for free on request if they have = an ASN. >=20 > So, where can I order a DSL circuit to my home from HE, for = competitive > pricing, with the /48 added in for free? You can use any DSL circuit you want. HE=E2=80=99s stuff operates over a = tunnel. >=20 > See how absurd that argument is? PI that I have to get someone to = tunnel > to me over IPv4 (which I might not even have anymore) is not exactly = useful. I don=E2=80=99t know whether HE will tunnel it over IPv6 or not. I do = know that there are others who will, though not for free. Owen From nobody Sat Nov 14 16:59: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 6E4391B2F00 for ; Sat, 14 Nov 2015 16:59:40 -0800 (PST) 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 ae-3OZzLOK2L for ; Sat, 14 Nov 2015 16:59:38 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2AD1B2EFF for ; Sat, 14 Nov 2015 16:59:38 -0800 (PST) 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 tAF0vYfK013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 16:57:34 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> Date: Sat, 14 Nov 2015 16:57:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 15 Nov 2015 00:59:40 -0000 > On Nov 14, 2015, at 10:48 , Hemant Singh (shemant) = wrote: >=20 >=20 >=20 > -----Original Message----- > From: Gert Doering [mailto:gert@space.net]=20 > Sent: Saturday, November 14, 2015 1:13 PM > To: Hemant Singh (shemant) > Cc: Owen DeLong; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >=20 >> This, actually, is a totally meaningless example. >=20 > Not it's not since Owen ask that the lo interface is not in the same = subnet at the outbound interface, so how is data forwarding working with = ND if an address resolution is needed? I proved data forwarding works. = I sure could have added to the example a log of the ND address = resolution but any ND log is very copious due to NUD and thus I skipped = the ND log.=20 I didn=E2=80=99t say you couldn=E2=80=99t bridge the LO and External = interfaces=E2=80=A6 I said that short of doing that, having the same = subnet on both interfaces is a misconfiguration. You haven=E2=80=99t proven that the interfaces aren=E2=80=99t bridged = (or effectively so), nor have you proven that they are actually on the = same subnet. Ergo, it is, actually, still a meaningless example. >> I can send packets round the world with any source address I choose, = and it has no significance for on-link NS or DAD with the *on-link* = address of intermediate network segments. >=20 >> If you look more closely at your box, you'll see that it will not use = the >> 2004::1 source address for ND on the next-hop lan interface. >=20 > Correct. This is what my point to Owen was. The lo interface IPv6 = address can be used to source packets out the router, and if the = outbound interface has an incomplete or nonexistent entry in the = neighbor cache, the outbound interfaces issues a ND address resolution = and if the address resolution is completed, the packet is forwarded out. = I did issue "clear ipv6 neigh" on my router to clear the neighbor = cache to force a ND address resolution. The ND address resolution NS = can use the link-local address or the global address of the outbound = interface for sourcing the NS. Sure, but the reply packet either has to get routed on the return = (router has to somehow be a next hop for the LO prefix) or the router = has to be incorrectly answering ND packets for the LO interface received = on a different interface. Owen From nobody Sat Nov 14 17: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 EE8A51B2EDB for ; Sat, 14 Nov 2015 17:02:46 -0800 (PST) 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 7vZQJxxtD5DF for ; Sat, 14 Nov 2015 17:02:45 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A56201A010F for ; Sat, 14 Nov 2015 17:02:45 -0800 (PST) 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 tAF11gRM014004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 17:01:43 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <56478FFF.1060708@alvarezp.ods.org> Date: Sat, 14 Nov 2015 17:01:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <20151112184613.GZ89490@Space.Net> <03C04D1B-86D1-4A5A-A8D3-7508CEC80DE9@delong.com> <20151112194327.GA89490@Space.Net> <95BC3D07-EF27-45A9-A1E0-12F9B43061C7@delong.com> <20151112214819.4EDE63C98D83@rock.dv.isc.org> <0723DCF1-DE0F-4BBB-9673-17686EB823CD@psc.edu> <5645E9D7.4070009@foobar.org> <5646589B.7060703@foobar.org> <56478FFF.1060708@alvarezp.ods.org> To: Octavio Alvarez X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 15 Nov 2015 01:02:47 -0000 > On Nov 14, 2015, at 11:48 , Octavio Alvarez = wrote: >=20 > On 11/14/2015 03:05 AM, Philip Homburg wrote: >>=20 >> PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't = sound like >> a barrier to obtaining some. >=20 > Unfortunately that is not the same in the LACNIC region. Assignment is = 2,500 USD + 600 USD yearly. This doesn't consider the ASN. >=20 > It is definitely for enterprises and large organizations only. Everything internet related seems to cost too much in the LACNIC region. I=E2=80=99m not sure why this problem persists so much, but I do hope it = improves over time. It=E2=80=99s absurd to see companies charging $30, $50, or in some cases = even $100/Mbit when just the other side of the Rio Grande, you can get tens of Gigabits for less than = $0.40/Megabit. Owen From nobody Sat Nov 14 17:21: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 3E2361B2F74 for ; Sat, 14 Nov 2015 17:21:23 -0800 (PST) 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 v4uASPaGM4sN for ; Sat, 14 Nov 2015 17:21:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7861B2F73 for ; Sat, 14 Nov 2015 17:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2016; q=dns/txt; s=iport; t=1447550481; x=1448760081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rInh+8Uu8h/bFY58rHh4mlrrsSdudnThyt3PGxHLQRY=; b=Td8QtXjoHb1acFeGbZZXPAEgKPkrJcB8GvuQgoefhz+/aygTGqIFxJfF MWOQgNa6PoyiN/5JUtg+eLch4mDahZKDokRy2jjWO5BAosrxJgWw8gKo+ G++u1oPZ0KSezlqpkD8rnJSG3MZe3fYkagWagfhjQSgG5cv5guFxfh5oa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCZ3UdW/5NdJa1egzuBQga+RQENg?= =?us-ascii?q?WSGEAIcgQs4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUIiCamcY9+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGHdYFEBZZIA?= =?us-ascii?q?Y0fnEsBHwEBQoIRHYFWcoREgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,295,1444694400"; d="scan'208";a="46892145" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2015 01:21:21 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAF1LKoY023780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 01:21:21 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 Nov 2015 20:21:20 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sat, 14 Nov 2015 20:21:20 -0500 From: "Hemant Singh (shemant)" To: Owen DeLong Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA///AA4CAAE9HQIAA4EYAgABMFPCAACUMAIAATzQw Date: Sun, 15 Nov 2015 01:21:20 +0000 Message-ID: References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.243.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 15 Nov 2015 01:21:23 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPd2VuIERlTG9uZyBbbWFpbHRv Om93ZW5AZGVsb25nLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMTQsIDIwMTUgNzo1 OCBQTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiBHZXJ0IERvZXJpbmc7IHY2b3Bz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBEQUQgYWdhaW4gW3dhczogZHJhZnQtaWV0 Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5IGRpc2N1c3Npb25dDQoNCj5JIGRpZG7igJl0 IHNheSB5b3UgY291bGRu4oCZdCBicmlkZ2UgdGhlIExPIGFuZCBFeHRlcm5hbCBpbnRlcmZhY2Vz 4oCmIEkgc2FpZCB0aGF0IHNob3J0IG9mIGRvaW5nIHRoYXQsIGhhdmluZyB0aGUgc2FtZSBzdWJu ZXQgb24gYm90aCBpbnRlcmZhY2VzIGlzIGEgbWlzY29uZmlndXJhdGlvbi4NCg0KPllvdSBoYXZl buKAmXQgcHJvdmVuIHRoYXQgdGhlIGludGVyZmFjZXMgYXJlbuKAmXQgYnJpZGdlZCAob3IgZWZm ZWN0aXZlbHkgc28pLCBub3IgaGF2ZSB5b3UgcHJvdmVuIHRoYXQgdGhleSBhcmUgYWN0dWFsbHkg b24gdGhlIHNhbWUgc3VibmV0LiBFcmdvLCBpdCBpcywgYWN0dWFsbHksIHN0aWxsIGEgbWVhbmlu Z2xlc3MgZXhhbXBsZS4NCg0KQW4gYXBwIGhhcyBkZWNpZGVzIHRvIHVzZSB0aGUgSVB2NiBhZGRy ZXNzIG9mIHRoZSBsbyBpbnRlcmZhY2UgdG8gc291cmNlIHRoZSBhcHAncyBwYWNrZXRzLiAgIFRo aXMgaXMgd2hhdCB0aGUgcGluZyBjb21tYW5kIGluIG15IGV4YW1wbGUgZGVjaWRlcyBzaW5jZSB0 aGUgY29tbWFuZCBpcyBhc2tlZCB0byB1c2UgdGhlIHNvdXJjZSBvZiB0aGUgSUNNUHY2IHBhY2tl dHMgYXMgdGhlIGxvIGludGVyZmFjZSdzIGFkZHJlc3MuICBUaGVuIHVzdWFsIGRhdGEgZm9yd2Fy ZGluZyBvbiB0aGUgcm91dGVyIHRha2VzIG92ZXIuICBSb3V0aW5nIGRlY2lkZXMgZnJvbSB0aGUg cGFja2V0IGRlc3RpbmF0aW9uLCB0aGUgcGFja2V0IGhhcyB0byBlZ3Jlc3Mgb3V0IGFuIG91dGJv dW5kIGludGVyZmFjZSwgc2F5LCBldGgwLiAgIEhvd2V2ZXIsIHdoZW4gdGhlIHBhY2tldCBpcyB0 byBiZSBlZ3Jlc3NlZCBvdXQgZXRoMCwgdGhlIEwyIGRlc3RpbmF0aW9uIGxvb2t1cCBmYWlscy4g IEV0aDAgaXNzdWVzIGEgTkQgYWRkcmVzcyByZXNvbHV0aW9uIHRvIHJlc29sdmUgdGhlIGRlc3Rp bmF0aW9uIHVzZXMgaXRzIG93biBzb3VyY2UgaW50ZXJmYWNlIElQdjYgYWRkcmVzcy4gIEkgZm9y Y2VkIHRoZSBORCBhZGRyZXNzIHJlc29sdXRpb24gYnkgY2xlYXJpbmcgdGhlIElQdjYgbmVpZ2hi b3IgY2FjaGUgb24gdGhlIHJvdXRlci4gICBUaGVuIEkgcHJvdmVkIHRoZSBwYWNrZXQgaXMgZm9y d2FyZGVkLiAgIFRoZXJlIGlzIG5vIGJyaWRnaW5nIGludm9sdmVkIGFuZCBwYWNrZXRzIGFyZSBz b3VyY2VkIGZpbmUgdXNpbmcgdGhlIGxvIGludGVyZmFjZS4NCg0KSGVtYW50DQo= From nobody Sun Nov 15 02:12: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 C58661B2BE1 for ; Sun, 15 Nov 2015 02:12:09 -0800 (PST) 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 5i1Q7ZRg0Q31 for ; Sun, 15 Nov 2015 02:12:08 -0800 (PST) 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 A9A561B2BDF for ; Sun, 15 Nov 2015 02:12:07 -0800 (PST) Received: by vkbs1 with SMTP id s1so13935294vkb.0 for ; Sun, 15 Nov 2015 02:12:06 -0800 (PST) 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=6l+F1sxiiXLZ4lpVMVNYBSoBmzGBLnpoZ3ztsV1LDX8=; b=M3i2Cy46/ZrZTalhuRqe1EM2Fk0g95obqxXV0qfD2WDDMSl167xId0SOSMzT/vAN89 3P89TgVAY7vc8qOXsmxhpF/twJNtoqBfCFV1G1RM3Fi2xQShiVUhKb3JuokIHCa1at1A CKXebAespc0g/chowFgJWrToZjHBjaWEXjlYlrzosMie1UsbiuItxndIYyQGy1aZ3luy /TplqM7lI6j3UGaYjienpgiE4N66mQG+e8ALbPc8WbvG0bhSfGP2SYBbACtikpnetL6Y N8XCuhM2jWP0FWufzIDzJNl1g4W6vB66/pjVwmFCalcZAqNJpNo913ABqmEiUm4cx1M7 UkZw== X-Received: by 10.31.54.209 with SMTP id d200mr7249121vka.133.1447582326781; Sun, 15 Nov 2015 02:12:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.45.198 with HTTP; Sun, 15 Nov 2015 02:11:36 -0800 (PST) In-Reply-To: References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> From: Mark Smith Date: Sun, 15 Nov 2015 21:11:36 +1100 Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 15 Nov 2015 10:12:09 -0000 On 14 Nov 2015 14:19, "Owen DeLong" wrote: > > >> > >> I=E2=80=99m all for providing a lower cost alternative to having a leg= itimate registry > >> for addresses for smaller users. > >> > > > > Zero cost is what is needed. > > I think a nominal fee (say US$25/year) wouldn=E2=80=99t represent a signi= ficant barrier. > It's $25 p.a. that can't be spent on something else. > > > > You can only charge money for magic numbers because of the magic, not > > the numbers. The numbers themselves are free, because anybody can make > > them up. > > > > The magic you're buying or renting when you get RIR space is: > > > > - actively managed global uniqueness (although not absolutely > > guaranteed, because of the human error factor) > > To the best of my knowledge there are all of 3 instances of non-uniquenes= s > temporarily resulting from such errors in all of internet history and all= in IPv4 > or ASNs. > > - implicit acceptance of routes for that space by networks that carry > > the DFZ route table > > Really? I don=E2=80=99t think so. > Why not? > > The first property is really a requirement and necessity demanded by > > the second one. > > Certainly the second cannot function with the first, yes, but the first > property is oh so desirable for so many other reasons. > I agree, which is why I think ULAs are much better than site-locals. > > If people don't need the magic of implicit acceptance in the DFZ, why > > should they have to pay for it? That is the unnecessary tax or cost on > > enabling IPv6 that you're creating by saying people should be required > > to use RIR space, even if they have no intention of having the > > corresponding local address space routes in the DFZ. > > If it isn=E2=80=99t connecting to the global internet than it doesn=E2=80= =99t matter what numbers > you make up or whether they are unique or how you go about making them > up. It=E2=80=99s not stealing space, it=E2=80=99s just using random numbe= rs that aren=E2=80=99t actually > internet addresses because you happen to be running the same protocol on > your disconnected network as most networks run on the internet. > > > If people later need the magic of implicit acceptance in the DFZ, they > > can get PA or PI, and most importantly add it to their existing ULA > > addressed network. > > With all the attendant problems that have been repeatedly discussed. > Can you enumerate them for me please? > > Renumbering is not required to add PA/PI, and that is where IPv6 > > provides a much better alternative than IPv4 - IPv4 demanded an > > exclusive or between PA/PI address space and RFC1918s, and RFC1918s > > were perceived to be cheaper and easier for a variety of reasons, > > including because a 'magic translation box' could be used between > > RFC1918s and PA/PI needed to reach the Internet. > > I can put an RFC1918 address and a GUA IPv4 address on the same > interface on any modern host as well. This is no different from IPv6. > *You* can put two addresses on a interface. DHCPv4 can't, and the protocol stack treats the addresses/subnets as though they were assigned to different interfaces/links. > There is no meaningful difference in this regard. ULA is just RFC1918 > with more addresses available for stupid host tricks. > > > In other words, in IPv4 we're forced into serial address spaces, where > > as in IPv6 we have the opportunity for multiple parallel ones. > > This statement is not reality on any modern system. > See above. > >>> Humans don't incur costs on themselves unless they see or perceive > >>> some equivalent benefit. Making something available for "free", in > >>> this case a local yet globally unique network address space, > >>> significantly lowers the barrier to IPv6 adoption. If you've bought > >>> the equipment to build your network, and it comes IPv6 enabled for > >>> "free", you can then immediately build an IPv6 network using ULA > >>> spa > > > >> Except that ULA isn=E2=80=99t globally unique, it=E2=80=99s just =E2= =80=9Cprobably unique=E2=80=9D for various > >> relatively high values of =E2=80=9Cprobably=E2=80=9D depending on how = you go about choosing > >> your ULA prefix. Were ULA globally unique, you=E2=80=99d have the doub= le edge sword > >> of: > >> > >> 1. It=E2=80=99s good because it=E2=80=99s free PI address = space. > > > > It isn't "free PI address space", because it doesn't have the magic > > that real PI address space has - implicit acceptance by all carriers > > of the DFZ route table. > > Neither does real PI space. This is a figment of your imagination. > "Implicit" is a form of the word "implied". Implied doesn't guarantee they will be accepted by all networks carrying DFZs. It means of all of the IPv6 address space, PI is most likely to be accepted by networks carrying DFZ, because most people who carry DFZ routes have a default accept policy, and only drop a small subset of routes (their own PI/PA etc.) > > The only similar properties between PI and ULAs are the > > (statistical/managed) global uniqueness. > > Not at all true=E2=80=A6 > > In fact, those are arguably the only differences. > > They are both prefixes of 128 bit numbers, usually in /48 chunks. > They are both intended for numbering interfaces on devices running the IP= v6 protocol. > They are both capable of being forward by routers. > Both can be described and routes distributed via OSPFv3, ISIS, and BGPv4. > > The only real difference between ULA and PI is the convention of not rout= ing > ULA across borders where administrators choose to enforce and/or abide by > said convention and the fact that anyone can make up whatever ULA address > they want, where there is an expectation that PI is coordinated through a= n RIR, > though there is enough history of hijacking in IPv4 prefixes that I see n= o reason > to believe this will not occur with IPv6. > > >> 2. It=E2=80=99s bad because it=E2=80=99s a free end-run ar= ound the RIR policy processes. > > > > Not if you can't successfully get it globally routed. > > I assert that this is simply a matter of the right number of =E2=80=9Cwom= bats=E2=80=9D placed > in the right pockets. (To use a term coined by Jan Zorz). > And it would be a terrible way to spend your "wombats". > > Here's the challenge for you. Show us how easy it is for you to get a > > ULA of your choosing permanently accepted in all ASes who accept the > > DFZ route table, at a cost and effort that is lower than using RIR PI > > space instead. > > The cost for the first people to do it will be extraordinarily high. Right. That creates a massive incentive to use the much cheaper RIR PI space to more easily and quickly achieve the same goal. > As it becomes > more common practice, the price will drop. > > >>> If at a later date a ULA addressed network connects to the Internet > >>> they would add PA or PI space to be able to access external > >>> destinations, because IPv6 is designed to fully support parallel > >>> address spaces (i.e., so having ULAs on your network doesn't > >>> automatically imply using NAT66). > >> > >> Except for all the problems previously noted in such installations wit= h various > >> issues around source address selection, etc. > >> > > > > I've been running ULAs here at home more than 4 years, both with 6to4 > > IPv6 connectivity, and for the last 4 years native connectivity. I > > haven't seen any issues, or if there have been any, they've been > > overcome transparently via such things as Happy Eyeballs. (with the > > caveat that all my hosts are fundamentally Linux, although various > > distros - Fedora, Android, Chromecast and Chrome OS.) > > As has been repeatedly pointed out to you, the use in your home does not > constitute a comprehensive study of all possible or even all likely envir= onments. I never claimed it was. It is operational experience with ULAs in one type of environment, and it is a piece of empirical evidence that seems to disprove your assertions that ULAs will only cause trouble. > I have had multiple issues with source address selection in IPv6 in my en= vironment, > especially on Apple equipment, even without using ULA. ULA would only mak= e > the problem 10x worse. > > > More recently, anybody who has been running IPv6 on OpenWRT since > > BarrierBreaker 14.07, released on 30th of September 2014, has had an > > ULA prefix automatically generated and announced to hosts on the LAN > > interfaces. Via a few Internet searches, I can't find any reports of > > issues relating to OpenWRT and automatic ULAs in the last 2 years. > > I briefly had a router that did that to my network. That option was quick= ly turned > off to resolve the myriad problems it created. Subsequently, that router = was > abandoned in favor of a router I didn=E2=80=99t have to keep beating abou= t the head > and shoulders to prevent it from damaging the network in unexpected ways. > "your home does not constitute a comprehensive study of all possible or even all likely environments." > Owen > From nobody Sun Nov 15 04:25: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 EC7971B33BA for ; Sun, 15 Nov 2015 04:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.186 X-Spam-Level: X-Spam-Status: No, score=-13.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 nsxESUSDn2_A for ; Sun, 15 Nov 2015 04:25:39 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17A91B33B9 for ; Sun, 15 Nov 2015 04:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1916; q=dns/txt; s=iport; t=1447590338; x=1448799938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Xgkj+SHlcCLsk3B+Rtu+qBSmfo5wFEqB32zXcZgc6Q=; b=KoFzbVCjdLmhz8vjEL2gUKSlvEuY6N/JjYk61vhw6oVbFjDJ2DRVD59m Oo3pkG8VwKHE7P9BqAJwlDgntu+VvfwrewR0O7Hs1CKxKmfZvDZ1VFNGh 8IPIkkluSId/c6MsVrnE9Ij8X0Q7rzKIdda2h+pYAiEkjxQb4G/9IUiq0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQACeUhW/4cNJK1egzuBQga+SQENg?= =?us-ascii?q?WSGEAKBIjgUAQEBAQEBAYEKhDQBAQEEOj8QAgEIEQQBAR8JBzIUCQgCBAENBQi?= =?us-ascii?q?IJrdVAQEBAQEBAQEBAQEBAQEBAQEBAQEBGItSiTkBBJZIAY0fgWKEQJYpAR8BA?= =?us-ascii?q?UKEBHKERIEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,297,1444694400"; d="scan'208";a="207141038" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 15 Nov 2015 12:25:36 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAFCPaFg003262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 12:25:36 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 15 Nov 2015 07:25:35 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sun, 15 Nov 2015 07:25:35 -0500 From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Mukom Akong T." Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAIkUDw Date: Sun, 15 Nov 2015 12:25:35 +0000 Message-ID: <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 15 Nov 2015 12:25:40 -0000 Fred, Sorry for the delay. I am catching up with the original thread. Please s= ee below. >From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L >Sent: Monday, November 09, 2015 3:00 PM >To: Mukom Akong T. >Cc: v6ops@ietf.org >Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabili= ty discussion] >>'N' sends a DHCPv6 PD Solicit over the WAN interface >>and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to ei= ther the >>loopback interface or the LAN interface, but MUST NOT assign 'P' to the W= AN >>interface. >This is correct, since this WAN interface would have already gotten legiti= mate non-link-local addresses by other means. There is another reason. The prefix delegation (PD) RFC in RFC3633 says [the requesting router MUST NOT assign any delegated prefixes or subnets fr= om the delegated prefix(es) to the link through which it received the DHCP = message from the delegating router.] The reason RFC3633 has such a restriction is because if it were possible, t= hen the WAN IPv6 global address is on-link to the northbound SP router. T= he delegated prefix in P is supposed to be not on-link on the WAN. Thus i= f a loopback (lo) interface is configured with an IPv6 address from prefix = P, the IPv6 address is not on-link and thus the lo interface does not init= iate DAD for the address. However, if an address is configured on the lo interface manually and the a= ddress is not using an address from a DHCPv6 PD, what transpires? The int= ent of the admin is to configure an address which is not on-link to the dir= ectly connected network. The only other case is if the directly connected= network includes a node who manually assigned its IPv6 address (or is brok= en) and the address happens to match the address on the lo interface - now = DAD is needed. =20 Hemant From nobody Sun Nov 15 10:47: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 C5F3B1A8A42 for ; Sun, 15 Nov 2015 10:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.99 X-Spam-Level: ** X-Spam-Status: No, score=2.99 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, J_CHICKENPOX_64=0.6, 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 L51N1ZqEWRlv for ; Sun, 15 Nov 2015 10:47:11 -0800 (PST) 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 BC2581A8A41 for ; Sun, 15 Nov 2015 10:47:11 -0800 (PST) Received: from [198.134.88.215] (helo=[10.252.46.169]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1Zy2KO-0000Ue-9z; Sun, 15 Nov 2015 19:47:04 +0100 To: Lorenzo Colitti References: <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56489030.2010808@si6networks.com> Date: Sun, 15 Nov 2015 23:01:20 +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: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 15 Nov 2015 18:47:13 -0000 On 11/13/2015 08:11 PM, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 1:15 PM, Fernando Gont > > wrote: > >> The IP addresses and port numbers could be signaled out of band >> using another mechanism (NFC, bluetooth, email, smoke signals, >> well-known ports, whatever). > > And for that signaling you need.... a third party. > > Not for NFC, bluetooth, smoke signals, or well-known ports you > don't. And even if you do need a third party, there's a huge > difference between a third party that relays / snoops your traffic > vs. a third party that just puts the two parties in touch and then > disappears from the equation. Could you please elaborate how this would work: 1. A is behind a diode firewall 2. B is behind a diode firewall 3. A initiates a TCP connection with B. >> As noted, shortcuts in the current in the current architecture should >> not be interpreted as design principles.. NATs happen to make this >> very evident. Don't shoot the messenger for this. > > And we come around to the previous argument. The situation is not > that we are shooting NAT for coming and telling us the architecture > is broken. The situation is that we are shooting NAT for breaking > it. I fully disagree. NAT can be the most evil device ever. But all this things we've being talking about have to do with an incomplete architecture that NAT is making evident rather than about a complete architecture that NAT is breaking. >> If a network has a policy of only allowing outgoing connections, then >> any workaround to do that is an attack on that policy. And >> making.that workaround more difficult can thus be seen as a feature. > > Such a policy is misguided Says who? It's the policy that is being enforced. Period. > because it ignores the reality that today > outgoing connections are just as dangerous as incoming ones, if not > more. I disagree. Your claim can be correct for an enterprise with BYOD. BUt it is certainly not true for virtually every home network where a number of devices are attached to it -- possibly un-updated, with bad defaults, etc. In any case it's possible to DoS a device with a single packet, or worse, that you can root a device with a single packet (see one of the few openbsd remotely exploitable vulns, alas IPv6-based), a diode firewall would prevent such devices from being owned from the Internet. (Not to mention reflection attacks, etc.) This doesn't mean "yeah.. there couldn't be nothing evil inside", but is rather along the lines of the principle of "least privilege" applied in security -- "if I don't need something for ding what I need to do, then I get read of it"... whether that's superuser privileges, or connectivity privileges. Yes... in general, your ability to play with my network is at odds with my network's security. > We need a better reason to break the architecture than > misguided policies. The only references to architecture have been shortcomings (e.g., well-known ports) r not-so-clean app design such as FTP PORT -- that become evident with NATs. The rest is policy, not architecture. In case it's not clear: it's perfectly understandable why many of such things happened that way. What's not understandable is that we, 40 years later, don't learn from history and consider "design principles" things that are not. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Nov 15 11: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 E34B71A8AB5 for ; Sun, 15 Nov 2015 11:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.686 X-Spam-Level: X-Spam-Status: No, score=-113.686 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 TOhnSJzu4AOE for ; Sun, 15 Nov 2015 11:00:05 -0800 (PST) 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 F18061A8AB4 for ; Sun, 15 Nov 2015 11:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1447614005; x=1448823605; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=aMtn7NC6e387PCZMLgryhuJeo3h4l+H3pNGmCgsHyu4tRp+gjjUFw108 miElfof0FqXOwQpK87sFCdOtmQaZ0soxZ5Kt4FxODC/So34ZwR8p52h6o Xi628IOtrw6PjRr7jPk59Un+yBr8t9ewGHG3XLpEI+y25GsdYjlDzRYkk Y=; X-IronPort-AV: E=Sophos;i="5.20,298,1444694400"; d="scan'208";a="208037011" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2015 19:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tAFJ03kD028041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2015 19:00:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id tAFJ03mr010118; Sun, 15 Nov 2015 11:00:03 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id tAFJ03Jb010117; Sun, 15 Nov 2015 11:00:03 -0800 Date: Sun, 15 Nov 2015 11:00:03 -0800 From: fred@cisco.com Message-Id: <201511151900.tAFJ03Jb010117@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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: Sun, 15 Nov 2015 19:00:06 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Sun Nov 15 22:35: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 9843B1B2DFE for ; Sun, 15 Nov 2015 22:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 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, RP_MATCHES_RCVD=-0.585, 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 gEtY5cBesJJK for ; Sun, 15 Nov 2015 22:35:22 -0800 (PST) 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 9D50F1B2DF7 for ; Sun, 15 Nov 2015 22:35:14 -0800 (PST) Received: by ykdv3 with SMTP id v3so223822140ykd.0 for ; Sun, 15 Nov 2015 22:35:13 -0800 (PST) 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=wY7L68hdO5pF2woP/PNzgxe5cIhMtd8cV1xOUD6/hHk=; b=Q3sP9I3lV2ZhnigdMntsO2V82BoB6PXVGnukk2bAvo/VFBICu9vpUQetQOKjnjKMlX lL8lCLq0Js9UwtLvKru7d2SSPXXt3PpSHSFfoO9gn5vFI9u9bQhG2m7M9zmfzNoQZqvj clYrA3IkREKyyH+hqEfo/8fV1kzUK1EkWMwq4GFENiZ4kTU5XjnF5QL+npxTxuS509B0 Sjfjwd4i1USeHr5qaOyNznliHR7MjCMnTrW2TM7RdU1j4UzjDV/bnskFVeDv5BB7Rhsj ETzByi/nopVblQfcShAGBj8snbWi1dMhDWOShgKBpyMs8m8UfUNQoCRFTHysezJUkgq8 N7rQ== 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=wY7L68hdO5pF2woP/PNzgxe5cIhMtd8cV1xOUD6/hHk=; b=R5ZoCvzvmgfu2TjdrSybfk9k0SicIwcJLVK+1KU9v3dboymz9tkxI6hu6m+VehydHk DBgrsyq1oiYAx0U8GIt59h2mX/fi2uSu0vtKRT/OyhQP07i33smEEgZQYDVRtenxL+ek 1o/637p74kEqt86N8nJgIEqw+53REvEEal7qEveIkd3vJszoKr7bJANI8RUf4yTpCGMQ ftWZjd+y2zbpxPhyTwkXDI9ZqIGO25swcBXiwex5A3xPnJq5ftV2GLWxlF3rhvBjcSmF 8r6d/p1TK4O6VpfWXFJY8bDOnG4HwSrOa+Q8rD7dNezrUXhhxq23ApJDio+vOrjBOL7o t9LA== X-Gm-Message-State: ALoCoQnaUDyj2m/E8Wy7QwUvTPor6fpf8EnOCzPZSWKoy9wv101VzRG/DQFG2D2+gcpyb5AOU0pO X-Received: by 10.129.44.3 with SMTP id s3mr32762724yws.141.1447655713784; Sun, 15 Nov 2015 22:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Sun, 15 Nov 2015 22:34:53 -0800 (PST) In-Reply-To: <56489030.2010808@si6networks.com> References: <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> <56489030.2010808@si6networks.com> From: Lorenzo Colitti Date: Mon, 16 Nov 2015 15:34:53 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114278de943b300524a29c32 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 06:35:24 -0000 --001a114278de943b300524a29c32 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 15, 2015 at 11:01 PM, Fernando Gont wrote: > > Not for NFC, bluetooth, smoke signals, or well-known ports you > > don't. And even if you do need a third party, there's a huge > > difference between a third party that relays / snoops your traffic > > vs. a third party that just puts the two parties in touch and then > > disappears from the equation. > > Could you please elaborate how this would work: > > 1. A is behind a diode firewall > 2. B is behind a diode firewall > 3. A initiates a TCP connection with B. > A and B exchange ports out of band using NFC. A says to B "I am at port 1111". B says to A "I am at port 2222". A binds to port 1111 and connects to B port 2222. A's firewall creates a mapping A:1111 -> B:2222. At the same time B binds to port 2222 and connects to A port 1111. B's firewall creates a mapping B:2222->A:1111. Once both mappings are created, TCP works. This works behind a simple stateful firewall, but does not work behind a NAT because the port numbers are rewritten as well. Yes, if the firewall checks the sequence numbers as well, then A and B need to agree on those too. It's true that you can't do that as an unprivileged app on today's host OSes, but rogue apps are certainly able to do this. > I fully disagree. NAT can be the most evil device ever. But all this > things we've being talking about have to do with an incomplete > architecture that NAT is making evident rather than about a complete > architecture that NAT is breaking. > I know you disagree with that. All I'm saying is that we've gone back to that. > I disagree. Your claim can be correct for an enterprise with BYOD. BUt > it is certainly not true for virtually every home network where a number > of devices are attached to it -- possibly un-updated, with bad defaults, > etc. > > In any case it's possible to DoS a device with a single packet, or > worse, that you can root a device with a single packet (see one of the > few openbsd remotely exploitable vulns, alas IPv6-based), a diode > firewall would prevent such devices from being owned from the Internet. > But that's really hard. You have to scan Internet space at random, scanning OUI space for remotely exploitable devices... much easier to use a browser trojan to compromise the user's host and DOS the device from there. --001a114278de943b300524a29c32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On S= un, Nov 15, 2015 at 11:01 PM, Fernando Gont <fgont@si6networks.com> wrote:
    >= ; Not for NFC, bluetooth, smoke signals, or well-known ports you
    > don't. And even if you do need a third party, there's a huge > difference between a third party that relays / snoops your traffic
    > vs. a third party that just puts the two parties in touch and then
    > disappears from the equation.

    Could you please elaborate how this would work:

    1. A is behind a diode firewall
    2. B is behind a diode firewall
    3. A initiates a TCP connection with B.

    A and B exchange ports out of band using NFC. A says to B "I am at po= rt 1111". B says to A "I am at port 2222". A binds to port 1= 111 and connects to B port 2222. A's firewall creates a mapping A:1111 = -> B:2222. At the same time B binds to port 2222 and connects to A port = 1111. B's firewall creates a mapping B:2222->A:1111. Once both mappi= ngs are created, TCP works.

    I fully disagree. NAT can be the most evil device ever.= But all this
    things we've being talking about have to do with an incomplete
    architecture that NAT is making evident rather than about a complete
    architecture that NAT is breaking.

    I kn= ow you disagree with that. All I'm saying is that we've gone back t= o that.
    =C2=A0
    I disagree. Yo= ur claim can be correct for an enterprise with BYOD. BUt
    it is certainly not true for virtually every home network where a number of devices are attached to it -- possibly un-updated, with bad defaults, etc.

    In any case it's possible to DoS a device with a single packet, or
    worse, that you can root a device with a single packet (see one of the
    few openbsd remotely exploitable vulns, alas IPv6-based), a diode
    firewall would prevent such devices from being owned from the Internet.
    =

    But that's really hard. You have to sc= an Internet space at random, scanning OUI space for remotely exploitable de= vices... much easier to use a browser trojan to compromise the user's h= ost and DOS the device from there.
    --001a114278de943b300524a29c32-- From nobody Mon Nov 16 05:46: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 57E041ACF0A for ; Mon, 16 Nov 2015 05:46:22 -0800 (PST) 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 t8OwbbQrwODZ for ; Mon, 16 Nov 2015 05:46:20 -0800 (PST) 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 85D0B1AD0B0 for ; Mon, 16 Nov 2015 05:46:15 -0800 (PST) Received: from host77.186-109-138.telecom.net.ar ([186.109.138.77] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1ZyK6e-0007D1-TS; Mon, 16 Nov 2015 14:46:08 +0100 To: Lorenzo Colitti References: <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5649721C.7010308@si6networks.com> Date: Sun, 15 Nov 2015 22:05:16 -0800 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 Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 13:46:22 -0000 On 11/12/2015 07:53 PM, Lorenzo Colitti wrote: > On Fri, Nov 13, 2015 at 12:36 PM, Fernando Gont > wrote: > > You claim that it is simpler to achieve that with NATs, than with FWs. > How would that happen without relying on a third party, and without > guessing port numbers to fake e.g. a TCP simultaneous open? > > > The IP addresses and port numbers could be signaled out of band using > another mechanism (NFC, bluetooth, email, smoke signals, well-known > ports, whatever). Yeah. You could also do all communication out of band, too. That's handwashing -- the problem is still there, and you don't say how you solve it, but kind of rather flag it as "out of scope". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 16 05:47: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 5E7BF1AD1DB for ; Mon, 16 Nov 2015 05:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.341 X-Spam-Level: ** X-Spam-Status: No, score=2.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TlkE4-sFYFlQ for ; Mon, 16 Nov 2015 05:47:10 -0800 (PST) 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 31A1F1AD1A6 for ; Mon, 16 Nov 2015 05:47:10 -0800 (PST) Received: from host77.186-109-138.telecom.net.ar ([186.109.138.77] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1ZyK7b-0007DN-NU; Mon, 16 Nov 2015 14:47:04 +0100 To: Owen DeLong References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <56453C96.7070509@si6netwo! rks.com> <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <564975CF.7000908@si6networks.com> Date: Sun, 15 Nov 2015 22:21:03 -0800 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: <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 13:47:11 -0000 On 11/12/2015 08:53 PM, Owen DeLong wrote: >>> >>>> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) >>> > wrote: >>>> >>>>> Nope. It is much easier to establish a connection across a diode >>>>> firewall than to establish one across a NAT. In the former case, all >>>>> the endpoints need to do is send each other packets at about the same >>>>> time. In the latter, they need to implement NAT traversal via relays. >>>> >>>> It is only 'slightly' easier... Because guessing the TCP sequence >>>> number of the other party... Well good luck :-) >>> >>> With a diode firewall, you don’t have to guess. Most diode firewalls >>> don’t look at TCP sequence numbers actively. They look only at the L3 >>> and L4 identifiers to determine state. >>> Some look at SYN bits and toss SYN packets going in the wrong direction, >>> but most just look for an ACK bit. >>> >>> Nonetheless, it’s also much easier because a diode firewall can easily >>> be given an exception to permit a particular flow or the initiation of a >>> class of flows to a particular protected host or set of hosts. >> >> The problem is how to do this automagically. > > Why does it have to be automagic? Because the regular user is, alas, a user, and not a fw adminsitrator. >>> In the case of a NAT, however (more specifically a NAPT), it is not >>> possible to program multiple port 80 terminations to land on different >>> hosts behind the NAT. >> >> That's like saying that the problem with cars is that they cannot fly -- >> yes, that's what a NAT is. > > Well… That is certainly a limitation of most automobiles, but I’m happy to > report that there are working alternatives such as the Terrafugia Transition > and some older prototypes as well. Then that's not a car. And that's my point. You're complaining about something that is a characteristic of NAT. That said, there's no conceptual reason for which HTTP must run at port 80. And would be perfectly sensible to have multiple instances of different HTTP implementations at the same host, without having to resort to other hacks such as ip aliases. Again: here NATs are making it very evident that harcoding HTTP to port 80 comes at a price. You don't want a full directory service? -- Fine... then pay the price for taking a shortcut. >> I might also add that this is another kludge that is made evident by >> NAT: there's no reason whatsoever for which a given service should run >> in any specific transport protocol port. Consider that a kludge or >> shortcut than a principle. > > Meh… There’s no mechanism available for signaling port numbers in response > to name lookups (modulo SRV records that don’t seem to be very popular in > practice). As you note, there is: SRV. Regarding popularity, when did popularity became a metric of correctness? > There are certain advantages to the idea of well known port numbers > and whether or not you consider them a kludge, they are certainly in widespread > use and have a great deal of history and support in the IETF and IANA. Can we have a technical discussion, please? I'm arguing that there are many pieces of the puzzle missing, and you answer "having a full puzzle is not popular.. besides, everyone loves it, and we have done it for a long time". That's like arguing that McDonald's sells quality beef because their restaurants are usually crowded, and Mc has made a lot of profit for years. McD might make a lot of money. There might be certain advantages of eating at McD (price (in some countries), timeliness, or whatever). But that doesn't make a Big Mac good beef. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 16 08:42: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 59E0C1A6F61 for ; Mon, 16 Nov 2015 08:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] 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 6_ZsDJxHCIAD for ; Mon, 16 Nov 2015 08:41:48 -0800 (PST) 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 AA28D1A6F58 for ; Mon, 16 Nov 2015 08:41:42 -0800 (PST) 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 tAGGfgsx015331; Mon, 16 Nov 2015 10:41:42 -0600 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGGfWlX015261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 10:41:33 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.114]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 08:41:30 -0800 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Mukom Akong T." Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6LeFYwgAa8AYCAAeLTIIAJg1aAgAFM4PA= Date: Mon, 16 Nov 2015 16:41:30 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> In-Reply-To: <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.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: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 16:42:00 -0000 Hi Hemant, > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Sunday, November 15, 2015 4:26 AM > To: Templin, Fred L; Mukom Akong T. > Cc: v6ops@ietf.org > Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabil= ity discussion] >=20 > Fred, >=20 > Sorry for the delay. I am catching up with the original thread. Please= see below. OK. > >From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > >Sent: Monday, November 09, 2015 3:00 PM > >To: Mukom Akong T. > >Cc: v6ops@ietf.org > >Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabi= lity discussion] >=20 >=20 > >>'N' sends a DHCPv6 PD Solicit over the WAN interface > >>and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to = either the > >>loopback interface or the LAN interface, but MUST NOT assign 'P' to the= WAN > >>interface. >=20 > >This is correct, since this WAN interface would have already gotten legi= timate non-link-local addresses by other means. >=20 > There is another reason. The prefix delegation (PD) RFC in RFC3633 says >=20 > [the requesting router MUST NOT assign any delegated prefixes or subnets = from the delegated prefix(es) to the link through which it > received the DHCP message from the delegating router.] Correct; that is exactly why I said "MUST NOT". > The reason RFC3633 has such a restriction is because if it were possible,= then the WAN IPv6 global address is on-link to the northbound > SP router. The delegated prefix in P is supposed to be not on-link on t= he WAN. Thus if a loopback (lo) interface is configured with an > IPv6 address from prefix P, the IPv6 address is not on-link and thus the= lo interface does not initiate DAD for the address. >=20 > However, if an address is configured on the lo interface manually and the= address is not using an address from a DHCPv6 PD, what > transpires? The intent of the admin is to configure an address which is= not on-link to the directly connected network. The only other > case is if the directly connected network includes a node who manually as= signed its IPv6 address (or is broken) and the address > happens to match the address on the lo interface - now DAD is needed. This is starting to diverge from the case I originally intended this discus= sion to examine. The case I am interested in is as follows: - Node N receives a /64 prefix delegation for prefix P over interface eth0. - N assigns P to the lo interface as a /64 route. This is done to black-hol= e unused portions of P. - N configures address A from prefix P, and assigns it to eth0. - N need not perform DAD for A over eth0, because the delegating router has made sure that the routing system will route all packets with a destination address from P to node N, and not to any other node. In this way, N can function as an ordinary host according to the strong end system model even though it acted as a "requesting router" in procuring a prefix from the delegating router. No other node X on the same link as N can therefore configure an address from P and have the routing system return packets to X. In fact, any node X that configures an address from P can be considered an "attacker", and the use or non-use of DAD has no way of preventing that. In fact, the use of DAD could give X a clue as to which addresses from P are ripe for attacking. So, it is in fact better to NOT do DAD. Thanks - Fred fred.l.templin@boeing.com > Hemant >=20 >=20 >=20 From nobody Mon Nov 16 09:03: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 BB1061A6FAC for ; Mon, 16 Nov 2015 09:03:53 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 wAmWz63irM7m for ; Mon, 16 Nov 2015 09:03:51 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 02C151A6FBE for ; Mon, 16 Nov 2015 09:03:48 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZyNBq-0000HnC; Mon, 16 Nov 2015 18:03:38 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com Date: Mon, 16 Nov 2015 18:03:32 +0100 Archived-At: Subject: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 17:03:53 -0000 >This is starting to diverge from the case I originally intended this discussion > to >examine. The case I am interested in is as follows: > >- Node N receives a /64 prefix delegation for prefix P over interface eth0. >- N assigns P to the lo interface as a /64 route. This is done to black-hole > unused portions of P. >- N configures address A from prefix P, and assigns it to eth0. >- N need not perform DAD for A over eth0, because the delegating router > has made sure that the routing system will route all packets with a > destination address from P to node N, and not to any other node. > >In this way, N can function as an ordinary host according to the strong end >system model even though it acted as a "requesting router" in procuring a >prefix from the delegating router. No other node X on the same link as >N can therefore configure an address from P and have the routing system >return packets to X. In fact, any node X that configures an address from P >can be considered an "attacker", and the use or non-use of DAD has no >way of preventing that. In fact, the use of DAD could give X a clue as to >which addresses from P are ripe for attacking. So, it is in fact better to >NOT do DAD. I have a two questions about this, sort of unrelated to DAD (so I changed the subject). 1) How do packets reach the host. Is that documented somewhere? I assume that in this case a router will send packets with destination prefix P to the link local address of N. But is that specified somewhere? 2) If a node M on the same ethernet link wants to communicate with address A, it creates a destination cache entry for A picking a default router as next hop (because P is not onlink). Later, A can send the reply directly to M if M's address is onlink. That is likely to cause a neighbor cache entry for A at M, which will not be used because the destination cache entry is still in place. Not good if you ever want to debug something. From nobody Mon Nov 16 09:26: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 3E8581A702B for ; Mon, 16 Nov 2015 09:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 9HcBZ6F6LXKv for ; Mon, 16 Nov 2015 09:26:31 -0800 (PST) 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 D13CE1A7025 for ; Mon, 16 Nov 2015 09:26:31 -0800 (PST) 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 tAGHQTtw011217; Mon, 16 Nov 2015 11:26:29 -0600 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGHQMEt011130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 11:26:22 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.203]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 09:26:22 -0800 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] Thread-Index: AQHRIJDFYIkt6ik5zUK0JBRfmgHKsJ6e4qQA Date: Mon, 16 Nov 2015 17:26:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-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] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 17:26:33 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Monday, November 16, 2015 9:04 AM > To: v6ops@ietf.org > Cc: Templin, Fred L; Hemant Singh (shemant) > Subject: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-ava= ilability discussion] ] >=20 > >This is starting to diverge from the case I originally intended this dis= cussion > > to > >examine. The case I am interested in is as follows: > > > >- Node N receives a /64 prefix delegation for prefix P over interface et= h0. > >- N assigns P to the lo interface as a /64 route. This is done to black-= hole > > unused portions of P. > >- N configures address A from prefix P, and assigns it to eth0. > >- N need not perform DAD for A over eth0, because the delegating router > > has made sure that the routing system will route all packets with a > > destination address from P to node N, and not to any other node. > > > >In this way, N can function as an ordinary host according to the strong = end > >system model even though it acted as a "requesting router" in procuring = a > >prefix from the delegating router. No other node X on the same link as > >N can therefore configure an address from P and have the routing system > >return packets to X. In fact, any node X that configures an address from= P > >can be considered an "attacker", and the use or non-use of DAD has no > >way of preventing that. In fact, the use of DAD could give X a clue as t= o > >which addresses from P are ripe for attacking. So, it is in fact better = to > >NOT do DAD. >=20 > I have a two questions about this, sort of unrelated to DAD (so I changed= the > subject). >=20 > 1) How do packets reach the host. Is that documented somewhere? RFC3633 is largely silent on this, but when P is delegated to N, it is implied that the delegating router must somehow inject information into the routing system that will guide packets with destination address A to N. > I assume that in this case a router will send packets with destination > prefix P to the link local address of N. But is that specified somewhe= re? That is correct, but again RFC3633 is largely silent. > 2) If a node M on the same ethernet link wants to communicate with addres= s > A, it creates a destination cache entry for A picking a default router > as next hop (because P is not onlink). Later, A can send the reply > directly to M if M's address is onlink. That is likely to cause a > neighbor cache entry for A at M, which will not be used because the > destination cache entry is still in place. In this instance, the default router would return a Redirect to M to inform it that N is a better first hop for reaching address A. The Redirect would cause M to update its destination cache accordingly. Thanks - Fred fred.l.templin@boeing.com > Not good if you ever want to debug something. >=20 From nobody Mon Nov 16 09:54: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 6B8E71AC414 for ; Mon, 16 Nov 2015 09:54:09 -0800 (PST) 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 m11uglJ4vGCb for ; Mon, 16 Nov 2015 09:54:08 -0800 (PST) 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 D737A1AC3F5 for ; Mon, 16 Nov 2015 09:54:05 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZyNyc-0000EoC; Mon, 16 Nov 2015 18:54:02 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Mon, 16 Nov 2015 17:26:22 +0000 ." <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 16 Nov 2015 18:53:57 +0100 Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 17:54:09 -0000 >> 1) How do packets reach the host. Is that documented somewhere? > >RFC3633 is largely silent on this, but when P is delegated to N, it is >implied that the delegating router must somehow inject information >into the routing system that will guide packets with destination >address A to N. I wonder where this should be documented. There seem to be some other interesting interactions: a DHCPv6 server running on a host should not hand out a PD to a host (because it doesn't work), but can hand it out to a router. And can hand it out when there request comes through a relay agent. A relay agent running on a router should install a routing table entry if the PD request comes from a host. There might be more interesting details. >> 2) If a node M on the same ethernet link wants to communicate with addres= >s >> A, it creates a destination cache entry for A picking a default router >> as next hop (because P is not onlink). Later, A can send the reply >> directly to M if M's address is onlink. That is likely to cause a >> neighbor cache entry for A at M, which will not be used because the >> destination cache entry is still in place. > >In this instance, the default router would return a Redirect to M to inform >it that N is a better first hop for reaching address A. The Redirect would >cause M to update its destination cache accordingly. I wondered about redirect just after I hit sent. The neighbor discovery RFC is very explict about the IsRouter flag in the neighbor cache. In this case M has to set the IsRouter flag for A. I wonder if A should then always set the Router flag in neighbor advertisements as well. It looks like it has to, otherwise the neighbor cache will be flushed. From nobody Mon Nov 16 10:12: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 2C8401B30BE for ; Mon, 16 Nov 2015 10:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 wqhj8R1gr5No for ; Mon, 16 Nov 2015 10:12:26 -0800 (PST) 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 879E41B30BD for ; Mon, 16 Nov 2015 10:12:26 -0800 (PST) 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 tAGICQKg008806; Mon, 16 Nov 2015 12:12:26 -0600 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGICKk0008782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 12:12:21 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.222]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 10:12:19 -0800 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] Thread-Index: AQHRIJpUsgni8VUg+0O8njNAhlteCg== Date: Mon, 16 Nov 2015 18:12:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4CFA6@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832F4CF07@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 18:12:28 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Monday, November 16, 2015 9:54 AM > To: v6ops@ietf.org > Cc: Templin, Fred L > Subject: Re: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr= -availability discussion] ] >=20 > >> 1) How do packets reach the host. Is that documented somewhere? > > > >RFC3633 is largely silent on this, but when P is delegated to N, it is > >implied that the delegating router must somehow inject information > >into the routing system that will guide packets with destination > >address A to N. >=20 > I wonder where this should be documented. The documentation or non-documentation considerations are exactly the same whether N is a host or a router. RFC3633 chooses to remain silent, and I have not seen errata filed nor updates to document routing. > There seem to be some other > interesting interactions: a DHCPv6 server running on a host should not DHCPv6 server runs either on the delegating router or (if the delegating router is a relay) on another server somewhere else in the network. Host vs. router considerations are one and the same as for standard PD to any type of "requesting router". > hand out a PD to a host (because it doesn't work), but can hand it out to > a router. And can hand it out when there request comes through a relay ag= ent. >=20 > A relay agent running on a router should install a routing table entry > if the PD request comes from a host. That's what AERO does, yes. > There might be more interesting details. AFAICT, the case is clean. But, certainly, we should look at it from all angles yes. > >> 2) If a node M on the same ethernet link wants to communicate with add= res=3D > >s > >> A, it creates a destination cache entry for A picking a default rou= ter > >> as next hop (because P is not onlink). Later, A can send the reply > >> directly to M if M's address is onlink. That is likely to cause a > >> neighbor cache entry for A at M, which will not be used because the > >> destination cache entry is still in place. > > > >In this instance, the default router would return a Redirect to M to inf= orm > >it that N is a better first hop for reaching address A. The Redirect wou= ld > >cause M to update its destination cache accordingly. >=20 > I wondered about redirect just after I hit sent. The neighbor discovery R= FC > is very explict about the IsRouter flag in the neighbor cache. > In this case M has to set the IsRouter flag for A. >=20 > I wonder if A should then always set the Router flag in neighbor advertis= ements > as well. It looks like it has to, otherwise the neighbor cache will be > flushed. Section 8.3 of RFC4861 says: "If the Target and Destination Addresses are the same, the host MUST treat the Target as on-link. If the Target Address is not the same as the Destination Address, the host MUST set IsRouter to TRUE for the target. If the Target and Destination Addresses are the same, however, one cannot reliably determine whether the Target Address is a router. Consequently, newly created Neighbor Cache entries should set the IsRouter flag to FALSE, while existing cache entries should leave the flag unchanged. If the Target is a router, subsequent Neighbor Advertisement or Router Advertisement messages will update IsRouter accordingly." and Appendix D. of RFC4861 says: " - The target of the redirect, when the target is the same as the destination, does not carry any host vs. router information. All that is known is that the destination (i.e., target) is on-link but it could be either a host or a router." In this case, the Target and Destination Address are the same. So, there is no host vs. router information, and the default value for isRouter is FALSE= . Thanks - Fred fred.l.templin@boeing.com From nobody Mon Nov 16 10:37: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 34BDB1A8712 for ; Mon, 16 Nov 2015 10:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 JVxbxsqorF5Z for ; Mon, 16 Nov 2015 10:37:19 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id B4AF51A8711 for ; Mon, 16 Nov 2015 10:37:18 -0800 (PST) Received: (qmail 23368 invoked from network); 16 Nov 2015 18:37:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Nov 2015 18:37:16 -0000 Date: Mon, 16 Nov 2015 19:37:16 +0100 (CET) Message-Id: <20151116.193716.74754318.sthaug@nethelp.no> To: pch-v6ops-3@u-1.phicoh.com From: sthaug@nethelp.no In-Reply-To: References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] PD to hosts 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, 16 Nov 2015 18:37:21 -0000 > >> 1) How do packets reach the host. Is that documented somewhere? > > > >RFC3633 is largely silent on this, but when P is delegated to N, it is > >implied that the delegating router must somehow inject information > >into the routing system that will guide packets with destination > >address A to N. > > I wonder where this should be documented. There seem to be some other > interesting interactions: a DHCPv6 server running on a host should not > hand out a PD to a host (because it doesn't work), but can hand it out to > a router. And can hand it out when there request comes through a relay agent. The difference between host and router seems to be getting more and more artificial, what with servers running lots of VMs etc. I find it much more logical to simply assume that if *some* client asks for a PD, it knows how to use it. Whether the client is a host or a router is rather irrelevant. Steinar Haug, AS 2116 From nobody Mon Nov 16 11:49: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 F25541A88D0 for ; Mon, 16 Nov 2015 11:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 rZ8SyPIp9W9m for ; Mon, 16 Nov 2015 11:49:47 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 634A51A88CB for ; Mon, 16 Nov 2015 11:49:47 -0800 (PST) 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 tAGJlgXc018940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 11:47:43 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Mon, 16 Nov 2015 11:47:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03BC1DEF-17E0-49A1-A628-5CE786FFCF0D@delong.com> References: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 19:49:49 -0000 > On Nov 14, 2015, at 17:21 , Hemant Singh (shemant) = wrote: >=20 >=20 >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Saturday, November 14, 2015 7:58 PM > To: Hemant Singh (shemant) > Cc: Gert Doering; v6ops@ietf.org > Subject: Re: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >=20 >> I didn=E2=80=99t say you couldn=E2=80=99t bridge the LO and External = interfaces=E2=80=A6 I said that short of doing that, having the same = subnet on both interfaces is a misconfiguration. >=20 >> You haven=E2=80=99t proven that the interfaces aren=E2=80=99t bridged = (or effectively so), nor have you proven that they are actually on the = same subnet. Ergo, it is, actually, still a meaningless example. >=20 > An app has decides to use the IPv6 address of the lo interface to = source the app's packets. This is what the ping command in my example = decides since the command is asked to use the source of the ICMPv6 = packets as the lo interface's address. Then usual data forwarding on = the router takes over. Routing decides from the packet destination, the = packet has to egress out an outbound interface, say, eth0. However, = when the packet is to be egressed out eth0, the L2 destination lookup = fails. Eth0 issues a ND address resolution to resolve the destination = uses its own source interface IPv6 address. I forced the ND address = resolution by clearing the IPv6 neighbor cache on the router. Then I = proved the packet is forwarded. There is no bridging involved and = packets are sourced fine using the lo interface. >=20 > Hemant Which has exactly nothing to do with the idea of having ETH0 do DAD on = an address on LO. All I have been saying is that having an LO address on the same subnet = as ETH0 without bridging is a misconfiguration. I never said it couldn=E2=80=99t work. I never said it didn=E2=80=99t = work. Certainly at a minimum it is a recipe for a potential undetected = duplicate address as the router SHOULD NOT respond to an ND packet for it=E2=80=99s LO interface on ETH0 or any other non-LO = interface. Owen From nobody Mon Nov 16 11:51: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 062BC1A88D5 for ; Mon, 16 Nov 2015 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 JAth9R1_AV5f for ; Mon, 16 Nov 2015 11:51:34 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AF51A88D0 for ; Mon, 16 Nov 2015 11:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=755; q=dns/txt; s=iport; t=1447703493; x=1448913093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z9I6cJNyku4DEhJHv/07y4cN7z8QuptBx+i3g+xB6FY=; b=bHLtiSVwGzou17R07HETVEJPNRD3IbxoICb0A001lfAH1jE1uroB6ag2 vfWsbu2mhNbm2LTDV6PJAvs0+xdQFXNF/EVwNzZVhQjfxy9XldviPeqMO zAcNSDVLYadXENRr7iUhIFAO7bvjlazAD4fyIon3c4tamd23NCRLI4GcU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgDIMkpW/4YNJK1dgzuBQga+WgENg?= =?us-ascii?q?WWGEAKBRzgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQBDQU?= =?us-ascii?q?IiCa7KwEBAQEBAQEBAQEBAQEBAQEBAQEBARiLUok5AQSWSAGNH5xLAR8BAUKCE?= =?us-ascii?q?R2BVnIBhAKBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,304,1444694400"; d="scan'208";a="45393526" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2015 19:51:33 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tAGJpWJd014718 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2015 19:51:33 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 Nov 2015 14:51:32 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Mon, 16 Nov 2015 14:51:32 -0500 From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Mukom Akong T." Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAIkUDwgAI3wAD//+CA4A== Date: Mon, 16 Nov 2015 19:51:32 +0000 Message-ID: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.78.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 19:51:35 -0000 Fred, -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, November 16, 2015 11:42 AM To: Hemant Singh (shemant); Mukom Akong T. Cc: v6ops@ietf.org Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] >- Node N receives a /64 prefix delegation for prefix P over interface eth0= . >- N assigns P to the lo interface as a /64 route. This is done to black-ho= le > unused portions of P. >- N configures address A from prefix P, and assigns it to eth0. If A from prefix P is assigned to eth0, we have violated rfc3633 which says= to not assign any IPv6 address on the port on which the node received the = PD from. Did I miss anything? Hemant From nobody Mon Nov 16 11: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 DFF791A88E7 for ; Mon, 16 Nov 2015 11:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.985 X-Spam-Level: X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 iM0K2g_nZCGS for ; Mon, 16 Nov 2015 11:58:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id B77331A88DA for ; Mon, 16 Nov 2015 11:58:55 -0800 (PST) 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 tAGJurxS019528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 11:56:53 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_89676796-127D-4BF8-AD28-E51EA701E695" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: Date: Mon, 16 Nov 2015 11:56:53 -0800 Message-Id: <1A94ECF6-9D9B-4DCE-A7F5-F97C6AD49301@delong.com> References: <20151106.063106.74659839.sthaug@nethelp.no> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> To: Mark Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 19:59:01 -0000 --Apple-Mail=_89676796-127D-4BF8-AD28-E51EA701E695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 15, 2015, at 02:11 , Mark Smith wrote: >=20 > On 14 Nov 2015 14:19, "Owen DeLong" > wrote: >>=20 >>>>=20 >>>> I=E2=80=99m all for providing a lower cost alternative to having a = legitimate registry >>>> for addresses for smaller users. >>>>=20 >>>=20 >>> Zero cost is what is needed. >>=20 >> I think a nominal fee (say US$25/year) wouldn=E2=80=99t represent a = significant barrier. >>=20 >=20 > It's $25 p.a. that can't be spent on something else. >=20 >>>=20 >>> You can only charge money for magic numbers because of the magic, = not >=20 >>> the numbers. The numbers themselves are free, because anybody can = make >>> them up. >>>=20 >>> The magic you're buying or renting when you get RIR space is: >>>=20 >>> - actively managed global uniqueness (although not absolutely >>> guaranteed, because of the human error factor) >>=20 >> To the best of my knowledge there are all of 3 instances of = non-uniqueness >> temporarily resulting from such errors in all of internet history and = all in IPv4 >> or ASNs. >=20 >>> - implicit acceptance of routes for that space by networks that = carry >>> the DFZ route table >>=20 >> Really? I don=E2=80=99t think so. >>=20 >=20 > Why not? RIRs issue lots of space that may or may not get accepted by any given = service provider. There is nothing inherent in getting an allocation/assignment from an = RIR that guarantees you or even implies you will necessarily get a slot in any particular = provider=E2=80=99s routing table. True, it=E2=80=99s more likely than if you just make up random numbers, = but it=E2=80=99s just more likely. >=20 >>> The first property is really a requirement and necessity demanded by >=20 >>> the second one. >>=20 >> Certainly the second cannot function with the first, yes, but the = first >> property is oh so desirable for so many other reasons. >>=20 >=20 > I agree, which is why I think ULAs are much better than site-locals. I fail to see the need or usefulness of either, TBH. >=20 >>> If people don't need the magic of implicit acceptance in the DFZ, = why >>> should they have to pay for it? That is the unnecessary tax or cost = on >>> enabling IPv6 that you're creating by saying people should be = required >>> to use RIR space, even if they have no intention of having the >>> corresponding local address space routes in the DFZ. >>=20 >> If it isn=E2=80=99t connecting to the global internet than it = doesn=E2=80=99t matter what numbers >> you make up or whether they are unique or how you go about making = them >> up. It=E2=80=99s not stealing space, it=E2=80=99s just using random = numbers that aren=E2=80=99t actually >> internet addresses because you happen to be running the same protocol = on >> your disconnected network as most networks run on the internet. >>=20 >>> If people later need the magic of implicit acceptance in the DFZ, = they >>> can get PA or PI, and most importantly add it to their existing ULA >>> addressed network. >>=20 >> With all the attendant problems that have been repeatedly discussed. >>=20 >=20 > Can you enumerate them for me please? Review the record. They=E2=80=99ve been well documented and relate = mainly to the fact that most code is not well suited to having the host be multihomed and the = APIs provide poor concepts of application source address selection and the operating = system mechanisms such as they are are generally poorly implemented and even = less well understood by administrators and end users that need them. >=20 >=20 >>> Renumbering is not required to add PA/PI, and that is where IPv6 >>> provides a much better alternative than IPv4 - IPv4 demanded an >>> exclusive or between PA/PI address space and RFC1918s, and RFC1918s >>> were perceived to be cheaper and easier for a variety of reasons, >>> including because a 'magic translation box' could be used between >>> RFC1918s and PA/PI needed to reach the Internet. >>=20 >> I can put an RFC1918 address and a GUA IPv4 address on the same >> interface on any modern host as well. This is no different from IPv6. >>=20 >=20 > *You* can put two addresses on a interface. DHCPv4 can't, and the > protocol stack treats the addresses/subnets as though they were > assigned to different interfaces/links. Depends on the implementation, though I agree about DHCPv4, but that=E2=80= =99s not an inherent property of IPv4, that=E2=80=99s a limitation baked into the = IPv4 implementation of DHCP. In fact, if we taught hosts how to understand it, DHCPv4 could = supply additional addresses in an option field fairly easily and the hosts = could easily apply them to interfaces. >> There is no meaningful difference in this regard. ULA is just RFC1918 >> with more addresses available for stupid host tricks. >>=20 >>> In other words, in IPv4 we're forced into serial address spaces, = where >>> as in IPv6 we have the opportunity for multiple parallel ones. >>=20 >> This statement is not reality on any modern system. >>=20 >=20 > See above. Stating it again doesn=E2=80=99t make it any less incorrect. >>>>> Humans don't incur costs on themselves unless they see or perceive >>>>> some equivalent benefit. Making something available for "free", in >>>>> this case a local yet globally unique network address space, >>>>> significantly lowers the barrier to IPv6 adoption. If you've = bought >>>>> the equipment to build your network, and it comes IPv6 enabled for >>>>> "free", you can then immediately build an IPv6 network using ULA >>>>> spa >>>=20 >>>> Except that ULA isn=E2=80=99t globally unique, it=E2=80=99s just = =E2=80=9Cprobably unique=E2=80=9D for various >>>> relatively high values of =E2=80=9Cprobably=E2=80=9D depending on = how you go about choosing >>>> your ULA prefix. Were ULA globally unique, you=E2=80=99d have the = double edge sword >>>> of: >>>>=20 >>>> 1. It=E2=80=99s good because it=E2=80=99s free PI = address space. >>>=20 >>> It isn't "free PI address space", because it doesn't have the magic >>> that real PI address space has - implicit acceptance by all carriers >>> of the DFZ route table. >>=20 >> Neither does real PI space. This is a figment of your imagination. >>=20 >=20 > "Implicit" is a form of the word "implied". Implied doesn't guarantee > they will be accepted by all networks carrying DFZs. It means of all > of the IPv6 address space, PI is most likely to be accepted by > networks carrying DFZ, because most people who carry DFZ routes have a > default accept policy, and only drop a small subset of routes (their > own PI/PA etc.) In fact, most of them will also accept a fair amount of bogus space if = you put it within the right range. Making sure it is real PI doesn=E2=80=99t come with any = magic. Making it less likely to conflict with real PI may remove some perceived magic, but = that=E2=80=99s not the same thing. >=20 >=20 >>> The only similar properties between PI and ULAs are the >>> (statistical/managed) global uniqueness. >>=20 >> Not at all true=E2=80=A6 >>=20 >> In fact, those are arguably the only differences. >>=20 >> They are both prefixes of 128 bit numbers, usually in /48 chunks. >> They are both intended for numbering interfaces on devices running = the IPv6 protocol. >> They are both capable of being forward by routers. >> Both can be described and routes distributed via OSPFv3, ISIS, and = BGPv4. >>=20 >> The only real difference between ULA and PI is the convention of not = routing >> ULA across borders where administrators choose to enforce and/or = abide by >> said convention and the fact that anyone can make up whatever ULA = address >> they want, where there is an expectation that PI is coordinated = through an RIR, >> though there is enough history of hijacking in IPv4 prefixes that I = see no reason >> to believe this will not occur with IPv6. >>=20 >>>> 2. It=E2=80=99s bad because it=E2=80=99s a free end-run = around the RIR policy processes. >>>=20 >>> Not if you can't successfully get it globally routed. >>=20 >> I assert that this is simply a matter of the right number of = =E2=80=9Cwombats=E2=80=9D placed >> in the right pockets. (To use a term coined by Jan Zorz). >>=20 >=20 > And it would be a terrible way to spend your "wombats=E2=80=9D. Perhaps, but that doesn=E2=80=99t mean there won=E2=80=99t come a day = when someone chooses to do so. >>> Here's the challenge for you. Show us how easy it is for you to get = a >>> ULA of your choosing permanently accepted in all ASes who accept the >>> DFZ route table, at a cost and effort that is lower than using RIR = PI >>> space instead. >>=20 >> The cost for the first people to do it will be extraordinarily high. >=20 > Right. That creates a massive incentive to use the much cheaper RIR PI > space to more easily and quickly achieve the same goal. Thus obviating the need to have ULA in the first place. >> As it becomes >> more common practice, the price will drop. >>=20 >>>>> If at a later date a ULA addressed network connects to the = Internet >>>>> they would add PA or PI space to be able to access external >>>>> destinations, because IPv6 is designed to fully support parallel >>>>> address spaces (i.e., so having ULAs on your network doesn't >>>>> automatically imply using NAT66). >>>>=20 >>>> Except for all the problems previously noted in such installations = with various >>>> issues around source address selection, etc. >>>>=20 >>>=20 >>> I've been running ULAs here at home more than 4 years, both with = 6to4 >>> IPv6 connectivity, and for the last 4 years native connectivity. I >>> haven't seen any issues, or if there have been any, they've been >>> overcome transparently via such things as Happy Eyeballs. (with the >>> caveat that all my hosts are fundamentally Linux, although various >>> distros - Fedora, Android, Chromecast and Chrome OS.) >>=20 >> As has been repeatedly pointed out to you, the use in your home does = not >> constitute a comprehensive study of all possible or even all likely = environments. >=20 > I never claimed it was. >=20 > It is operational experience with ULAs in one type of environment, and > it is a piece of empirical evidence that seems to disprove your > assertions that ULAs will only cause trouble. I never said they would ONLY cause trouble=E2=80=A6 I stated that they = do in some environments cause trouble. You continue to assert that they won=E2=80=99t cause = trouble contrary to my own personal operational experience. >> I have had multiple issues with source address selection in IPv6 in = my environment, >> especially on Apple equipment, even without using ULA. ULA would only = make >> the problem 10x worse. >>=20 >>> More recently, anybody who has been running IPv6 on OpenWRT since >>> BarrierBreaker 14.07, released on 30th of September 2014, has had an >>> ULA prefix automatically generated and announced to hosts on the LAN >>> interfaces. Via a few Internet searches, I can't find any reports of >>> issues relating to OpenWRT and automatic ULAs in the last 2 years. >>=20 >> I briefly had a router that did that to my network. That option was = quickly turned >> off to resolve the myriad problems it created. Subsequently, that = router was >> abandoned in favor of a router I didn=E2=80=99t have to keep beating = about the head >> and shoulders to prevent it from damaging the network in unexpected = ways. >>=20 >=20 > "your home does not constitute a comprehensive study of all possible > or even all likely environments.=E2=80=9D Sure, but it does disprove your claim that ULA is harmless. Owen --Apple-Mail=_89676796-127D-4BF8-AD28-E51EA701E695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 15, 2015, at 02:11 , Mark Smith <markzzzsmith@gmail.com> wrote:

    On 14 Nov 2015 14:19, "Owen DeLong" = <owen@delong.com> wrote:


    I=E2=80=99m all for providing a lower cost = alternative to having a legitimate registry
    for addresses = for smaller users.


    Zero cost is what is needed.

    I think a nominal fee (say US$25/year) wouldn=E2=80=99t = represent a significant barrier.


    It's $25 p.a. that can't = be spent on something else.


    You = can only charge money for magic numbers because of the magic, not

    the numbers. The numbers themselves are free, because anybody = can make
    them up.

    The magic = you're buying or renting when you get RIR space is:

    - actively managed global uniqueness (although not = absolutely
    guaranteed, because of the human error = factor)

    To the best of my = knowledge there are all of 3 instances of non-uniqueness
    temporarily resulting from such errors in all of internet = history and all in IPv4
    or ASNs.

    - implicit = acceptance of routes for that space by networks that carry
    the DFZ route table

    Really? I don=E2=80=99t think so.


    Why = not?

    RIRs issue lots = of space that may or may not get accepted by any given service = provider.

    There is nothing inherent = in getting an allocation/assignment from an RIR that = guarantees
    you or even implies you will necessarily get a slot = in any particular provider=E2=80=99s routing table.

    True, it=E2=80=99s more likely than if you just = make up random numbers, but it=E2=80=99s just more likely.


    The first property is really a requirement and necessity = demanded by

    the second one.

    Certainly the second cannot function with the first, yes, but = the first
    property is oh so desirable for so many other = reasons.


    I agree, which is why I think ULAs are much = better than site-locals.

    I fail to = see the need or usefulness of either, TBH.


    If people don't need the magic of implicit acceptance in the = DFZ, why
    should they have to pay for it? That is the = unnecessary tax or cost on
    enabling IPv6 that you're = creating by saying people should be required
    to use RIR = space, even if they have no intention of having the
    corresponding local address space routes in the DFZ.

    If it isn=E2=80=99t connecting to = the global internet than it doesn=E2=80=99t matter what numbers
    you make up or whether they are unique or how you go about = making them
    up. It=E2=80=99s not stealing space, it=E2=80=99= s just using random numbers that aren=E2=80=99t actually
    internet addresses because you happen to be running the same = protocol on
    your disconnected network as most networks run = on the internet.

    If people later need the magic of implicit acceptance in the = DFZ, they
    can get PA or PI, and most importantly add it to = their existing ULA
    addressed network.

    With all the attendant problems = that have been repeatedly discussed.


    Can you enumerate them for = me please?

    Review the = record. They=E2=80=99ve been well documented and relate mainly to the = fact that
    most code is not well suited to having the host be = multihomed and the APIs provide
    poor concepts of application = source address selection and the operating system
    mechanisms = such as they are are generally poorly implemented and even less = well
    understood by administrators and end users that need = them.



    Renumbering is not = required to add PA/PI, and that is where IPv6
    provides a = much better alternative than IPv4 - IPv4 demanded an
    exclusive or between PA/PI address space and RFC1918s, and = RFC1918s
    were perceived to be cheaper and easier for a = variety of reasons,
    including because a 'magic translation = box' could be used between
    RFC1918s and PA/PI needed to = reach the Internet.

    I can put = an RFC1918 address and a GUA IPv4 address on the same
    interface on any modern host as well. This is no different = from IPv6.


    *You* can put two addresses on a interface. = DHCPv4 can't, and the
    protocol stack treats the = addresses/subnets as though they were
    assigned to different = interfaces/links.

    Depends on the = implementation, though I agree about DHCPv4, but that=E2=80=99s = not
    an inherent property of IPv4, that=E2=80=99s a limitation = baked into the IPv4 implementation
    of DHCP. In fact, if we = taught hosts how to understand it, DHCPv4 could = supply
    additional addresses in an option field fairly easily = and the hosts could easily
    apply them to = interfaces.

    There is no meaningful = difference in this regard. ULA is just RFC1918
    with more = addresses available for stupid host tricks.

    In other words, in IPv4 = we're forced into serial address spaces, where
    as in IPv6 = we have the opportunity for multiple parallel ones.

    This statement is not reality on = any modern system.


    See above.

    Stating it again doesn=E2=80=99t make it any less = incorrect.

    Humans don't incur costs on themselves unless they see or = perceive
    some equivalent benefit. Making something = available for "free", in
    this case a local yet globally = unique network address space,
    significantly lowers the = barrier to IPv6 adoption. If you've bought
    the equipment = to build your network, and it comes IPv6 enabled for
    "free",= you can then immediately build an IPv6 network using ULA
    spa

    Except that ULA isn=E2=80=99= t globally unique, it=E2=80=99s just =E2=80=9Cprobably unique=E2=80=9D = for various
    relatively high values of =E2=80=9Cprobably=E2=80= =9D depending on how you go about choosing
    your ULA = prefix. Were ULA globally unique, you=E2=80=99d have the double edge = sword
    of:

          1. =      It=E2=80=99s good because it=E2=80=99s = free PI address space.

    It = isn't "free PI address space", because it doesn't have the magic
    that real PI address space has - implicit acceptance by all = carriers
    of the DFZ route table.

    Neither does real PI space. This = is a figment of your imagination.


    "Implicit" is a form of = the word "implied". Implied doesn't guarantee
    they will be accepted by all networks carrying = DFZs. It means of all
    of the IPv6 address space, = PI is most likely to be accepted by
    networks carrying DFZ, because most people who = carry DFZ routes have a
    default accept policy, and = only drop a small subset of routes (their
    own PI/PA etc.)

    In fact, most of them will also accept a fair amount of = bogus space if you put it within
    the right range. Making sure = it is real PI doesn=E2=80=99t come with any magic. Making it = less
    likely to conflict with real PI may remove some perceived = magic, but that=E2=80=99s not the
    same thing.



    The only similar properties between PI and ULAs are the
    (statistical/managed) global uniqueness.

    Not at all true=E2=80=A6

    In fact, those are arguably the only = differences.

    They are both prefixes of 128 = bit numbers, usually in /48 chunks.
    They are both intended = for numbering interfaces on devices running the IPv6 protocol.
    They are both capable of being forward by routers.
    Both can be described and routes distributed via OSPFv3, = ISIS, and BGPv4.

    The only real difference = between ULA and PI is the convention of not routing
    ULA = across borders where administrators choose to enforce and/or abide by
    said convention and the fact that anyone can make up whatever = ULA address
    they want, where there is an expectation that = PI is coordinated through an RIR,
    though there is enough = history of hijacking in IPv4 prefixes that I see no reason
    to believe this will not occur with IPv6.

          2. =      It=E2=80=99s bad because it=E2=80=99s a = free end-run around the RIR policy processes.

    Not if you can't successfully get = it globally routed.

    I assert = that this is simply a matter of the right number of =E2=80=9Cwombats=E2=80= =9D placed
    in the right pockets. (To use a term coined by = Jan Zorz).


    And it would be a terrible way to spend your = "wombats=E2=80=9D.

    Perhaps, but = that doesn=E2=80=99t mean there won=E2=80=99t come a day when someone = chooses to do so.

    Here's the challenge for you. Show us how easy it is for you = to get a
    ULA of your choosing permanently accepted in all = ASes who accept the
    DFZ route table, at a cost and effort = that is lower than using RIR PI
    space instead.

    The cost for the first people to = do it will be extraordinarily high.

    Right. That creates a massive incentive to use = the much cheaper RIR PI
    space to more easily and = quickly achieve the same goal.

    Thus = obviating the need to have ULA in the first place.

    As it becomes
    more common practice, the = price will drop.

    If at a later date a ULA addressed network connects to the = Internet
    they would add PA or PI space to be able to = access external
    destinations, because IPv6 is designed to = fully support parallel
    address spaces (i.e., so having = ULAs on your network doesn't
    automatically imply using = NAT66).

    Except for all the = problems previously noted in such installations with various
    issues around source address selection, etc.


    I've been running ULAs here at = home more than 4 years, both with 6to4
    IPv6 connectivity, = and for the last 4 years native connectivity. I
    haven't = seen any issues, or if there have been any, they've been
    overcome transparently via such things as Happy Eyeballs. = (with the
    caveat that all my hosts are fundamentally = Linux, although various
    distros - Fedora, Android, = Chromecast and Chrome OS.)

    As = has been repeatedly pointed out to you, the use in your home does not
    constitute a comprehensive study of all possible or even all = likely environments.

    I never claimed it was.

    It is operational experience with ULAs in one = type of environment, and
    it is a piece of empirical = evidence that seems to disprove your
    assertions that ULAs will only cause = trouble.

    I never said = they would ONLY cause trouble=E2=80=A6 I stated that they do in some = environments
    cause trouble. You continue to assert that they = won=E2=80=99t cause trouble contrary to my own
    personal = operational experience.

    I have had multiple = issues with source address selection in IPv6 in my environment,
    especially on Apple equipment, even without using ULA. ULA = would only make
    the problem 10x worse.

    More recently, anybody = who has been running IPv6 on OpenWRT since
    BarrierBreaker = 14.07, released on 30th of September 2014, has had an
    ULA = prefix automatically generated and announced to hosts on the LAN
    interfaces. Via a few Internet searches, I can't find any = reports of
    issues relating to OpenWRT and automatic ULAs = in the last 2 years.

    I briefly = had a router that did that to my network. That option was quickly = turned
    off to resolve the myriad problems it created. = Subsequently, that router was
    abandoned in favor of a = router I didn=E2=80=99t have to keep beating about the head
    and shoulders to prevent it from damaging the network in = unexpected ways.


    "your home does not constitute a comprehensive = study of all possible
    or even all likely = environments.=E2=80=9D

    Sure, but it does disprove your claim that ULA is = harmless.

    Owen

    = --Apple-Mail=_89676796-127D-4BF8-AD28-E51EA701E695-- From nobody Mon Nov 16 12:04: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 789701A8949 for ; Mon, 16 Nov 2015 12:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 qEOlwK6HYs1k for ; Mon, 16 Nov 2015 12:04:52 -0800 (PST) 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 372031A8948 for ; Mon, 16 Nov 2015 12:04:52 -0800 (PST) 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 tAGK4s2u030761; Mon, 16 Nov 2015 12:04:54 -0800 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGK4nmq030727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 12:04:49 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.120]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 12:04:45 -0800 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Mukom Akong T." Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6LeFYwgAa8AYCAAeLTIIAJg1aAgAFM4PCAAMIOAP//e67w Date: Mon, 16 Nov 2015 20:04:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4D137@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> <2134F8430051B64F815C691A62D9831832F4CE72@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="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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 20:04:53 -0000 Hi Hemant, > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Monday, November 16, 2015 11:52 AM > To: Templin, Fred L; Mukom Akong T. > Cc: v6ops@ietf.org > Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabil= ity discussion] >=20 > Fred, >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Monday, November 16, 2015 11:42 AM > To: Hemant Singh (shemant); Mukom Akong T. > Cc: v6ops@ietf.org > Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabil= ity discussion] >=20 > >- Node N receives a /64 prefix delegation for prefix P over interface et= h0. > >- N assigns P to the lo interface as a /64 route. This is done to black-= hole > > unused portions of P. > >- N configures address A from prefix P, and assigns it to eth0. >=20 > If A from prefix P is assigned to eth0, we have violated rfc3633 which sa= ys to not assign any IPv6 address on the port on which the > node received the PD from. Did I miss anything? Section 12.1 of RFC3633 says: "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router." and what I am suggesting agrees with this requirement. I am talking about assigning *addresses* (not prefixes or subnets), and the document does not say that an address cannot be assigned to the link through which the DHCP message was received. Thanks - Fred fred.l.templin@boeing.com > Hemant >=20 From nobody Mon Nov 16 12: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 B25BE1B30CE for ; Mon, 16 Nov 2015 12:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 rRdjDzJSXen5 for ; Mon, 16 Nov 2015 12:12:51 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF551B30D4 for ; Mon, 16 Nov 2015 12:12:49 -0800 (PST) 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 tAGKBkVR020638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:11:47 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <56489030.2010808@si6networks.com> Date: Mon, 16 Nov 2015 12:11:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <77C3DF92-3F81-4BEB-AF36-C923636A9383@delong.com> References: <564537A7.90102@si6networks.com> <56455ACD.6040804@si6networks.com> <56489! 030.2010808@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 20:12:52 -0000 >>> If a network has a policy of only allowing outgoing connections, = then >>> any workaround to do that is an attack on that policy. And=20 >>> making.that workaround more difficult can thus be seen as a feature. >>=20 >> Such a policy is misguided >=20 > Says who? It's the policy that is being enforced. Period. The author of that post for one. Me for another. >=20 >=20 >> because it ignores the reality that today=20 >> outgoing connections are just as dangerous as incoming ones, if not=20= >> more. >=20 > I disagree. Your claim can be correct for an enterprise with BYOD. BUt > it is certainly not true for virtually every home network where a = number > of devices are attached to it -- possibly un-updated, with bad = defaults, > etc. It absolutely is even more true in that case because if you allow those hosts to make outbound connections, nothing prevents them from = initiating a TCP-based tunnel to a BOT CNC center which then fully opens inbound access for exploitation regardless of NAT, diode firewall, or anything = else. This has happened more than once and you know it. QED. > In any case it's possible to DoS a device with a single packet, or > worse, that you can root a device with a single packet (see one of the > few openbsd remotely exploitable vulns, alas IPv6-based), a diode > firewall would prevent such devices from being owned from the = Internet. No=E2=80=A6 It just _MAY_ add to the steps necessary to do so. See = above. > (Not to mention reflection attacks, etc.) >=20 > This doesn't mean "yeah.. there couldn't be nothing evil inside", but = is > rather along the lines of the principle of "least privilege" applied = in > security -- "if I don't need something for ding what I need to do, = then > I get read of it"... whether that's superuser privileges, or > connectivity privileges. Sort of, but there are other ways to achieve the same effect which do a better job of accounting for the dangers of outbound connections as well. > Yes... in general, your ability to play with my network is at odds = with > my network's security. Sure, but the assumption that this relates to which direction = connections are allowed to be initiated is fundamentally flawed. Owen From nobody Mon Nov 16 12:15: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 8D8741B30CF for ; Mon, 16 Nov 2015 12:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 0Fq6jQ8d5994 for ; Mon, 16 Nov 2015 12:15:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC7B1B30E3 for ; Mon, 16 Nov 2015 12:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=995; q=dns/txt; s=iport; t=1447704894; x=1448914494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MJ1CbB+tj2L+J4jcyEcce5Qu2w3Vemxo8R30B6/J1Jg=; b=AFz6uo8opy/tNlK8LLvG/+309nbKgZFzvIpOY2hSkfJRMes3ZKKJayIq lb/AJgS+55YsHtF3hnoep7PSVBRZv2UO19ObJzvnG3AerAB9pyJlGl0si crCJO5gfStTYI0jd1NKF+aq7IghqAdH4OoFHgfpRr4tYK/pJGx4JH0cux o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgDuN0pW/5xdJa1dgzuBQga+WgENg?= =?us-ascii?q?WWGEAKBRzgUAQEBAQEBAYEKhDQBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQBDQU?= =?us-ascii?q?IiCa7GgEBAQEBAQEBAQEBAQEBAQEBAQEBARiLUok5AQSWSAGNH4FilniDcQEfA?= =?us-ascii?q?QFChARyAYQCgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,304,1444694400"; d="scan'208";a="208807145" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2015 20:14:53 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAGKErPC001732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2015 20:14:53 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 Nov 2015 15:14:52 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Mon, 16 Nov 2015 15:14:52 -0500 From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Mukom Akong T." Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAIkUDwgAI3wAD//+CA4IAAWEgA//+utiA= Date: Mon, 16 Nov 2015 20:14:52 +0000 Message-ID: <71ad4618b68249fcbe2d5888c77580ca@XCH-RTP-005.cisco.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4D137@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F4D137@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.78.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 20:15:01 -0000 Fred, Ah, even I was thinking, maybe is addresses are allowed and bingo, you caug= ht it - thanks for the clarifications. Your use case looks good. Hemant -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, November 16, 2015 3:05 PM To: Hemant Singh (shemant); Mukom Akong T. Cc: v6ops@ietf.org Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availabilit= y discussion] Section 12.1 of RFC3633 says: "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router." and what I am suggesting agrees with this requirement. I am talking about a= ssigning *addresses* (not prefixes or subnets), and the document does not s= ay that an address cannot be assigned to the link through which the DHCP me= ssage was received. Thanks - Fred fred.l.templin@boeing.com From nobody Mon Nov 16 12:41: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 92D561B314B for ; Mon, 16 Nov 2015 12:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 QVQLPFBNnswz for ; Mon, 16 Nov 2015 12:41:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 195131B313C for ; Mon, 16 Nov 2015 12:41:54 -0800 (PST) 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 tAGKdno5026028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:39:49 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <564975CF.7000908@si6networks.com> Date: Mon, 16 Nov 2015 12:39:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563C7C01.6010703@foobar.org> <563FA84C.7030601@si6networks.com> <56453C96.7070509@si6netwo! rks.com> <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com> <564975C! F.7000908@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon? 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, 16 Nov 2015 20:41:57 -0000 >>>> In the case of a NAT, however (more specifically a NAPT), it is not >>>> possible to program multiple port 80 terminations to land on = different >>>> hosts behind the NAT. >>>=20 >>> That's like saying that the problem with cars is that they cannot = fly -- >>> yes, that's what a NAT is. >>=20 >> Well=E2=80=A6 That is certainly a limitation of most automobiles, but = I=E2=80=99m happy to >> report that there are working alternatives such as the Terrafugia = Transition >> and some older prototypes as well. >=20 > Then that's not a car. And that's my point. You're complaining about > something that is a characteristic of NAT. By what possible definition do you claim that the Terrafugia Transition is not a car? It is most certainly a car which is capable of doing all = the things a car does and is also capable of becoming an aircraft. > That said, there's no conceptual reason for which HTTP must run at = port > 80. And would be perfectly sensible to have multiple instances of > different HTTP implementations at the same host, without having to > resort to other hacks such as ip aliases. Indeed many people run HTTP on non-standard ports for a variety of = reasons and many people (myself included) run other things (such as an SSH = server) on port 80 for other reasons (after the first time I encountered an = airport lounge that thought the only internet access I could possibly need was to ports = 80 and 443, I set up an SSH server on port 80 to work around this = limitation). The problem is that there=E2=80=99s no DNS provision for A+P records or = AAAA+P records or even meaningful definitions of P records, so while it=E2=80=99s = perfectly reasonable to have http servers at [2001:db8::1]:80, [2001:db8::1]:81, =E2=80=A6, = there=E2=80=99s no good way to make www.foo.com map to [2001:db8::1]:80 and www.bar.com map to [2001:db8::1]:81 in the real world. > Again: here NATs are making it very evident that harcoding HTTP to = port > 80 comes at a price. No=E2=80=A6 They=E2=80=99re making it very evident that NAT comes at a = price and part of that price may come from the convenience of having HTTP linked to a well-known port (there=E2=80=99s nothing magic about 80). Unless you can convince client resolver libraries and applications to = make better use of SRV records, this is where we are in the real world. It wasn=E2=80=99t broken before NAT. Sure it represents certain = assumptions that can be violated and NAT most definitely violates them in an extreme way. However, it is a fundamental tenant of the architecture that I expect the devices in the network not to edit my packets, but rather to forward them without mutilation. NAT most definitely violates this and as a = result, it breaks things. Claiming that this fundamental tenant is incomplete and that NAT is not the problem is like claiming that it would be OK to introduce a square ball into a basketball game, claiming that the fact the hoops are round is a design flaw in the hoop. > You don't want a full directory service? -- Fine... then pay the price > for taking a shortcut. I want a directory service that is adequate to the task. DNS does that (mostly) and this is certainly not one of the areas where I consider it to be meaningfully deficient. The fact that NAT makes this capability more necessary than the network without NAT does not make NAT inherently acceptable. >>> I might also add that this is another kludge that is made evident by >>> NAT: there's no reason whatsoever for which a given service should = run >>> in any specific transport protocol port. Consider that a kludge or >>> shortcut than a principle. >>=20 >> Meh=E2=80=A6 There=E2=80=99s no mechanism available for signaling = port numbers in response >> to name lookups (modulo SRV records that don=E2=80=99t seem to be = very popular in >> practice).=20 >=20 > As you note, there is: SRV. >=20 > Regarding popularity, when did popularity became a metric of = correctness? It=E2=80=99s not a metric of correctness, but it is a metric of = acceptance and more importantly, a metric of usefulness. Clearly SRV has not been deemed adequately useful to achieve wide-spread = support in client software. >> There are certain advantages to the idea of well known port numbers >> and whether or not you consider them a kludge, they are certainly in = widespread >> use and have a great deal of history and support in the IETF and = IANA. >=20 > Can we have a technical discussion, please? >=20 > I'm arguing that there are many pieces of the puzzle missing, and you > answer "having a full puzzle is not popular.. besides, everyone loves > it, and we have done it for a long time=E2=80=9D. You=E2=80=99re arguing that NAT isn=E2=80=99t broken and/or doesn=E2=80=99= t break things, but rather that the design assumptions in the internet are what is broken and NAT = being not broke proves it. It was never a technical discussion on either side. It has inherently = been your religious support of diode firewalls and NAT that has driven it away = from a technical discussion from the beginning. > That's like arguing that McDonald's sells quality beef because their > restaurants are usually crowded, and Mc has made a lot of profit for = years. No, it=E2=80=99s like arguing that Fred=E2=80=99s Burgers is probably = not going to succeed since there=E2=80=99s never anybody in their restaurants. I=E2=80=99m not arguing that the popularity of the present system makes = it not broken. I=E2=80=99m arguing that solutions which do not achieve adoption are not = solutions. > McD might make a lot of money. There might be certain advantages of > eating at McD (price (in some countries), timeliness, or whatever). = But > that doesn't make a Big Mac good beef. Depends on where you go=E2=80=A6 In Moscow, the McDonald=E2=80=99s = actually does use decent beef (or at least did the last time I ate there in 1993). Normally I=E2=80=99m not a fan of the golden arches, but it was what was = open at this particular hour and I was pleasantly surprised how much higher the quality of the food was compared to US operations. However, that=E2=80=99s a side issue. The simple reality is that arguing that everyone should eat soy tofu = burgers because beef burgers are somehow inadequate or soy burgers are healthier or whatever doesn=E2=80=99t seem to change the fact that people like = beef and will go to McDonald=E2=80=99s or wherever else and nobody goes to the Soy = Burger Drivethru. When was the last time you saw a Soy Burger Drivethru = restaurant? If you=E2=80=99re wondering why, it=E2=80=99s because when nobody buys = your =E2=80=9Csolution=E2=80=9D, then your solution clearly didn=E2=80=99t solve anything. Owen From nobody Mon Nov 16 12:48: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 D9A6F1B315E for ; Mon, 16 Nov 2015 12:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.685 X-Spam-Level: X-Spam-Status: No, score=-6.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 L4vphPnY2yI3 for ; Mon, 16 Nov 2015 12:48:18 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA1E1B315D for ; Mon, 16 Nov 2015 12:48:18 -0800 (PST) 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 tAGKjDle026606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:45:14 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_3B720431-2620-491C-ACAB-E2E6CDA2BD16" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 16 Nov 2015 12:45:13 -0800 Message-Id: <8ADBFD2C-6FEC-4305-93A1-8B4AAEC2277C@delong.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.b! oeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 20:48:21 -0000 --Apple-Mail=_3B720431-2620-491C-ACAB-E2E6CDA2BD16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > This is starting to diverge from the case I originally intended this = discussion to > examine. The case I am interested in is as follows: >=20 > - Node N receives a /64 prefix delegation for prefix P over interface = eth0. > - N assigns P to the lo interface as a /64 route. This is done to = black-hole > unused portions of P. > - N configures address A from prefix P, and assigns it to eth0. N inherently cannot do this because ETH0 is the interface on which it = received the DHCPv6 PD delegation of the /64 in question. Therefore it volates: > [the requesting router MUST NOT assign any delegated prefixes or = subnets from the delegated prefix(es) to the link through which it > received the DHCP message from the delegating router.] > - N need not perform DAD for A over eth0, because the delegating = router > has made sure that the routing system will route all packets with a > destination address from P to node N, and not to any other node. In any case, N should not perform DAD for A over eth0 because A is not = assigned to eth0. However, I=E2=80=99m not sure how one can claim that a delegating router = can ensure anything about the behavior of other routers in the routing system. It=E2=80=99s unclear to me why A would assign P to eth0 anyway. Why not = just have the delegating router assign addresses to other hosts on eth0? Why would A act as a = gateway leading to the delegating router on the same subnet? I am finding your example more confusing that perhaps is intended. Owen >=20 > In this way, N can function as an ordinary host according to the = strong end > system model even though it acted as a "requesting router" in = procuring a > prefix from the delegating router. No other node X on the same link as > N can therefore configure an address from P and have the routing = system > return packets to X. In fact, any node X that configures an address = from P > can be considered an "attacker", and the use or non-use of DAD has no > way of preventing that. In fact, the use of DAD could give X a clue as = to > which addresses from P are ripe for attacking. So, it is in fact = better to > NOT do DAD. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> Hemant >>=20 >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_3B720431-2620-491C-ACAB-E2E6CDA2BD16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    This is starting to diverge from the case I = originally intended this discussion to
    examine. The case I am interested in is as = follows:

    - Node N receives a /64 = prefix delegation for prefix P over interface eth0.
    - N assigns P to the lo interface as a /64 = route. This is done to black-hole
      unused portions of P.
    - N configures address A from prefix P, and = assigns it to eth0.

    N inherently = cannot do this because ETH0 is the interface on which it received the = DHCPv6 PD
    delegation of the /64 in question.

    Therefore it volates:

    [the requesting router MUST NOT = assign any delegated prefixes or subnets from the delegated prefix(es) = to the link through which it
    received the DHCP message = from the delegating router.]


    - N need not = perform DAD for A over eth0, because the delegating router
      has made sure that the routing = system will route all packets with a
      destination address from P to node = N, and not to any other node.

    In any = case, N should not perform DAD for A over eth0 because A is not assigned = to eth0.

    However, I=E2=80=99m not = sure how one can claim that a delegating router can ensure = anything
    about the behavior of other routers in the routing = system.

    It=E2=80=99s unclear to me = why A would assign P to eth0 anyway. Why not just have the = delegating
    router assign addresses to other hosts on eth0? Why = would A act as a gateway leading to
    the delegating router on = the same subnet?

    I am finding your = example more confusing that perhaps is intended.

    Owen


    In this way, N can function as an ordinary host = according to the strong end
    system model even though = it acted as a "requesting router" in procuring a
    prefix from the delegating router. No other node = X on the same link as
    N can therefore configure = an address from P and have the routing system
    return packets to X. In fact, any node X that = configures an address from P
    can be considered an = "attacker", and the use or non-use of DAD has no
    way of preventing that. In fact, the use of DAD = could give X a clue as to
    which addresses from P are = ripe for attacking. So, it is in fact better to
    NOT do DAD.

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

    Hemant




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

    = --Apple-Mail=_3B720431-2620-491C-ACAB-E2E6CDA2BD16-- From nobody Mon Nov 16 12:55: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 E2CA61B3168 for ; Mon, 16 Nov 2015 12:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.685 X-Spam-Level: X-Spam-Status: No, score=-6.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 VqAnQ5ALmiq0 for ; Mon, 16 Nov 2015 12:55:02 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 529C41B3169 for ; Mon, 16 Nov 2015 12:55:02 -0800 (PST) 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 tAGKpvE6027030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:51:57 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_876C6E88-3536-45D3-82AD-E6174CD2A471" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <2134F8430051B64F815C691A62D9831832F4D137@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 16 Nov 2015 12:51:56 -0800 Message-Id: References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com> <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.b! oeing.com> <2134F8430051B64F815C691A62D9831832F4D137@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 16 Nov 2015 20:55:04 -0000 --Apple-Mail=_876C6E88-3536-45D3-82AD-E6174CD2A471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 16, 2015, at 12:04 , Templin, Fred L = wrote: >=20 > Hi Hemant, >=20 >> -----Original Message----- >> From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >> Sent: Monday, November 16, 2015 11:52 AM >> To: Templin, Fred L; Mukom Akong T. >> Cc: v6ops@ietf.org >> Subject: RE: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >>=20 >> Fred, >>=20 >> -----Original Message----- >> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >> Sent: Monday, November 16, 2015 11:42 AM >> To: Hemant Singh (shemant); Mukom Akong T. >> Cc: v6ops@ietf.org >> Subject: RE: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion] >>=20 >>> - Node N receives a /64 prefix delegation for prefix P over = interface eth0. >>> - N assigns P to the lo interface as a /64 route. This is done to = black-hole >>> unused portions of P. >>> - N configures address A from prefix P, and assigns it to eth0. >>=20 >> If A from prefix P is assigned to eth0, we have violated rfc3633 = which says to not assign any IPv6 address on the port on which the >> node received the PD from. Did I miss anything? >=20 > Section 12.1 of RFC3633 says: >=20 > "the requesting router MUST > NOT assign any delegated prefixes or subnets from the delegated > prefix(es) to the link through which it received the DHCP message > from the delegating router.=E2=80=9D I would argue that an address from within the prefix constitutes the = same thing as a prefix in this context. Even if it is a /128 prefix. Owen --Apple-Mail=_876C6E88-3536-45D3-82AD-E6174CD2A471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Nov 16, 2015, at 12:04 , Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

    Hi Hemant,

    -----Original = Message-----
    From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
    Sent: Monday, = November 16, 2015 11:52 AM
    To: Templin, Fred L; Mukom = Akong T.
    Cc: v6ops@ietf.org
    Subject: RE: [v6ops] DAD = again [was: draft-ietf-v6ops-host-addr-availability discussion]

    Fred,

    -----Original= Message-----
    From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
    Sent: = Monday, November 16, 2015 11:42 AM
    To: Hemant Singh = (shemant); Mukom Akong T.
    Cc: v6ops@ietf.org
    Subject: RE: [v6ops] DAD again [was: = draft-ietf-v6ops-host-addr-availability discussion]

    - Node N receives a /64 = prefix delegation for prefix P over interface eth0.
    - N = assigns P to the lo interface as a /64 route. This is done to = black-hole
     unused portions of P.
    - N = configures address A from prefix P, and assigns it to eth0.

    If A from prefix P is assigned to = eth0, we have violated rfc3633 which says to not assign any IPv6 address = on the port on which the
    node received the PD from. =  Did I miss anything?

    Section 12.1 of RFC3633 says:

      "the requesting router = MUST
      NOT assign any = delegated prefixes or subnets from the delegated
      prefix(es) to the link through which = it received the DHCP message
      from the = delegating router.=E2=80=9D

    I would argue that an address from within the prefix = constitutes the same thing as a prefix in this context.

    Even if it is a /128 prefix.

    Owen

    = --Apple-Mail=_876C6E88-3536-45D3-82AD-E6174CD2A471-- From nobody Mon Nov 16 14:15: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 3ECD01A013F for ; Mon, 16 Nov 2015 14:15:17 -0800 (PST) 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 g2V1GKjmCfw2 for ; Mon, 16 Nov 2015 14:15:14 -0800 (PST) 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 E90601A00A0 for ; Mon, 16 Nov 2015 14:15:13 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZyS3J-0000CGC; Mon, 16 Nov 2015 23:15:09 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4CFA6@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Mon, 16 Nov 2015 18:12:18 +0000 ." <2134F8430051B64F815C691A62D9831832F4CFA6@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 16 Nov 2015 23:14:59 +0100 Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 22:15:17 -0000 >> I wonder if A should then always set the Router flag in neighbor advertis= >ements >> as well. It looks like it has to, otherwise the neighbor cache will be >> flushed. > >Section 8.3 of RFC4861 says: > > "If the Target and Destination Addresses are the same, the host MUST > treat the Target as on-link. If the Target Address is not the same > as the Destination Address, the host MUST set IsRouter to TRUE for > the target. If the Target and Destination Addresses are the same, > however, one cannot reliably determine whether the Target Address is > a router. Consequently, newly created Neighbor Cache entries should > set the IsRouter flag to FALSE, while existing cache entries should > leave the flag unchanged. If the Target is a router, subsequent > Neighbor Advertisement or Router Advertisement messages will update > IsRouter accordingly." > >and Appendix D. of RFC4861 says: > > " - The target of the redirect, when the target is the same as the > destination, does not carry any host vs. router information. All > that is known is that the destination (i.e., target) is on-link > but it could be either a host or a router." > >In this case, the Target and Destination Address are the same. So, there is >no host vs. router information, and the default value for isRouter is FALSE= Target and Destination are the same if the router sending the redirect considers the Destination to be on-link. Given that the router has a link local next hop, I wonder if that's the case. In general after prefix delegation, the delegating router is supposed to assume that the prefix is not on-link but used on other links. From nobody Mon Nov 16 14:24:14 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 72E021A046D; Mon, 16 Nov 2015 14:24:12 -0800 (PST) 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.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151116222412.3788.21948.idtracker@ietfa.amsl.com> Date: Mon, 16 Nov 2015 14:24:12 -0800 Archived-At: Cc: draft-ietf-v6ops-reducing-ra-energy-consumption@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-reducing-ra-energy-consumption.all@tools.ietf.org Subject: [v6ops] Stephen Farrell's Yes on draft-ietf-v6ops-reducing-ra-energy-consumption-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: Mon, 16 Nov 2015 22:24:12 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-v6ops-reducing-ra-energy-consumption-03: 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-reducing-ra-energy-consumption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like this kind of thing, thanks! Is the implication of 5.1, bullet 1 that devices are listening but check the RA information before deciding to wake the main CPU or not? I'd say a reference to some description of that kind of implementation would be a useful thing to add. It'd be good to see a response to the secdir review, [1] which raised a couple of minor points. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06122.html From nobody Mon Nov 16 15:09: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 2E4BF1A8A3C for ; Mon, 16 Nov 2015 15:09:23 -0800 (PST) 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 9Ajaupc6b14I for ; Mon, 16 Nov 2015 15:09:21 -0800 (PST) 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 B667A1A89EB for ; Mon, 16 Nov 2015 15:09:21 -0800 (PST) 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 tAGN9Krq038149; Mon, 16 Nov 2015 16:09:20 -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 tAGN9A9u037737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 16:09:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.18]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 15:09:09 -0800 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] Thread-Index: AQHRIJpUsgni8VUg+0O8njNAhlteCp6fN14+gAANn9A= Date: Mon, 16 Nov 2015 23:09:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4D4C5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4CFA6@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 16 Nov 2015 23:09:23 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Monday, November 16, 2015 2:15 PM > To: v6ops@ietf.org > Cc: Templin, Fred L > Subject: Re: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr= -availability discussion] ] >=20 > >> I wonder if A should then always set the Router flag in neighbor adver= tis=3D > >ements > >> as well. It looks like it has to, otherwise the neighbor cache will be > >> flushed. > > > >Section 8.3 of RFC4861 says: > > > > "If the Target and Destination Addresses are the same, the host MUST > > treat the Target as on-link. If the Target Address is not the same > > as the Destination Address, the host MUST set IsRouter to TRUE for > > the target. If the Target and Destination Addresses are the same, > > however, one cannot reliably determine whether the Target Address is > > a router. Consequently, newly created Neighbor Cache entries should > > set the IsRouter flag to FALSE, while existing cache entries should > > leave the flag unchanged. If the Target is a router, subsequent > > Neighbor Advertisement or Router Advertisement messages will update > > IsRouter accordingly." > > > >and Appendix D. of RFC4861 says: > > > > " - The target of the redirect, when the target is the same as the > > destination, does not carry any host vs. router information. All > > that is known is that the destination (i.e., target) is on-link > > but it could be either a host or a router." > > > >In this case, the Target and Destination Address are the same. So, there= is > >no host vs. router information, and the default value for isRouter is FA= LSE=3D >=20 > Target and Destination are the same if the router sending the redirect > considers the Destination to be on-link. >=20 > Given that the router has a link local next hop, I wonder if that's the > case. > > In general after prefix delegation, the delegating router is supposed to > assume that the prefix is not on-link but used on other links. Yes, you are right; the target address will be the link-local address of N on the eth0 link, and the destination address will be A. So, to the outside world, N would look like a router. Do you see a problem with that? Thanks - Fred fred.l.templin@boeing.com From nobody Mon Nov 16 17:46: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 F32271ACCEC for ; Mon, 16 Nov 2015 17:46:05 -0800 (PST) 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 5mnMYSHYIK24 for ; Mon, 16 Nov 2015 17:45:58 -0800 (PST) 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 400591ACCE1 for ; Mon, 16 Nov 2015 17:45:58 -0800 (PST) Received: by pabfh17 with SMTP id fh17so196479797pab.0 for ; Mon, 16 Nov 2015 17:45:58 -0800 (PST) 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=SJ392rdrTO9GpDiJb1TqhdQUtNpwUpbriLmxWyRw7/U=; b=yeiXSc5hukk7m+ldFwS7AJvtmuuTvlz4VyArYgBjUp5nUiJ6wBx0K8zioeuKlRCYIx t5KZwC066r/RxJQvLcTDLv4D6cRspJnudlMj5UVDoMgUgtR5Zlwp322BIJbkAg19NIDR 05UpcUEbjIwcDt6QYiR71PCnTn5yWUl+QIx3i+xQhliHRGywj6z1S9usM0rgj8C2VzYp PV2W/73pA97LQNJ0+ntha1dcdeeTXhGFsV7Fc09voCqMjCfYrRDvzs475tYaJaTb/zOS ajj5o35hMc7HqIIHOFC09V/tvs7/J8kUjLORqXNCRa8LBo03zSYebyzMPnOrA3PL3dvN VaIw== X-Received: by 10.66.221.105 with SMTP id qd9mr59981925pac.46.1447724757850; Mon, 16 Nov 2015 17:45:57 -0800 (PST) Received: from [10.0.3.190] ([97.65.203.35]) by smtp.gmail.com with ESMTPSA id d7sm39089083pas.31.2015.11.16.17.45.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Nov 2015 17:45:56 -0800 (PST) To: "Templin, Fred L" , Lorenzo Colitti References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <564A86D3.6050708@gmail.com> Date: Tue, 17 Nov 2015 14:45:55 +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: <2134F8430051B64F815C691A62D9831832F3A88F@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" Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 17 Nov 2015 01:46:06 -0000 I guess I've been puzzling over this for ten days, but the PD discussion made me think about it again. Read to the end to reload the context and seem my comment: On 04/11/2015 11:37, Templin, Fred L wrote: > Hi Brian, >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Tuesday, November 03, 2015 1:47 PM >> To: Templin, Fred L; Lorenzo Colitti >> Cc: v6ops@ietf.org >> Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability discu= ssion] >> >> Hello Fred, >> >> On 03/11/2015 20:10, Templin, Fred L wrote: >>> Hi Brian, >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Monday, November 02, 2015 6:55 PM >>>> To: Templin, Fred L; Lorenzo Colitti >>>> Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discuss= ion >>>> >>>> Hi Fred, >>>> On 03/11/2015 14:59, Templin, Fred L wrote: >>>>> Hi Brian, >>>>> >>>>>> -----Original Message----- >>>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>>>> Sent: Monday, November 02, 2015 5:46 PM >>>>>> To: Templin, Fred L; Lorenzo Colitti >>>>>> Cc: v6ops@ietf.org >>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discu= ssion >>>>>> >>>>>> On 03/11/2015 14:31, Templin, Fred L wrote: >>>>>>> Bumping up one level =E2=80=93 is it clear to everyone that it is= OK to assign addresses >>>>>>> taken from a DHCPv6 delegated prefix to the interface over which = the prefix >>>>>>> was received? >>>>>> >>>>>> If it was legitimately received, I can't see why it wouldn't be OK= =2E >>>>> >>>>> OK. When the DHCPv6 server grants a prefix delegation to the client= , >>>>> the server is asserting that that prefix is unique and is now the s= ole >>>>> property of the client. So, when you say legitimately received I >>>>> agree and that is actually a core requirement of DHCPv6 PD. >>>>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the >>>>> routing system would become hopelessly corrupted and address >>>>> duplication would be the least of our worries. >>>>> >>>>>>> And, that DAD is not required for those addresses? >>>>>> >>>>>> How is that safe? What is to stop a host running SLAAC once it >>>>>> sees that prefix in an RA, and hitting the same IID by chance? >>>>>> At least you need to specify that the A bit must not be set. >>>>> >>>>> I am talking about DAD on interface "A" being the interface over >>>>> which the client receives the prefix delegation. No other node on >>>>> interface "A" may use the delegated prefix, and no router on >>>>> interface "A" may advertise the prefix in an RA. The prefix is the >>>>> sole property of the client that received the PD, so the client is >>>>> free to assign addresses without needing DAD. >>>> >>>> That usage of "may" might confuse some people, so let's pretend >>>> you used a "MUST NOT" construct instead. I could still construct >>>> a host stack that would ignore the issue: its logic would be >>>> "I sent an RS and got no RA/PIO with A=3D1; but I see traffic from >>>> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix.= " >>> >>> The malicious (or otherwise broken) host 'A' could configure any numb= er >>> of addresses it likes, but it would do so in a vacuum because ingress= >>> filtering will prevent a packet with a source address from a prefix >>> belonging to host B from being accepted. So, node B has no reason >>> to fear address duplication by node A. >> >> I'm not sure how an ingress filter somewhere upstream would know that >> the packet came from the "wrong" host. But I don't think that's enough= ; >> a duplicate address on the LAN is already a problem in itself. >> >>> Also, what if node B in fact did do DAD and A heard it? What is to st= op >>> A from configuring a duplicate address and trying to use it just to m= ess >>> up the legitimate operation of node B? >> >> Nothing. That, I think, is why the RFCs make DAD mandatory. >> >>> >>> What you are describing is a broken implementation that could only >>> be employed by a malicious host, and not something that honors >>> the standards. >> >> I don't think it's malicious; it's just trying to get IPv6 connectivit= y >> in the face of what it sees as a broken router that isn't responding >> to RS. But that isn't really my point - my point is that whatever we >> do, it's impossible to assert that a duplicate address will never aris= e. >> >>> Doing DAD is not going to guard against malicious >>> hosts. >> >> No, but it might allow you to detect the resulting anomaly. >=20 >=20 > Actually, the simpler answer to your question is that the node would > act as a host internally, but appear to be a router on the link from an= > outside observer's perspective. And, routers do not do DAD for the > source addresses of packets that pass through them. All routers are also IPv6 nodes, and by definition have an active IPv6 interface with an address on each of their links. All IPv6 nodes are supposed to perform DAD on their addresses. RFC 4862 is clear that this applies even if SLAAC is not used: The Duplicate Address Detection algorithm is performed on all addresses, independently of whether they are obtained via stateless autoconfiguration or DHCPv6. and specifically requires routers to perform DAD: In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. In fact it's particularly important that routers detect any address collision on any of their interfaces, because downstream hosts or other routers use each address as a next hop. I can readily believe that implementations where static addresses are configured on a simple pt2pt link skip this, but doing so on a broadcast or NBMA link seems wrong to me. Brian Brian From nobody Tue Nov 17 02:57: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 9EEEE1A8AF1 for ; Tue, 17 Nov 2015 02:57:07 -0800 (PST) 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 1QtptJtgvfWl for ; Tue, 17 Nov 2015 02:57:06 -0800 (PST) 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 8F7A01A8AEC for ; Tue, 17 Nov 2015 02:57:05 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Zydwa-0000GYC; Tue, 17 Nov 2015 11:57:00 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4CFA6@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4D4C5@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Mon, 16 Nov 2015 23:09:09 +0000 ." <2134F8430051B64F815C691A62D9831832F4D4C5@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 17 Nov 2015 11:56:55 +0100 Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 10:57:07 -0000 Hi Fred, >Yes, you are right; the target address will be the link-local address of >N on the eth0 link, and the destination address will be A. So, to the >outside world, N would look like a router. Do you see a problem >with that? The problem is that other hosts will clear their destination caches if they receive a NA without the router bit set. So a host trying to communicate with an address taken from the prefix will constantly go back to the default router, get a redirect, do a neighbor discovery probe and clear the destination cache for that address. Maybe all nodes that receive a prefix using PD have to behave as routers for the purposes of (at least) ND. From nobody Tue Nov 17 03:08: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 2C17E1B2A9D for ; Tue, 17 Nov 2015 03:08:10 -0800 (PST) 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 R0Pb3wqPWv5h for ; Tue, 17 Nov 2015 03:08:08 -0800 (PST) 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 00BA71AD05B for ; Tue, 17 Nov 2015 03:08:06 -0800 (PST) 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 tAHB84lX008636 for ; Tue, 17 Nov 2015 12:08:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 076EE20A101 for ; Tue, 17 Nov 2015 12:14:22 +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 F3A5E203198 for ; Tue, 17 Nov 2015 12:14:21 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tAHB83Fi000521 for ; Tue, 17 Nov 2015 12:08:04 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <564B0A93.6010908@gmail.com> Date: Tue, 17 Nov 2015 12:08:03 +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] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 11:08:10 -0000 Le 16/11/2015 18:03, Philip Homburg a écrit : >> This is starting to diverge from the case I originally intended this discussion >> to >> examine. The case I am interested in is as follows: >> >> - Node N receives a /64 prefix delegation for prefix P over interface eth0. >> - N assigns P to the lo interface as a /64 route. This is done to black-hole >> unused portions of P. >> - N configures address A from prefix P, and assigns it to eth0. >> - N need not perform DAD for A over eth0, because the delegating router >> has made sure that the routing system will route all packets with a >> destination address from P to node N, and not to any other node. >> >> In this way, N can function as an ordinary host according to the strong end >> system model even though it acted as a "requesting router" in procuring a >> prefix from the delegating router. No other node X on the same link as >> N can therefore configure an address from P and have the routing system >> return packets to X. In fact, any node X that configures an address from P >> can be considered an "attacker", and the use or non-use of DAD has no >> way of preventing that. In fact, the use of DAD could give X a clue as to >> which addresses from P are ripe for attacking. So, it is in fact better to >> NOT do DAD. > > I have a two questions about this, sort of unrelated to DAD (so I changed the > subject). > > 1) How do packets reach the host. Is that documented somewhere? No. > I assume that in this case a router will send packets with destination > prefix P to the link local address of N. But is that specified somewhere? It is not specified. But I agree it should act as you say above. Alex > > 2) If a node M on the same ethernet link wants to communicate with address > A, it creates a destination cache entry for A picking a default router > as next hop (because P is not onlink). Later, A can send the reply > directly to M if M's address is onlink. That is likely to cause a > neighbor cache entry for A at M, which will not be used because the > destination cache entry is still in place. > > Not good if you ever want to debug something. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 17 03:09: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 4D3261B2A9D for ; Tue, 17 Nov 2015 03:09:48 -0800 (PST) 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 lkj3qOXdZZj5 for ; Tue, 17 Nov 2015 03:09:46 -0800 (PST) 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 DBAD41B2A03 for ; Tue, 17 Nov 2015 03:09:45 -0800 (PST) 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 tAHB9hgF003155 for ; Tue, 17 Nov 2015 12:09:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0D3A420A30A for ; Tue, 17 Nov 2015 12:16:01 +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 0421B20A12D for ; Tue, 17 Nov 2015 12:16:01 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tAHB9ho5001693 for ; Tue, 17 Nov 2015 12:09:43 +0100 To: v6ops@ietf.org References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <564B0AF7.4080106@gmail.com> Date: Tue, 17 Nov 2015 12:09:43 +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: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 11:09:48 -0000 Le 16/11/2015 18:26, Templin, Fred L a écrit : > Hi Philip, > >> -----Original Message----- >> From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] On Behalf Of Philip Homburg >> Sent: Monday, November 16, 2015 9:04 AM >> To: v6ops@ietf.org >> Cc: Templin, Fred L; Hemant Singh (shemant) >> Subject: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] >> >>> This is starting to diverge from the case I originally intended this discussion >>> to >>> examine. The case I am interested in is as follows: >>> >>> - Node N receives a /64 prefix delegation for prefix P over interface eth0. >>> - N assigns P to the lo interface as a /64 route. This is done to black-hole >>> unused portions of P. >>> - N configures address A from prefix P, and assigns it to eth0. >>> - N need not perform DAD for A over eth0, because the delegating router >>> has made sure that the routing system will route all packets with a >>> destination address from P to node N, and not to any other node. >>> >>> In this way, N can function as an ordinary host according to the strong end >>> system model even though it acted as a "requesting router" in procuring a >>> prefix from the delegating router. No other node X on the same link as >>> N can therefore configure an address from P and have the routing system >>> return packets to X. In fact, any node X that configures an address from P >>> can be considered an "attacker", and the use or non-use of DAD has no >>> way of preventing that. In fact, the use of DAD could give X a clue as to >>> which addresses from P are ripe for attacking. So, it is in fact better to >>> NOT do DAD. >> >> I have a two questions about this, sort of unrelated to DAD (so I changed the >> subject). >> >> 1) How do packets reach the host. Is that documented somewhere? > > RFC3633 is largely silent on this, Yes, and the forthcoming DHCPv6 update integrating PD will also be silent I believe (they try pure tex integration, little if any new text). > but when P is delegated to N, it is > implied that the delegating router must somehow inject information > into the routing system that will guide packets with destination > address A to N. Yes, I agree. Alex > >> I assume that in this case a router will send packets with destination >> prefix P to the link local address of N. But is that specified somewhere? > > That is correct, but again RFC3633 is largely silent. > >> 2) If a node M on the same ethernet link wants to communicate with address >> A, it creates a destination cache entry for A picking a default router >> as next hop (because P is not onlink). Later, A can send the reply >> directly to M if M's address is onlink. That is likely to cause a >> neighbor cache entry for A at M, which will not be used because the >> destination cache entry is still in place. > > In this instance, the default router would return a Redirect to M to inform > it that N is a better first hop for reaching address A. The Redirect would > cause M to update its destination cache accordingly. > > Thanks - Fred > fred.l.templin@boeing.com > >> Not good if you ever want to debug something. >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 17 03:11: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 CB49A1AD05B for ; Tue, 17 Nov 2015 03:11:37 -0800 (PST) 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 EFC6I2orGJJ0 for ; Tue, 17 Nov 2015 03:11:36 -0800 (PST) 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 E4A351ACF60 for ; Tue, 17 Nov 2015 03:11:35 -0800 (PST) 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 tAHBBYK3010065 for ; Tue, 17 Nov 2015 12:11:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 56A8620A32A for ; Tue, 17 Nov 2015 12:17:51 +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 4E58620A2EB for ; Tue, 17 Nov 2015 12:17:51 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tAHBBXeo003102 for ; Tue, 17 Nov 2015 12:11:33 +0100 To: v6ops@ietf.org References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <564B0B65.6080305@gmail.com> Date: Tue, 17 Nov 2015 12:11:33 +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] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 11:11:38 -0000 Le 16/11/2015 18:53, Philip Homburg a écrit : >>> 1) How do packets reach the host. Is that documented somewhere? >> >> RFC3633 is largely silent on this, but when P is delegated to N, it >> is implied that the delegating router must somehow inject >> information into the routing system that will guide packets with >> destination address A to N. > > I wonder where this should be documented. I agree it shoul dbe documented. > There seem to be some other interesting interactions: a DHCPv6 server > running on a host should not hand out a PD to a host (because it > doesn't work), but can hand it out to a router. And can hand it out > when there request comes through a relay agent. > > A relay agent running on a router should install a routing table > entry if the PD request comes from a host. Certainly yes. In the past we tried a problem statement draft about how PD impacts routing at Relay. > There might be more interesting details. Which ones? Alex > >>> 2) If a node M on the same ethernet link wants to communicate >>> with addres= >> s >>> A, it creates a destination cache entry for A picking a default >>> router as next hop (because P is not onlink). Later, A can send >>> the reply directly to M if M's address is onlink. That is likely >>> to cause a neighbor cache entry for A at M, which will not be >>> used because the destination cache entry is still in place. >> >> In this instance, the default router would return a Redirect to M >> to inform it that N is a better first hop for reaching address A. >> The Redirect would cause M to update its destination cache >> accordingly. > > I wondered about redirect just after I hit sent. The neighbor > discovery RFC is very explict about the IsRouter flag in the neighbor > cache. In this case M has to set the IsRouter flag for A. > > I wonder if A should then always set the Router flag in neighbor > advertisements as well. It looks like it has to, otherwise the > neighbor cache will be flushed. > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 17 07:39: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 ECA7A1AC42E for ; Tue, 17 Nov 2015 07:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fRXi-E-Kd_Mp for ; Tue, 17 Nov 2015 07:39:36 -0800 (PST) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752201A9136 for ; Tue, 17 Nov 2015 07:39:36 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id DFD432008F; Tue, 17 Nov 2015 16:39:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id BA6CC1A0061; Tue, 17 Nov 2015 16:39:34 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 16:39:34 +0100 From: To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] Thread-Index: AQHRISjBKXywGSjIXkWLXwLhOaFsAZ6gWXVw Date: Tue, 17 Nov 2015 15:39:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008C9F53A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> <564B0B65.6080305@gmail.com> In-Reply-To: <564B0B65.6080305@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 15:39:38 -0000 Hi Alex, all, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandre > Petrescu > Envoy=E9=A0: mardi 17 novembre 2015 12:12 > =C0=A0: v6ops@ietf.org > Objet=A0: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops- > host-addr-availability discussion] ] >=20 >=20 >=20 > Le 16/11/2015 18:53, Philip Homburg a =E9crit : > >>> 1) How do packets reach the host. Is that documented somewhere? > >> > >> RFC3633 is largely silent on this, but when P is delegated to N, it > >> is implied that the delegating router must somehow inject > >> information into the routing system that will guide packets with > >> destination address A to N. > > > > I wonder where this should be documented. >=20 > I agree it shoul dbe documented. >=20 > > There seem to be some other interesting interactions: a DHCPv6 server > > running on a host should not hand out a PD to a host (because it > > doesn't work), but can hand it out to a router. And can hand it out > > when there request comes through a relay agent. > > > > A relay agent running on a router should install a routing table > > entry if the PD request comes from a host. >=20 > Certainly yes. >=20 > In the past we tried a problem statement draft about how PD impacts > routing at Relay. [Med] Better with pointers:=20 * https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00=20 And=20 * https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03=20 From nobody Tue Nov 17 09:36: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 58FC01A6F0B for ; Tue, 17 Nov 2015 09:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 DUomSzL1eS_a for ; Tue, 17 Nov 2015 09:35:57 -0800 (PST) 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 C9BBE1A6F0E for ; Tue, 17 Nov 2015 09:35:57 -0800 (PST) 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 tAHHa0su020804; Tue, 17 Nov 2015 09:36:00 -0800 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAHHZuge020756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Nov 2015 09:35:57 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.207]) with mapi id 14.03.0235.001; Tue, 17 Nov 2015 09:35:53 -0800 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] Thread-Index: AQHRIJpUsgni8VUg+0O8njNAhlteCp6fN14+gAANn9CAAMc7lIAAbB3g Date: Tue, 17 Nov 2015 17:35:52 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4EBA4@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832F4CF07@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4CFA6@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F4D4C5@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ] 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, 17 Nov 2015 17:35:59 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Tuesday, November 17, 2015 2:57 AM > To: v6ops@ietf.org > Cc: Templin, Fred L > Subject: Re: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr= -availability discussion] ] >=20 > Hi Fred, >=20 > >Yes, you are right; the target address will be the link-local address of > >N on the eth0 link, and the destination address will be A. So, to the > >outside world, N would look like a router. Do you see a problem > >with that? >=20 > The problem is that other hosts will clear their destination caches if th= ey > receive a NA without the router bit set. So a host trying to communicate > with an address taken from the prefix will constantly go back to the defa= ult > router, get a redirect, do a neighbor discovery probe and clear the > destination cache for that address. >=20 > Maybe all nodes that receive a prefix using PD have to behave as routers = for the > purposes of (at least) ND. Yes, you are right about the IsRouter flag. But, I think all that means is = that node N simply needs to leave "ip forwarding" turned on so that IsRouter will be set in ND messages. Internally, however, N can still assign address A from prefix P to the eth0 interface so that applications will believe that they are running on an ordinary host that observes the strong end system model. I have this working in linux and android. Leaving "ip forwarding" turned on I think also allows N to send ICMP unreachables when it receives packets with destination address B from prefix P, where B is not an address that N has configured on any interface. So, it is somewhat router-like in that sense also. Thanks - Fred fred.l.templin@boeing.com From nobody Tue Nov 17 09:52: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 45CF41B2D2D for ; Tue, 17 Nov 2015 09:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 mH0xJPLVpiIL for ; Tue, 17 Nov 2015 09:52:52 -0800 (PST) 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 40E711B2D21 for ; Tue, 17 Nov 2015 09:52:52 -0800 (PST) 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 tAHHqrnD003226; Tue, 17 Nov 2015 09:52:53 -0800 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAHHqiFH002675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Nov 2015 09:52:44 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.29]) with mapi id 14.03.0235.001; Tue, 17 Nov 2015 09:52:41 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Lorenzo Colitti Thread-Topic: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6gDHGAgACEtQA= Date: Tue, 17 Nov 2015 17:52:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F4EC02@XCH-BLV-504.nw.nos.boeing.com> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <564A86D3.6050708@gmail.com> In-Reply-To: <564A86D3.6050708@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] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] 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, 17 Nov 2015 17:52:54 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTYsIDIwMTUgNTo0NiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBMb3JlbnpvIENvbGl0dGkNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBE QUQgYWdhaW4gW3dhczogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5IGRp c2N1c3Npb25dDQo+IA0KPiBJIGd1ZXNzIEkndmUgYmVlbiBwdXp6bGluZyBvdmVyIHRoaXMgZm9y IHRlbiBkYXlzLCBidXQgdGhlIFBEDQo+IGRpc2N1c3Npb24gbWFkZSBtZSB0aGluayBhYm91dCBp dCBhZ2Fpbi4gUmVhZCB0byB0aGUgZW5kIHRvDQo+IHJlbG9hZCB0aGUgY29udGV4dCBhbmQgc2Vl bSBteSBjb21tZW50Og0KPiANCj4gT24gMDQvMTEvMjAxNSAxMTozNywgVGVtcGxpbiwgRnJlZCBM IHdyb3RlOg0KPiA+IEhpIEJyaWFuLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwMywgMjAxNSAxOjQ3 IFBNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEw7IExvcmVuem8gQ29saXR0aQ0KPiA+PiBDYzog djZvcHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogREFEIGFnYWluIFt3YXM6IGRyYWZ0LWlldGYt djZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBkaXNjdXNzaW9uXQ0KPiA+Pg0KPiA+PiBIZWxs byBGcmVkLA0KPiA+Pg0KPiA+PiBPbiAwMy8xMS8yMDE1IDIwOjEwLCBUZW1wbGluLCBGcmVkIEwg d3JvdGU6DQo+ID4+PiBIaSBCcmlhbiwNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDAyLCAy MDE1IDY6NTUgUE0NCj4gPj4+PiBUbzogVGVtcGxpbiwgRnJlZCBMOyBMb3JlbnpvIENvbGl0dGkN Cj4gPj4+PiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBk cmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHkgZGlzY3Vzc2lvbg0KPiA+Pj4+ DQo+ID4+Pj4gSGkgRnJlZCwNCj4gPj4+PiBPbiAwMy8xMS8yMDE1IDE0OjU5LCBUZW1wbGluLCBG cmVkIEwgd3JvdGU6DQo+ID4+Pj4+IEhpIEJyaWFuLA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFtt YWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+Pj4+Pj4gU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAwMiwgMjAxNSA1OjQ2IFBNDQo+ID4+Pj4+PiBUbzogVGVtcGxpbiwgRnJlZCBM OyBMb3JlbnpvIENvbGl0dGkNCj4gPj4+Pj4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4+Pj4g U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmls aXR5IGRpc2N1c3Npb24NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBPbiAwMy8xMS8yMDE1IDE0OjMxLCBU ZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4+Pj4+Pj4gQnVtcGluZyB1cCBvbmUgbGV2ZWwg4oCT IGlzIGl0IGNsZWFyIHRvIGV2ZXJ5b25lIHRoYXQgaXQgaXMgT0sgdG8gYXNzaWduIGFkZHJlc3Nl cw0KPiA+Pj4+Pj4+IHRha2VuIGZyb20gYSBESENQdjYgZGVsZWdhdGVkIHByZWZpeCB0byB0aGUg aW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIHByZWZpeA0KPiA+Pj4+Pj4+IHdhcyByZWNlaXZlZD8N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBJZiBpdCB3YXMgbGVnaXRpbWF0ZWx5IHJlY2VpdmVkLCBJIGNh bid0IHNlZSB3aHkgaXQgd291bGRuJ3QgYmUgT0suDQo+ID4+Pj4+DQo+ID4+Pj4+IE9LLiBXaGVu IHRoZSBESENQdjYgc2VydmVyIGdyYW50cyBhIHByZWZpeCBkZWxlZ2F0aW9uIHRvIHRoZSBjbGll bnQsDQo+ID4+Pj4+IHRoZSBzZXJ2ZXIgaXMgYXNzZXJ0aW5nIHRoYXQgdGhhdCBwcmVmaXggaXMg dW5pcXVlIGFuZCBpcyBub3cgdGhlIHNvbGUNCj4gPj4+Pj4gcHJvcGVydHkgb2YgdGhlIGNsaWVu dC4gU28sIHdoZW4geW91IHNheSBsZWdpdGltYXRlbHkgcmVjZWl2ZWQgSQ0KPiA+Pj4+PiBhZ3Jl ZSBhbmQgdGhhdCBpcyBhY3R1YWxseSBhIGNvcmUgcmVxdWlyZW1lbnQgb2YgREhDUHY2IFBELg0K PiA+Pj4+PiBPdGhlcndpc2UsIGlmIHRoZSBESENQdjYgc2VydmVyIGdhdmUgb3V0IGR1cGxpY2F0 ZSBwcmVmaXhlcywgdGhlDQo+ID4+Pj4+IHJvdXRpbmcgc3lzdGVtIHdvdWxkIGJlY29tZSBob3Bl bGVzc2x5IGNvcnJ1cHRlZCBhbmQgYWRkcmVzcw0KPiA+Pj4+PiBkdXBsaWNhdGlvbiB3b3VsZCBi ZSB0aGUgbGVhc3Qgb2Ygb3VyIHdvcnJpZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+Pj4gQW5kLCB0aGF0 IERBRCBpcyBub3QgcmVxdWlyZWQgZm9yIHRob3NlIGFkZHJlc3Nlcz8NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBIb3cgaXMgdGhhdCBzYWZlPyBXaGF0IGlzIHRvIHN0b3AgYSBob3N0IHJ1bm5pbmcgU0xB QUMgb25jZSBpdA0KPiA+Pj4+Pj4gc2VlcyB0aGF0IHByZWZpeCBpbiBhbiBSQSwgYW5kIGhpdHRp bmcgdGhlIHNhbWUgSUlEIGJ5IGNoYW5jZT8NCj4gPj4+Pj4+IEF0IGxlYXN0IHlvdSBuZWVkIHRv IHNwZWNpZnkgdGhhdCB0aGUgQSBiaXQgbXVzdCBub3QgYmUgc2V0Lg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBJIGFtIHRhbGtpbmcgYWJvdXQgREFEIG9uIGludGVyZmFjZSAiQSIgYmVpbmcgdGhlIGludGVy ZmFjZSBvdmVyDQo+ID4+Pj4+IHdoaWNoIHRoZSBjbGllbnQgcmVjZWl2ZXMgdGhlIHByZWZpeCBk ZWxlZ2F0aW9uLiBObyBvdGhlciBub2RlIG9uDQo+ID4+Pj4+IGludGVyZmFjZSAiQSIgbWF5IHVz ZSB0aGUgZGVsZWdhdGVkIHByZWZpeCwgYW5kIG5vIHJvdXRlciBvbg0KPiA+Pj4+PiBpbnRlcmZh Y2UgIkEiIG1heSBhZHZlcnRpc2UgdGhlIHByZWZpeCBpbiBhbiBSQS4gVGhlIHByZWZpeCBpcyB0 aGUNCj4gPj4+Pj4gc29sZSBwcm9wZXJ0eSBvZiB0aGUgY2xpZW50IHRoYXQgcmVjZWl2ZWQgdGhl IFBELCBzbyB0aGUgY2xpZW50IGlzDQo+ID4+Pj4+IGZyZWUgdG8gYXNzaWduIGFkZHJlc3NlcyB3 aXRob3V0IG5lZWRpbmcgREFELg0KPiA+Pj4+DQo+ID4+Pj4gVGhhdCB1c2FnZSBvZiAibWF5IiBt aWdodCBjb25mdXNlIHNvbWUgcGVvcGxlLCBzbyBsZXQncyBwcmV0ZW5kDQo+ID4+Pj4geW91IHVz ZWQgYSAiTVVTVCBOT1QiIGNvbnN0cnVjdCBpbnN0ZWFkLiBJIGNvdWxkIHN0aWxsIGNvbnN0cnVj dA0KPiA+Pj4+IGEgaG9zdCBzdGFjayB0aGF0IHdvdWxkIGlnbm9yZSB0aGUgaXNzdWU6IGl0cyBs b2dpYyB3b3VsZCBiZQ0KPiA+Pj4+ICJJIHNlbnQgYW4gUlMgYW5kIGdvdCBubyBSQS9QSU8gd2l0 aCBBPTE7IGJ1dCBJIHNlZSB0cmFmZmljIGZyb20NCj4gPj4+PiBwcmVmaXggMmJhZDpkZWFkOmJl ZWY6Oi82NCwgc28gSSdsbCBkbyBTTEFBQyBhbmQgREFEIGluIHRoYXQgcHJlZml4LiINCj4gPj4+ DQo+ID4+PiBUaGUgbWFsaWNpb3VzIChvciBvdGhlcndpc2UgYnJva2VuKSBob3N0ICdBJyBjb3Vs ZCBjb25maWd1cmUgYW55IG51bWJlcg0KPiA+Pj4gb2YgYWRkcmVzc2VzIGl0IGxpa2VzLCBidXQg aXQgd291bGQgZG8gc28gaW4gYSB2YWN1dW0gYmVjYXVzZSBpbmdyZXNzDQo+ID4+PiBmaWx0ZXJp bmcgd2lsbCBwcmV2ZW50IGEgcGFja2V0IHdpdGggYSBzb3VyY2UgYWRkcmVzcyBmcm9tIGEgcHJl Zml4DQo+ID4+PiBiZWxvbmdpbmcgdG8gaG9zdCBCIGZyb20gYmVpbmcgYWNjZXB0ZWQuIFNvLCBu b2RlIEIgaGFzIG5vIHJlYXNvbg0KPiA+Pj4gdG8gZmVhciBhZGRyZXNzIGR1cGxpY2F0aW9uIGJ5 IG5vZGUgQS4NCj4gPj4NCj4gPj4gSSdtIG5vdCBzdXJlIGhvdyBhbiBpbmdyZXNzIGZpbHRlciBz b21ld2hlcmUgdXBzdHJlYW0gd291bGQga25vdyB0aGF0DQo+ID4+IHRoZSBwYWNrZXQgY2FtZSBm cm9tIHRoZSAid3JvbmciIGhvc3QuIEJ1dCBJIGRvbid0IHRoaW5rIHRoYXQncyBlbm91Z2g7DQo+ ID4+IGEgZHVwbGljYXRlIGFkZHJlc3Mgb24gdGhlIExBTiBpcyBhbHJlYWR5IGEgcHJvYmxlbSBp biBpdHNlbGYuDQo+ID4+DQo+ID4+PiBBbHNvLCB3aGF0IGlmIG5vZGUgQiBpbiBmYWN0IGRpZCBk byBEQUQgYW5kIEEgaGVhcmQgaXQ/IFdoYXQgaXMgdG8gc3RvcA0KPiA+Pj4gQSBmcm9tIGNvbmZp Z3VyaW5nIGEgZHVwbGljYXRlIGFkZHJlc3MgYW5kIHRyeWluZyB0byB1c2UgaXQganVzdCB0byBt ZXNzDQo+ID4+PiB1cCB0aGUgbGVnaXRpbWF0ZSBvcGVyYXRpb24gb2Ygbm9kZSBCPw0KPiA+Pg0K PiA+PiBOb3RoaW5nLiBUaGF0LCBJIHRoaW5rLCBpcyB3aHkgdGhlIFJGQ3MgbWFrZSBEQUQgbWFu ZGF0b3J5Lg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIGEg YnJva2VuIGltcGxlbWVudGF0aW9uIHRoYXQgY291bGQgb25seQ0KPiA+Pj4gYmUgZW1wbG95ZWQg YnkgYSBtYWxpY2lvdXMgaG9zdCwgYW5kIG5vdCBzb21ldGhpbmcgdGhhdCBob25vcnMNCj4gPj4+ IHRoZSBzdGFuZGFyZHMuDQo+ID4+DQo+ID4+IEkgZG9uJ3QgdGhpbmsgaXQncyBtYWxpY2lvdXM7 IGl0J3MganVzdCB0cnlpbmcgdG8gZ2V0IElQdjYgY29ubmVjdGl2aXR5DQo+ID4+IGluIHRoZSBm YWNlIG9mIHdoYXQgaXQgc2VlcyBhcyBhIGJyb2tlbiByb3V0ZXIgdGhhdCBpc24ndCByZXNwb25k aW5nDQo+ID4+IHRvIFJTLiBCdXQgdGhhdCBpc24ndCByZWFsbHkgbXkgcG9pbnQgLSBteSBwb2lu dCBpcyB0aGF0IHdoYXRldmVyIHdlDQo+ID4+IGRvLCBpdCdzIGltcG9zc2libGUgdG8gYXNzZXJ0 IHRoYXQgYSBkdXBsaWNhdGUgYWRkcmVzcyB3aWxsIG5ldmVyIGFyaXNlLg0KPiA+Pg0KPiA+Pj4g RG9pbmcgREFEIGlzIG5vdCBnb2luZyB0byBndWFyZCBhZ2FpbnN0IG1hbGljaW91cw0KPiA+Pj4g aG9zdHMuDQo+ID4+DQo+ID4+IE5vLCBidXQgaXQgbWlnaHQgYWxsb3cgeW91IHRvIGRldGVjdCB0 aGUgcmVzdWx0aW5nIGFub21hbHkuDQo+ID4NCj4gPg0KPiA+IEFjdHVhbGx5LCB0aGUgc2ltcGxl ciBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiBpcyB0aGF0IHRoZSBub2RlIHdvdWxkDQo+ID4gYWN0 IGFzIGEgaG9zdCBpbnRlcm5hbGx5LCBidXQgYXBwZWFyIHRvIGJlIGEgcm91dGVyIG9uIHRoZSBs aW5rIGZyb20gYW4NCj4gPiBvdXRzaWRlIG9ic2VydmVyJ3MgcGVyc3BlY3RpdmUuIEFuZCwgcm91 dGVycyBkbyBub3QgZG8gREFEIGZvciB0aGUNCj4gPiBzb3VyY2UgYWRkcmVzc2VzIG9mIHBhY2tl dHMgdGhhdCBwYXNzIHRocm91Z2ggdGhlbS4NCj4gDQo+IEFsbCByb3V0ZXJzIGFyZSBhbHNvIElQ djYgbm9kZXMsIGFuZCBieSBkZWZpbml0aW9uIGhhdmUgYW4gYWN0aXZlDQo+IElQdjYgaW50ZXJm YWNlIHdpdGggYW4gYWRkcmVzcyBvbiBlYWNoIG9mIHRoZWlyIGxpbmtzLiBBbGwgSVB2NiBub2Rl cw0KPiBhcmUgc3VwcG9zZWQgdG8gcGVyZm9ybSBEQUQgb24gdGhlaXIgYWRkcmVzc2VzLiBSRkMg NDg2MiBpcyBjbGVhciB0aGF0DQo+IHRoaXMgYXBwbGllcyBldmVuIGlmIFNMQUFDIGlzIG5vdCB1 c2VkOg0KPiANCj4gICAgVGhlIER1cGxpY2F0ZQ0KPiAgICBBZGRyZXNzIERldGVjdGlvbiBhbGdv cml0aG0gaXMgcGVyZm9ybWVkIG9uIGFsbCBhZGRyZXNzZXMsDQo+ICAgIGluZGVwZW5kZW50bHkg b2Ygd2hldGhlciB0aGV5IGFyZSBvYnRhaW5lZCB2aWEgc3RhdGVsZXNzDQo+ICAgIGF1dG9jb25m aWd1cmF0aW9uIG9yIERIQ1B2Ni4NCg0KUkZDNDg2MiBzYXlzOg0KDQogICAtICBBbiBpbnRlcmZh Y2Ugd2hvc2UgRHVwQWRkckRldGVjdFRyYW5zbWl0cyB2YXJpYWJsZSBpcyBzZXQgdG8gemVybw0K ICAgICAgZG9lcyBub3QgcGVyZm9ybSBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24uDQoNCldo YXQgdGhhdCBtZWFucyBpcyB0aGF0IHRoZSBub2RlIGRvZXMgbm90IGhhdmUgdG8gZG8gREFEIGlm IGl0IGhhcyBzb21lDQpnb29kIHJlYXNvbiBmb3Igc2V0dGluZyBEdXBBZGRyRGV0ZWN0VHJhbnNt aXRzIHRvIDAuIFN1Y2ggYXMgaWYgdGhlDQphZGRyZXNzZXMgaXQgYXNzaWducyB0byB0aGUgaW50 ZXJmYWNlIGFyZSBmcm9tIGEgcHJlZml4IGRlbGVnYXRpb24gaXQNCmhhcyByZWNlaXZlZCBmcm9t IGEgZGVsZWdhdGluZyByb3V0ZXIuDQoNCj4gYW5kIHNwZWNpZmljYWxseSByZXF1aXJlcyByb3V0 ZXJzIHRvIHBlcmZvcm0gREFEOg0KDQo+ICAgIEluIGFkZGl0aW9uLCByb3V0ZXJzIGFyZSBleHBl Y3RlZCB0byBzdWNjZXNzZnVsbHkgcGFzcyB0aGUNCj4gICAgRHVwbGljYXRlIEFkZHJlc3MgRGV0 ZWN0aW9uIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBvbg0KPiAgICBhbGwg YWRkcmVzc2VzIHByaW9yIHRvIGFzc2lnbmluZyB0aGVtIHRvIGFuIGludGVyZmFjZS4NCj4gDQo+ IEluIGZhY3QgaXQncyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IHRoYXQgcm91dGVycyBkZXRlY3Qg YW55IGFkZHJlc3MNCj4gY29sbGlzaW9uIG9uIGFueSBvZiB0aGVpciBpbnRlcmZhY2VzLCBiZWNh dXNlIGRvd25zdHJlYW0gaG9zdHMgb3Igb3RoZXINCj4gcm91dGVycyB1c2UgZWFjaCBhZGRyZXNz IGFzIGEgbmV4dCBob3AuDQo+IA0KPiBJIGNhbiByZWFkaWx5IGJlbGlldmUgdGhhdCBpbXBsZW1l bnRhdGlvbnMgd2hlcmUgc3RhdGljIGFkZHJlc3NlcyBhcmUNCj4gY29uZmlndXJlZCBvbiBhIHNp bXBsZSBwdDJwdCBsaW5rIHNraXAgdGhpcywgYnV0IGRvaW5nIHNvIG9uIGEgYnJvYWRjYXN0DQo+ IG9yIE5CTUEgbGluayBzZWVtcyB3cm9uZyB0byBtZS4NCg0KVXNpbmcgQUVSTyBhcyBhbiBleGFt cGxlIG9mIGFuIE5CTUEgbGluaywgQUVSTyBDbGllbnRzIGF1dG9jb25maWd1cmUNCkFFUk8gYWRk cmVzc2VzIGJhc2VkIG9uIHRoZSBwcmVmaXggZGVsZWdhdGlvbnMgdGhleSByZWNlaXZlIGZyb20g QUVSTw0KU2VydmVycy4gQUVSTyBTZXJ2ZXJzIE1VU1QgZW5zdXJlIHRoYXQgdGhlIHByZWZpeGVz IHRoZXkgZ2l2ZSBvdXQgYXJlDQp1bmlxdWUgdG8gdGhlIEFFUk8gQ2xpZW50IHJlY2lwaWVudCBh bmQgbm90IGdpdmVuIG91dCB0byBvdGhlciBBRVJPDQpDbGllbnRzLiBTbywgdGhlIEFFUk8gYWRk cmVzcyAod2hpY2ggaXMgcmVhbGx5IGp1c3QgYW4gSVB2NiBsaW5rLWxvY2FsDQphZGRyZXNzIHdp dGggYW4gSVB2NiBwcmVmaXggZW1iZWRkZWQgaW4gdGhlIGludGVyZmFjZSBpZGVudGlmaWVyKSBp cw0KZ3VhcmFudGVlZCB0byBiZSB1bmlxdWUgYW5kIGhlbmNlIG5vIERBRCBuZWVkZWQuDQoNClRo YW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJlb2luZy5jb20NCg0KDQo+ICAgICBCcmlhbg0K PiANCj4gICAgICBCcmlhbg0KDQo= From nobody Tue Nov 17 13:23:24 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 DE3291A88F0; Tue, 17 Nov 2015 13:23:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117212322.28145.24175.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 13:23:22 -0800 Archived-At: Cc: draft-ietf-v6ops-reducing-ra-energy-consumption@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-reducing-ra-energy-consumption.all@tools.ietf.org Subject: [v6ops] Martin Stiemerling's No Objection on draft-ietf-v6ops-reducing-ra-energy-consumption-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: Tue, 17 Nov 2015 21:23:23 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-v6ops-reducing-ra-energy-consumption-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-reducing-ra-energy-consumption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One comment about Section 4. Router Advertisement frequency: There are no references to where the power draw numbers are coming from. E.g., it is not clear what real device is taking 5 mA vs 200 mA. From nobody Tue Nov 17 13:53:31 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 00F301B316A; Tue, 17 Nov 2015 13:53:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117215328.14492.2282.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 13:53:28 -0800 Archived-At: Cc: v6ops@ietf.org, fred.baker@cisco.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-reducing-ra-energy-consumption@ietf.org, bill.wu@huawei.com, draft-ietf-v6ops-reducing-ra-energy-consumption.all@tools.ietf.org Subject: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-reducing-ra-energy-consumption-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: Tue, 17 Nov 2015 21:53:29 -0000 Benoit Claise has entered the following ballot position for draft-ietf-v6ops-reducing-ra-energy-consumption-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-reducing-ra-energy-consumption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some editorial proposals from Qin, part of the OPS Directorate review. Here are a few suggestion and editorial comments: 1. Section 4, last bullet: s/ non-general-purpose/ dedicated 2. Section 5.1, bullet 2 said: “Administrators of networks that serve large numbers (tens or hundreds) of battery-powered devices SHOULD enable this behaviour.” which behavior should be enabled? “Responding to Router Solicitations with unicast Router Advertisements” or the behavior described by bullet 1? Please make this clear. 3. Section 5.1, bullet 3: The word “Section” repeats twice, it is not necessary. s/see section Section 4/see Section 4 From nobody Tue Nov 17 20:35:50 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 7864A1B34EC; Tue, 17 Nov 2015 15:21:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117232152.6906.30368.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 15:21:52 -0800 Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2015 20:35:48 -0800 Cc: draft-ietf-v6ops-reducing-ra-energy-consumption@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-reducing-ra-energy-consumption.all@tools.ietf.org Subject: [v6ops] Ben Campbell's Yes on draft-ietf-v6ops-reducing-ra-energy-consumption-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: Tue, 17 Nov 2015 23:21:52 -0000 Ben Campbell has entered the following ballot position for draft-ietf-v6ops-reducing-ra-energy-consumption-03: 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-reducing-ra-energy-consumption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few minor comments: - 1: It would be nice to have a very brief summary of the recommendations (even if it's just the fact that the doc makes recommendations) in the introduction. - 4, 3rd paragraph from end:"the average power budget for receiving RAs must be no more than 0.1mA" Should that be mAH? -8: There is no reference for RFC 6104. From nobody Wed Nov 18 19:53: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 DA2611A038A for ; Wed, 18 Nov 2015 19:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.686 X-Spam-Level: X-Spam-Status: No, score=-113.686 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 dOhWIXpwMTjd for ; Wed, 18 Nov 2015 19:53:03 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15CB1A0366 for ; Wed, 18 Nov 2015 19:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3865; q=dns/txt; s=iport; t=1447905182; x=1449114782; h=from:to:subject:date:message-id:mime-version; bh=YrONJ6YSclLmI39JOSZNIXa1t/28SIsatLi4Rvtpyog=; b=KqCmm8FF4QETwcwpw9UoneAU4d3RKj7yV/0azTCzZPkDOeO+4USnvfJr VHdRDY0ZgLK8ccxsHjQ1RkK+KCnBNWBJeXhjYwI/GpydJfDJgWFBLHJ6v K8RMe3ryDB+M76IF2JIXBnIDSna5npJce5GIHXn9b8/sjmJKT5/3pN/4m A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgBFRk1W/5xdJa1UCoM7gUi+Yg6BZ?= =?us-ascii?q?YdaOBQBAQEBAQEBgQqEO4ELAYEAJwQhiCCeepMGjR0BAQEBAQUBAQEBAQEBARI?= =?us-ascii?q?JiGSHHoN0gRUFlkoBglaBYINbhRmBW4RAlikBHwFDhASFC4EHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,316,1444694400"; d="asc'?scan'208";a="46235910" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2015 03:53:02 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAJ3r1MB031332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 Nov 2015 03:53:01 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 Nov 2015 22:53:00 -0500 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; Wed, 18 Nov 2015 22:53:00 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: Net Neutrality question Thread-Index: AQHRIn3I03cONo/ye0GO4yyDa7Yi9Q== Date: Thu, 19 Nov 2015 03:53:00 +0000 Message-ID: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@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.66.255.204] Content-Type: multipart/signed; boundary="Apple-Mail=_A8E0BAFC-6439-4738-89B3-556D77A15AAC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Net Neutrality question 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, 19 Nov 2015 03:53:05 -0000 --Apple-Mail=_A8E0BAFC-6439-4738-89B3-556D77A15AAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am reviewing a paper on Net Neutrality by someone in a developing = country. He describes something that I presume is true of the major ISP = in his country. It gets me thinking, and I wonder what folks think of = the thought. The comment he makes is that "operators commonly" (by which I think he = means his operator) "install DPI equipment watching for certain high = volume applications such as file sharing, and block it." Comcast went through this, using DPI to trap BitTorrent. They got into a = scrap with the FCC. There were two outcomes: LEDBAT (BitTorrent now uses = a different transport in order to maximize throughput while minimizing = latency, loss, and impact on competing traffic) and RFC 6057 (a Cable = Network procedure designed to apply a relatively gentle pushback on a = top talker so that everyone gets a turn to communicate without having to = identify a subscriber or application, or drop traffic). If the provider in this case is a Cable Modem provider, RFC 6057 seems = like a very reasonable alternative to DPI. I'm guessing it's actually = DSL. Hmm, he thinks... When we wrote Diffserv, at the request of certain network operators, we = duplicated the Cascade implementation of Frame Relay in four Diffserv = PHBs - the Assured Forwarding Service, RFC 2597. The premise is that a = service provider can measure the rate at which traffic arrives from a = customer or peer, mark the first BPS packets AFn1, the next = BPS packets AFn2, the third BPS packets AFn3, and = discard anything above that out of hand. Couple that with an AQM = implementation that applies different parameters to the different DSCPs = (when a queue builds up, the probability of loss of AFn1 is close to = zero, probability of loss of AFn2 is a little higher, and the = probability of loss of AFn3 is a lot higher), and senders that exceed = their contracts are likely to experience loss first. It occurs to me that this service could be used in such a network to = accomplish a goal similar to RFC 6057, but in a different way. We're not = targeting an application, nor are we targeting a specific subscriber or = peer. We're targeting any subscriber or peer that exceeds his contract, = and only doing so if and when the result is network congestion. We do = use loss, but we use it in a way that at least tries to interact with = TCP in a gentle way. There's probably something I'm missing. Could someone point it out to = me? (please be gentle...) --Apple-Mail=_A8E0BAFC-6439-4738-89B3-556D77A15AAC 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 iQIVAwUBVk1HpEayAOS/EQ8MAQI78A//act5n36WJFiT0cnkCfdJ/hiO8mq+m31V oSgEvYZMkN2syWfbBoO+no+pEYkfw9CZsdwlC00kL2JQCsmLkkqqx/6Gew1xYb9M cHq+Fj3DHKHvWawNhCHFPKoLvgh0g4/2f5zWQDGH2gsC8UhUoIbcazq9KaRV6KKv QmBm3dwq2WRMBGN1kU9VCHs2rZXwqjJ/Bajt+ZDuRDMZ5M4KK6Pc52KUh5/x+LK3 IlytRjD6Um4ujuA7C3iFvHhszMXfJ1BhYS8HFfEsyHzHEqiNjgmlvQJtLFi7EySe TynvkMEfWnORLsOLChFjjxdISnvYxAhxJjcTYRv8/WNxNM5lIZCgYzPEfYNyxNNb SSA7VEOhGQhTFAmvjiYTDqJccW67tKkPxuHR4oYG8AQSrly2qOzVPhYL09/l/Exn SsqDj4W7POqnMahUCxv92o9Vyd2hTie21xRn3UNgbQTdh3MMKl82+zt+R7ZcGhXq AKeR335GQn7xAUwdLqQiOmSikKv+0KiamLM3x3w8Bp50l9+KGOxiB+vAEdF8xGoS 8PFNIGUwaq62hSV7L+audXz8A3Mhvf+FaNprPcw83/OfsfUhFSTAVM1JkuMm3jdc o2qwla2F+lMP8QBiuOTPOCg+d6kI/aipd8dCnB4eYwB43gqd2OvyITeRSbfI5jgQ x4FULRBUJ6Y= =c+bR -----END PGP SIGNATURE----- --Apple-Mail=_A8E0BAFC-6439-4738-89B3-556D77A15AAC-- From nobody Wed Nov 18 21:25: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 D97671A8833 for ; Wed, 18 Nov 2015 21:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 g1diGL_gSnT0 for ; Wed, 18 Nov 2015 21:25:06 -0800 (PST) Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E0F1A882E for ; Wed, 18 Nov 2015 21:25:06 -0800 (PST) Received: from smtp22.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id F2DEB180390; Thu, 19 Nov 2015 00:25:05 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 061A618037E; Thu, 19 Nov 2015 00:25:04 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [172.20.10.4] (amx-tls2.starhub.net.sg [203.116.164.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 19 Nov 2015 00:25:05 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Barry Raveendran Greene In-Reply-To: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> Date: Thu, 19 Nov 2015 13:25:00 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93BAB56C-060D-4EBD-8A17-22CE55DD4CF6@senki.org> References: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Net Neutrality question 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, 19 Nov 2015 05:25:08 -0000 > Comcast went through this, using DPI to trap BitTorrent. They got into = a scrap with the FCC. There were two outcomes: LEDBAT (BitTorrent now = uses a different transport in order to maximize throughput while = minimizing latency, loss, and impact on competing traffic) and RFC 6057 = (a Cable Network procedure designed to apply a relatively gentle = pushback on a top talker so that everyone gets a turn to communicate = without having to identify a subscriber or application, or drop = traffic). Too complicated and the engineers + vendors who give them free = consulting don=E2=80=99t the depth of engineering options available. It = is easier for a DPI box to be placed into the network thinking that it = is going to work. In most cases, it does not work (people find ways = around it). Scaling the DPI also becomes a problem. For now, the = =E2=80=9Cmagic DPI box=E2=80=9D is the quick fix.=20 From nobody Wed Nov 18 22:03: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 667271A88F7 for ; Wed, 18 Nov 2015 22:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 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, RP_MATCHES_RCVD=-0.585, 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 tGxMl97XZZQf for ; Wed, 18 Nov 2015 22:02:28 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 94AFE1A88F5 for ; Wed, 18 Nov 2015 22:02:28 -0800 (PST) Received: by ykfs79 with SMTP id s79so97705330ykf.1 for ; Wed, 18 Nov 2015 22:02:28 -0800 (PST) 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=2TVOcfkKYYatXX0v2Wq6UbGuauSNM3ofAhehcs/rIgw=; b=IqirdSRLE99MVDPGcvnFHXcwjahqxC3yZu7tkBVisYqZwiU3Kap0iItChUC1vrkP49 acSSb5SfOkxcVFlV5RDTfaIdGtAIlaH3PR/PwVExtTlWvOVmZDxbRcxl13/3p/1YM7Rb gPHhHtlyu0Uasi/uHcyxtNnyQqCyyNLDi4TnjeUSUPIQPwebcpu92paT4TeNIW3HRXJ9 m94P599PyjFIhGe3SaG2h8R7kFqoAAm1FqE+c7lr5LZ6eItwHVwTFBoZrx4jGUmMjkGS z7DbgycYIIXcxQG/cDUvzoIsYGhEgXzZpu03dSJzhlaj4bZlMh1tL7tFLumlsVz7hlRa qlMQ== 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=2TVOcfkKYYatXX0v2Wq6UbGuauSNM3ofAhehcs/rIgw=; b=TbllR6lX+bzC2UM7pm4HboHnYIF/ZY7kJb06iIeybsAcdgqvkrprUvzIJm3iz5+zpl KixTLHP6R3etfkvg5RGvwmk99UIKOkLnSl3kVJzg4l3hZhQ0FaL0Et3jQODkn3ZpbF6H NKetq3Gc32/xN78DOQmqbH/WTcZP8bpIOGIuWw3ASccj5Tm1QfjFhXEFUn4ZtqDwMoH3 4MVqPam+8u6Oh5R/bQ01RHadbOrAFGHNzSSGmqukiW5+jxTQtQI6vQO0zVt9Kt2UT8Pn GO8Z8wdn65kQ0xedhhmC9YBNNDy9uRWkCyfY6DsApHv1hFr07gsbRBr5MFYveh4LEg6u BAKw== X-Gm-Message-State: ALoCoQkJ7vb3ipt20+N+mZbOUI3nxwhn/W+5KLFutXkX1jcbocm9LDk29cwYJ2tLNRh90oE0rISG X-Received: by 10.129.42.4 with SMTP id q4mr5834286ywq.35.1447912947774; Wed, 18 Nov 2015 22:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Wed, 18 Nov 2015 22:02:08 -0800 (PST) In-Reply-To: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> References: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> From: Lorenzo Colitti Date: Thu, 19 Nov 2015 15:02:08 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a1141fb50eb73c90524de806e Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Net Neutrality question 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, 19 Nov 2015 06:02:32 -0000 --001a1141fb50eb73c90524de806e Content-Type: text/plain; charset=UTF-8 On Thu, Nov 19, 2015 at 12:53 PM, Fred Baker (fred) wrote: > The comment he makes is that "operators commonly" (by which I think he > means his operator) "install DPI equipment watching for certain high volume > applications such as file sharing, and block it." > Wouldn't that practice violate regulations or even laws in a number of countries? --001a1141fb50eb73c90524de806e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Nov 19, 2015 at 12:53 PM, Fred Baker (fred) <fred@cisco.com> wrote:
    The comment he makes is that &qu= ot;operators commonly" (by which I think he means his operator) "= install DPI equipment watching for certain high volume applications such as= file sharing, and block it."

    Woul= dn't that practice violate regulations or even laws in a number of coun= tries?=C2=A0
    --001a1141fb50eb73c90524de806e-- From nobody Wed Nov 18 22:25: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 EC7981A8980 for ; Wed, 18 Nov 2015 22:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.585, 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 gw4jzTOyHCTN for ; Wed, 18 Nov 2015 22:25:09 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627611A897B for ; Wed, 18 Nov 2015 22:25:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 440BDA2; Thu, 19 Nov 2015 07:25:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1447914306; bh=8iMV/gkptiXG1upHVc02650f4RcTy2xl97/AM8/HVrY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=T72DPd15IQSZAY2DrPFEjuR/65Q2SjKKiL4EtJ1e22KTqXfNG30iOStIqG+HIGSam nZNxDINdBw3ZAddI1sLTSwuhR7MXfnJtCoHmzAaC09st/FYC2mY4+0S85TIo7pafqR l+WO1u0iiOLC6ZJY92iKmNyipY7qEcM75D+ZbPSU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 34F23A1; Thu, 19 Nov 2015 07:25:06 +0100 (CET) Date: Thu, 19 Nov 2015 07:25:06 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> Message-ID: References: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Net Neutrality question 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, 19 Nov 2015 06:25:12 -0000 On Thu, 19 Nov 2015, Fred Baker (fred) wrote: > The comment he makes is that "operators commonly" (by which I think he > means his operator) "install DPI equipment watching for certain high > volume applications such as file sharing, and block it." >From my experience, this happens for networks where moving bits is expensive. I would not use the word "commonly", but it's not "uncommon". Same thing with in-line cache boxes, if you're paying 100 USD / month per megabit/s then you want to do everything in your power to keep data local and keep customer use down, if you pay 0.5 USD / month per megabit/s, then you do not care much. I have seen operators get into trouble when doing this heavy handedly, and I think I know operators that do this without customers being much impacted (for instance they will use these kinds of boxes to re-encode or rate-limit video for customers with monthly data caps, so the video uses less bandwidth). > If the provider in this case is a Cable Modem provider, RFC 6057 seems > like a very reasonable alternative to DPI. I'm guessing it's actually > DSL. Yes, you do not need DPI, some boxes will do traffic analysis and deduct that a certain flow is X, and will then apply shaping/rate-limiting to this flow. > When we wrote Diffserv, at the request of certain network operators, we > duplicated the Cascade implementation of Frame Relay in four Diffserv > PHBs - the Assured Forwarding Service, RFC 2597. The premise is that a > service provider can measure the rate at which traffic arrives from a > customer or peer, mark the first BPS packets AFn1, the next > BPS packets AFn2, the third BPS packets AFn3, and > discard anything above that out of hand. Couple that with an AQM > implementation that applies different parameters to the different DSCPs > (when a queue builds up, the probability of loss of AFn1 is close to > zero, probability of loss of AFn2 is a little higher, and the > probability of loss of AFn3 is a lot higher), and senders that exceed > their contracts are likely to experience loss first. Yes, that could make sense. > It occurs to me that this service could be used in such a network to > accomplish a goal similar to RFC 6057, but in a different way. We're not > targeting an application, nor are we targeting a specific subscriber or > peer. We're targeting any subscriber or peer that exceeds his contract, > and only doing so if and when the result is network congestion. We do > use loss, but we use it in a way that at least tries to interact with > TCP in a gentle way. Yep. > There's probably something I'm missing. Could someone point it out to > me? (please be gentle...) No, you're on the right track, these boxes I talk about above could definitely do this kind of marking. I wouldn't be surprised if some of them already do, usually the "action" part can be drop or re-mark. However, the operator has to be careful to keep the AFnX in the same queue so reordering doesn't happen, that might be something good to point out because it's not obvious to everybody. Also, equipment that would use AFnX for drop probability within the same queue, that's not something I think is very commonly available today. I don't remember seeing this myself in any equipment I have come across... -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Nov 18 22:38: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 722501A89E9 for ; Wed, 18 Nov 2015 22:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.086 X-Spam-Level: X-Spam-Status: No, score=-115.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 rtmtcCJpXHws for ; Wed, 18 Nov 2015 22:38:21 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03251A89C6 for ; Wed, 18 Nov 2015 22:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2006; q=dns/txt; s=iport; t=1447915100; x=1449124700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PDnxAWtRraARTIUY81isT0GusLyZKUVRsJQBfPe8tLA=; b=Shtw/w3Aa9zrrDEpAkbY/IoFbREmpQ8hY8ViLLhES0vl2WxM8Fd7uLGW R375ViBfzRQYT1+LRmHEqim/4HikZ82S94f+7q91Yp7zPyo0xLzJRrlMK HprNUIuoWb9FFhSE6ooc8ZieLq8hCWFndmaBJnQwCRVRwp/nxQPPkknLL A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAgBobU1W/49dJa1egzuBQga+Yg6BZ?= =?us-ascii?q?YYPAoFBOBQBAQEBAQEBgQqENAEBAQMBeQULAgEIDgouMiUCBA4FDogYCL8jAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDwmIZIJuiCSBFQWWSgGCVoFgiHScRAEfAUOEB?= =?us-ascii?q?HKEGYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,317,1444694400"; d="asc'?scan'208";a="209919450" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2015 06:38:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAJ6cJH8003498 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2015 06:38:19 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, 19 Nov 2015 01:38:18 -0500 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, 19 Nov 2015 01:38:18 -0500 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [v6ops] Net Neutrality question Thread-Index: AQHRIpTgTDi2LgMGjEa6jL5mlPKdLw== Date: Thu, 19 Nov 2015 06:38:18 +0000 Message-ID: <95C1B3DD-C547-490B-B8DC-8B66C6C670F5@cisco.com> References: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@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.66.255.204] Content-Type: multipart/signed; boundary="Apple-Mail=_F9DE3023-A6B7-4103-8746-A9B7AC3AC4C3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Net Neutrality question 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, 19 Nov 2015 06:38:23 -0000 --Apple-Mail=_F9DE3023-A6B7-4103-8746-A9B7AC3AC4C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 19, 2015, at 7:25 PM, Mikael Abrahamsson = wrote: >=20 > However, the operator has to be careful to keep the AFnX in the same = queue so reordering doesn't happen, that might be something good to = point out because it's not obvious to everybody. Also, equipment that = would use AFnX for drop probability within the same queue, that's not = something I think is very commonly available today. I don't remember = seeing this myself in any equipment I have come across... It's on Cisco equipment running IOS, and I believe IOS-XR and friends. = I'll send you the MQC Configuration if you're interested. I can't speak = to anything else. --Apple-Mail=_F9DE3023-A6B7-4103-8746-A9B7AC3AC4C3 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 iQIVAwUBVk1uX0ayAOS/EQ8MAQJyshAArY9CHA/9tRFJipgsFtoRWLeGyUVqk8mc VaXOyDdWw0j0/ft1FFsyd9Cg/X9KwyTma7EYrno/L5ESBUp13kkEWh84SwPSchNq D7WIIGcBw6jKzmKge3878T4LeyYIekld2y/pe8zrXIlrUlk/wPfOOeJ5B8rkwd8u LxouDa9CLglTvLdSztVTxNLTrbuPulxI5kUKgNTaPxoEASt2V90ru36zEKtEcdF1 ebaic9i/AJ9e1Hgu5cQMpRsalWB3hAGl/SqcePF12P7Wji2/+fqaOeePHHr8kCGG atLEZUbq4z39agK4SMiiUVzZVcNf96w6zQT3jLTaoXZOGCOJW0N4w/6Ky8h9voGb Yu/l8/VObcW9RRr2OxxZ3qTdh6HAAYfftvvOK9DPrd6fh8geaFAKMlwlhQHrPH2O ERNE8zS6mKZZUjQf8raU45cwwBxS7dJ12Lr7T597OD1K/LyPe/1pPRd8CWG45JrU HXzfpIWvUof/8HW4Hw5ms/a4W3uGxUB3EkAneaThaMQAeqgMM9pNaVbj/R1yLqZA QJBQdAdSY7tYmnsJxqkkBCifsb5OK2yXrfwwTweF/TLIEvxmRFmI4O1RZWIRpAdd Wm2YFWRnN8moW0fRmOusnf2iH+kvlnpD0kA+xqSRUH53iTaP/787mV9DLSG063bG 7pLEAzcBxgg= =o4Mf -----END PGP SIGNATURE----- --Apple-Mail=_F9DE3023-A6B7-4103-8746-A9B7AC3AC4C3-- From nobody Wed Nov 18 22: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 5BAE71A8A09 for ; Wed, 18 Nov 2015 22:44:43 -0800 (PST) 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 fk_97feCTme8 for ; Wed, 18 Nov 2015 22:44:41 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 1BF531A8A05 for ; Wed, 18 Nov 2015 22:44:41 -0800 (PST) Received: by lfs39 with SMTP id 39so41629484lfs.3 for ; Wed, 18 Nov 2015 22:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type; bh=VyCro/UyTCGUfWVWosQdGLjf9mnYT2U98TgbW9cH6IY=; b=uJxuqcO0lLChOzcEZVUIhU5HZNK3NwfMXIZjw+HMZBimRu+3zT6UV0h9b+jkVeKlfy e4IRhJFXaDe8hhag7qTYWN9imZW8b+CnvnYvwvgBngl6LHGSXFSkHj4Wy6HFZrV8f3HC 9te2FhLgO8sX9Uy7d1qlv57BjTX2YWTZCHjdsIMUjRTYmpiw/cqdBU/r4arEHu0YAjGI r2AiWYbDYCdN+KxtAL6VpxDSJZs0Nsp75AVUv5qSmrdmb0AItoQJFgJ9ZOZaP8dmu2K/ CG3MgIBiUoupsL/in6/rKiRors0G+D3VrUsMD0E7dO0C6CrG+Wfb0s/3V2+P5ArJiEhn ZKrg== X-Received: by 10.25.26.210 with SMTP id a201mr2133583lfa.58.1447915478933; Wed, 18 Nov 2015 22:44:38 -0800 (PST) Received: from Ivans-MacBook-Pro.local ([194.136.233.81]) by smtp.gmail.com with ESMTPSA id 102sm977297lft.21.2015.11.18.22.44.37 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Nov 2015 22:44:37 -0800 (PST) Date: Thu, 19 Nov 2015 08:44:36 +0200 From: Ivan Pepelnjak To: "Fred Baker (fred)" , IPv6 Operations Message-ID: In-Reply-To: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> References: <4E9C6C1B-9F9C-4AD7-9822-DFFC8E406F86@cisco.com> X-Mailer: Airmail (335) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="564d6fd4_31be8d23_14a93" Archived-At: Subject: Re: [v6ops] Net Neutrality question 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, 19 Nov 2015 06:44:43 -0000 --564d6fd4_31be8d23_14a93 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline When we wrote Diffserv, at the request of certain network operators, we d= uplicated the Cascade implementation of =46rame Relay in four Diffserv PH= Bs - the Assured =46orwarding Service, R=46C 2597. The premise is that a = service provider can measure the rate at which traffic arrives from a cus= tomer or peer, mark the first BPS packets A=46n1, the next BPS packets A=46n2, the third BPS packets A=46n3, and discar= d anything above that out of hand. Couple that with an AQM implementation= that applies different parameters to the different DSCPs (when a queue b= uilds up, the probability of loss of A=46n1 is close to zero, probability= of loss of A=46n2 is a little higher, and the probability of loss of A=46= n3 is a lot higher), and senders that exceed their contracts are likely t= o experience loss first.=C2=A0 It occurs to me that this service could be used in such a network to acco= mplish a goal similar to R=46C 6057, but in a different way. We're not ta= rgeting an application, nor are we targeting a specific subscriber or pee= r. We're targeting any subscriber or peer that exceeds his contract, and = only doing so if and when the result is network congestion. We do use los= s, but we use it in a way that at least tries to interact with TCP in a g= entle way.=C2=A0 It=E2=80=99s easy to measure user-generated traffic at ingress interface,= but really hard to identify and measure per-user traffic sent from the I= nternet toward the user, as no router I=E2=80=99ve seen so far enables yo= u to measure and mark traffic per-destination-IP (or prefix) and that=E2=80= =99s how some people might be using the DPI boxes. In other words, I have yet to see something that would give every user (i= dentified by IP address or prefix) a fair share of bandwidth. Note: please don=E2=80=99t start the NAT-breaks-this-idea discussion. I=E2= =80=99m well aware of that ;) Hope this helps, Ivan --564d6fd4_31be8d23_14a93 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

    With regard to the notion that IPv6's= large (source) address space

    “…also gives attac= kers a potential advantage over defenders w.r.t. resource depletion attacks= compared to the scarcity of source addresses in IPv4”=

     

    I mentioned this before, so don’= ;t want to dwell on it too much, but think it is important to understand th= e problem from a real world perspective.  An address does not deplete resources.  It takes an interface with CPU and memor= y to do that.

     

    “If an attacker compromi= ses an important server in a corporate network, and the corporation have be= en sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each= /64 per LAN) that could form a very attractive attack platform (2^32/2^64 = potential /64 prefixes =3D equivalent to the entire current Internet addres= s space sourced from a single machine).”

     

    The important point is, with regard t= o resource depletion, this is a still single machine, and in the context of= DOS attack platforms, is usually insignificant without additional systems from which to launch the attack.  Indeed u= tilizing that many addresses during an attack carries with it some signific= ant overhead that would take away from the effective throughput in this sce= nario.

    The real concern in the stated scenar= io is the randomly changing source addressing that might evade detection ot= her than the fact that it is all coming from the same subnet.  (That in itself ought to be a useful clue for the corpo= rate network admins of the compromised system, if they are looking to detec= t the issue.)

     

    When we think about this from a compa= rison to IPv4, the change is not in the amount of resources that can be ded= icated to the attack, but in the potential identities from which they are sourced.

     

    Certainly the massive address space c= ould lead to significant abilities to attack other systems, but it requires= more than just address space.  It requires a corresponding investment in network throughput and endpoints that can init= iate the attack.

    While we think about these issues, I = think it is important to not lose sight of that.

     

    Thanks,

     

    -   =        Dan

     

     

    &nbs= p;

    From: Ray Hunter (v6ops) [mailto:v6ops@globis.net]
    Sent: Wednesday, November 25, 2015 8:12 AM
    To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
    Cc: Metzler, Dan J <dan-metzler@uiowa.edu>; v6ops@ietf.org
    Subject: Re: Re: [v6ops] preventing denial of service in IPv6

     



    Nikos Mavrogiannopoulos wrote:

     
    Then a single user can exhaust a server's resources by simply
    attacking the server with all his available addresses.


    FWIW I agree with the original premise that IPv6's large (source) address s= pace is a blessing, but also gives attackers a potential advantage over def= enders w.r.t. resource depletion attacks compared to the scarcity of source= addresses in IPv4.

    I think the problem here is that attackers may also have access to a /32 ..= /48 /52 /56 or /60, as well as /64.

    If an attacker compromises an important server in a corporate network, and = the corporation have been sloppy and only applied BCP38 egress filtering at= the external boundary at /32 level (rather than individual filters at each= /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes =3D equi= valent to the entire current Internet address space sourced from a single m= achine).


     

     

    --

    regards,
    RayH

    --_000_CO2PR04MB58511D172234305AA2DE9CCFE050CO2PR04MB585namprd_-- From nobody Thu Nov 26 04:41: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 A69431B2AFC for ; Thu, 26 Nov 2015 04:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, 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 vFtBR-e9QcC6 for ; Thu, 26 Nov 2015 04:41:39 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D47951A90E9 for ; Thu, 26 Nov 2015 04:41:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6EED14034B; Thu, 26 Nov 2015 13:41:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scmj8fLQmPmG; Thu, 26 Nov 2015 13:41:33 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8CA6940348; Thu, 26 Nov 2015 13:41:33 +0100 (CET) Message-ID: <5656FDFC.1010502@globis.net> Date: Thu, 26 Nov 2015 13:41:32 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Metzler, Dan J" References: <5655C1B5.8030801@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050109000306000606020804" 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: Thu, 26 Nov 2015 12:41:45 -0000 This is a multi-part message in MIME format. --------------050109000306000606020804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit inline. > Metzler, Dan J > 25 Nov 2015 16:09 > > With regard to the notion that IPv6's large (source) address space > > "...also gives attackers a potential advantage over defenders w.r.t. > resource depletion attacks compared to the scarcity of source > addresses in IPv4" > > I mentioned this before, so don't want to dwell on it too much, but > think it is important to understand the problem from a real world > perspective. An address does not deplete resources. It takes an > interface with CPU and memory to do that. > > "If an attacker compromises an important server in a corporate > network, and the corporation have been sloppy and only applied BCP38 > egress filtering at the external boundary at /32 level (rather than > individual filters at each /64 per LAN) that could form a very > attractive attack platform (2^32/2^64 potential /64 prefixes = > equivalent to the entire current Internet address space sourced from a > single machine)." > > The important point is, with regard to resource depletion, this is a > still single machine, and in the context of DOS attack platforms, is > usually insignificant without additional systems from which to launch > the attack. Indeed utilizing that many addresses during an attack > carries with it some significant overhead that would take away from > the effective throughput in this scenario. > > The real concern in the stated scenario is the randomly changing > source addressing that might evade detection other than the fact that > it is all coming from the same subnet. (That in itself ought to be a > useful clue for the corporate network admins of the compromised > system, if they are looking to detect the issue.) > But if the BCP38 filtering is "weak" then the notion of 'subnet' is lost to the outside world. I hope that rack space providers have good filtering (at subnet/machine level). In the past there was an automatic upper limit for source addresses based on the assigned address space, even if BCP38 filters were lax at the subnet level. > > When we think about this from a comparison to IPv4, the change is not > in the amount of resources that can be dedicated to the attack, but in > the potential identities from which they are sourced. > Agreed. > > Certainly the massive address space could lead to significant > abilities to attack other systems, but it requires more than just > address space. It requires a corresponding investment in network > throughput and endpoints that can initiate the attack. > I disagree here. The tracking mechanisms in many current firewalls and other devices rely on tracking by remote identity = IPv4 source address. Even with 10gbps connectivity at the attackers end, a single attacking machine could easily be identified, tracked, and blocked before much traffic hit end hosts at say 1Gbps or 100Mbps. In IPv6, Identity and state now needs to be tracked at multiple levels of prefix length. Otherwise the tracking mechanisms or NAT slots or load balancing slots or state tables in your firewalls or other middleware box become the attack target for resource depletion (exhaustion of tracking slots in the middleware box). Which means IMHO that any state-based middleware boxes are potential targets. [yes, I know the IETF denies these devices exist] The same is true for the identity slots in any peer to peer network that relies on remote IP address = peer identity. These peer tables can now be poisoned by a single machine filling up the peer table with garbage. That resource depletion attack was not easily feasible in IPv4, because of source address scarcity. A single attacker could not trivially overflow the peering table of multiple torrent clients by sending just a few packets. So IMVHO this is a new attack vector. Or at least one that has greatly reduced in how difficult it is to execute. > > While we think about these issues, I think it is important to not lose > sight of that. > > Thanks, > > -Dan > > *From:*Ray Hunter (v6ops) [mailto:v6ops@globis.net] > *Sent:* Wednesday, November 25, 2015 8:12 AM > *To:* Nikos Mavrogiannopoulos > *Cc:* Metzler, Dan J ; v6ops@ietf.org > *Subject:* Re: Re: [v6ops] preventing denial of service in IPv6 > > > > Nikos Mavrogiannopoulos wrote: > > > > Then a single user can exhaust a server's resources by simply > > attacking the server with all his available addresses. > > > FWIW I agree with the original premise that IPv6's large (source) > address space is a blessing, but also gives attackers a potential > advantage over defenders w.r.t. resource depletion attacks compared to > the scarcity of source addresses in IPv4. > > I think the problem here is that attackers may also have access to a > /32 .. /48 /52 /56 or /60, as well as /64. > > If an attacker compromises an important server in a corporate network, > and the corporation have been sloppy and only applied BCP38 egress > filtering at the external boundary at /32 level (rather than > individual filters at each /64 per LAN) that could form a very > attractive attack platform (2^32/2^64 potential /64 prefixes = > equivalent to the entire current Internet address space sourced from a > single machine). > > > > > -- > > regards, > RayH > > Ray Hunter (v6ops) > 25 Nov 2015 15:12 > > > Nikos Mavrogiannopoulos wrote: >> On Fri, Oct 23, 2015 at 3:18 PM, Metzler, Dan J wrote: >> >>>> 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". > Agreed. >>> [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 from an availability standpoint, in the same way that it makes it a bit harder to scan addresses. >>> I would expect blocking a /64 to be the equivalent of blocking a subnet in IPv4, because it is. >> >> Then a single user can exhaust a server's resources by simply >> attacking the server with all his available addresses. > > FWIW I agree with the original premise that IPv6's large (source) > address space is a blessing, but also gives attackers a potential > advantage over defenders w.r.t. resource depletion attacks compared to > the scarcity of source addresses in IPv4. > > I think the problem here is that attackers may also have access to a > /32 .. /48 /52 /56 or /60, as well as /64. > > If an attacker compromises an important server in a corporate network, > and the corporation have been sloppy and only applied BCP38 egress > filtering at the external boundary at /32 level (rather than > individual filters at each /64 per LAN) that could form a very > attractive attack platform (2^32/2^64 potential /64 prefixes = > equivalent to the entire current Internet address space sourced from a > single machine). > > I wrote some (experimental) code last year in C to track source > addresses using a Patricia Tree. I intended to use this in front of > our mail server, but never got around to implementing it. I can share > if you want. > > My experiments suggested that it was best to track sessions was using > a 4 bit nibble to key each branch of the Patricia tree, and then > initiate a firewall block at this level if there were above a > threshold number of sessions from a given prefix length in a given > time (more experimentation needed to determine the thresholds in > operation to avoid false positives). I did not find that tracking > beyond /64 was worthwhile, given the impossible task of distinguishing > between a legitimate temporary address, or a hand configured /127. > Using an octet at the tree branch vastly increased memory usage. Using > a binary tree increased search time (64 recursive lookups rather than > 16 to track to /64 level). > > The code could track large numbers of connections per second, at the > expense of eating up to 2GB of memory for the tree structure to track > several million connections. > > An alternative would be to add this prefix-length-aware triggering > into a log follower like fail2ban. > > Whether this is a good/viable defence strategy remains to be proven. > >>>> 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. >>> [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 they all must be offenders. >>> 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 their >>>> users. >>>> >>>> Are there any recommendations for protecting servers from the IPv6 address >>>> 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 capacity 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 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 >> >> > -- regards, RayH --------------050109000306000606020804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline.

    25 Nov 2015 16:09

    With regard to the notion that IPv6's large (source) address space

    “…also gives attackers a potential advantage over defenders w.r.t. resource depletion attacks compared to the scarcity of source addresses in IPv4”

     

    I mentioned this before, so don’t want to dwell on it too much, but think it is important to understand the problem from a real world perspective.  An address does not deplete resources.  It takes an interface with CPU and memory to do that.

     

    “If an attacker compromises an important server in a corporate network, and the corporation have been sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes = equivalent to the entire current Internet address space sourced from a single machine).”

     

    The important point is, with regard to resource depletion, this is a still single machine, and in the context of DOS attack platforms, is usually insignificant without additional systems from which to launch the attack.  Indeed utilizing that many addresses during an attack carries with it some significant overhead that would take away from the effective throughput in this scenario.

    The real concern in the stated scenario is the randomly changing source addressing that might evade detection other than the fact that it is all coming from the same subnet.  (That in itself ought to be a useful clue for the corporate network admins of the compromised system, if they are looking to detect the issue.)

     

    But if the BCP38 filtering is "weak" then the notion of 'subnet' is lost to the outside world.

    I hope that rack space providers have good filtering (at subnet/machine level).

    In the past there was an automatic upper limit for source addresses based on the assigned address space, even if BCP38 filters were lax at the subnet level.

    When we think about this from a comparison to IPv4, the change is not in the amount of resources that can be dedicated to the attack, but in the potential identities from which they are sourced.

    Agreed.

    Certainly the massive address space could lead to significant abilities to attack other systems, but it requires more than just address space.  It requires a corresponding investment in network throughput and endpoints that can initiate the attack.

    I disagree here.

    The tracking mechanisms in many current firewalls and other devices rely on tracking by remote identity = IPv4 source address.

    Even with 10gbps connectivity at the attackers end, a single attacking machine could easily be identified, tracked, and blocked before much traffic hit end hosts at say 1Gbps or 100Mbps.

    In IPv6, Identity and state now needs to be tracked at multiple levels of prefix length.

    Otherwise the tracking mechanisms or NAT slots or load balancing slots or state tables in your firewalls or other middleware box become the attack target for resource depletion (exhaustion of tracking slots in the middleware box).

    Which means IMHO that any state-based middleware boxes are potential targets.
    [yes, I know the IETF denies these devices exist]

    The same is true for the identity slots in any peer to peer network that relies on remote IP address = peer identity.
    These peer tables can now be poisoned by a single machine filling up the peer table with garbage.

    That resource depletion attack was not easily feasible in IPv4, because of source address scarcity.

    A single attacker could not trivially overflow the peering table of multiple torrent clients by sending just a few packets.

    So IMVHO this is a new attack vector. Or at least one that has greatly reduced in how difficult it is to execute.

    While we think about these issues, I think it is important to not lose sight of that.

     

    Thanks,

     

    -          Dan

     

     

     

    From: Ray Hunter (v6ops) [mailto:v6ops@globis.net]
    Sent: Wednesday, November 25, 2015 8:12 AM
    To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
    Cc: Metzler, Dan J <dan-metzler@uiowa.edu>; v6ops@ietf.org
    Subject: Re: Re: [v6ops] preventing denial of service in IPv6

     



    Nikos Mavrogiannopoulos wrote:

     
    Then a single user can exhaust a server's resources by simply
    attacking the server with all his available addresses.


    FWIW I agree with the original premise that IPv6's large (source) address space is a blessing, but also gives attackers a potential advantage over defenders w.r.t. resource depletion attacks compared to the scarcity of source addresses in IPv4.

    I think the problem here is that attackers may also have access to a /32 .. /48 /52 /56 or /60, as well as /64.

    If an attacker compromises an important server in a corporate network, and the corporation have been sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes = equivalent to the entire current Internet address space sourced from a single machine).


     

     

    --

    regards,
    RayH

    25 Nov 2015 15:12


    Nikos Mavrogiannopoulos wrote:
    On Fri, Oct 23, 2015 at 3:18 PM, Metzler, Dan J <dan-metzler@uiowa.edu> wrote:


    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".
    Agreed.
    [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 from an availability standpoint, in the same way that it makes it a bit harder to scan addresses.
I would expect blocking a /64 to be the equivalent of blocking a subnet in IPv4, because it is.

    
Then a single user can exhaust a server's resources by simply
attacking the server with all his available addresses.

    FWIW I agree with the original premise that IPv6's large (source) address space is a blessing, but also gives attackers a potential advantage over defenders w.r.t. resource depletion attacks compared to the scarcity of source addresses in IPv4.

    I think the problem here is that attackers may also have access to a /32 .. /48 /52 /56 or /60, as well as /64.

    If an attacker compromises an important server in a corporate network, and the corporation have been sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes = equivalent to the entire current Internet address space sourced from a single machine).

    I wrote some (experimental) code last year in C to track source addresses using a Patricia Tree. I intended to use this in front of our mail server, but never got around to implementing it. I can share if you want.

    My experiments suggested that it was best to track sessions was using a 4 bit nibble to key each branch of the Patricia tree, and then initiate a firewall block at this level if there were above a threshold number of sessions from a given prefix length in a given time (more experimentation needed to determine the thresholds in operation to avoid false positives). I did not find that tracking beyond /64 was worthwhile, given the impossible task of distinguishing between a legitimate temporary address, or a hand configured /127. Using an octet at the tree branch vastly increased memory usage. Using a binary tree increased search time (64 recursive lookups rather than 16 to track to /64 level).

    The code could track large numbers of connections per second, at the expense of eating up to 2GB of memory for the tree structure to track several million connections.

    An alternative would be to add this prefix-length-aware triggering into a log follower like fail2ban.

    Whether this is a good/viable defence strategy remains to be proven.

    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.

    [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 they all must be offenders.
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 their
users.

Are there any recommendations for protecting servers from the IPv6 address
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 capacity 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 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


    --
    regards,
    RayH
    --------------050109000306000606020804-- From nobody Fri Nov 27 01:18: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 22D991B2A04 for ; Fri, 27 Nov 2015 01:18:14 -0800 (PST) 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 5awLrQP5alM2 for ; Fri, 27 Nov 2015 01:18:08 -0800 (PST) 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 A977C1B2A05 for ; Fri, 27 Nov 2015 01:18:08 -0800 (PST) Received: by igcph11 with SMTP id ph11so24002732igc.1 for ; Fri, 27 Nov 2015 01:18:08 -0800 (PST) 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 :content-type; bh=Qq0VbDgdPKcFDRv/yVjbhcyF6lJJ0F4VM9BsdAlZ6oE=; b=wOjUISCZL6ldXealNT19izq+DegTegcUMO1wWsFb5zUKE/Vbz1uHNt8bQKXgN+Ko30 i3kG9rM7GWObIO55vrzMzxcqTprNIucqRKxWfug1tP/HRVL+GZwt90VOopWiFlHDf5TW PnvNnU28M+n5P+ZueXo0U4qdS9S6TA79lLpzAmzNlkEn0Enz9flJlfotnKDugMWW5SAO E6xkgv3OUHUcdDtCOXPQShGQVdUWw0UWYtLZkbRDbtXwQIqTMTnvUHvBH6syu8Gf6tdo 2IzB8v44ZM8/s8kpogRqXM6It6BCEewQtLgGJe7Q51mbv62C/2jTfe74w56seWYtyRbG SEXQ== X-Received: by 10.50.73.130 with SMTP id l2mr7216183igv.93.1448615887985; Fri, 27 Nov 2015 01:18:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.142.68 with HTTP; Fri, 27 Nov 2015 01:17:28 -0800 (PST) In-Reply-To: References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> From: Qiong Date: Fri, 27 Nov 2015 17:17:28 +0800 Message-ID: To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=089e01160edc6b61d30525822bc1 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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, 27 Nov 2015 09:18:14 -0000 --089e01160edc6b61d30525822bc1 Content-Type: text/plain; charset=UTF-8 Dear all, I've read this document and think it provides valuable information to the community in terms of what is the reality with ipv6 extension headers. I like Eric's proposal to remove the (mostly duplicate) tables. Best wishes Qiong On Tue, Nov 24, 2015 at 12:41 PM, Qiong wrote: > > > On Thu, Nov 12, 2015 at 2:04 AM, Warren Kumari wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, wrote: >> > This is to initiate a two week working group last call of >> > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. >> > Please read it now. If you find nits (spelling errors, minor suggested >> > wording changes, etc), comment to the authors; if you find greater >> > issues, such as disagreeing with a statement or finding additional >> > issues that need to be addressed, please post your comments to the >> > list. >> > >> > We are looking specifically for comments on the importance of the >> > document as well as its content. If you have read the document and >> > believe it to be of operational utility, that is also an important >> > comment to make. >> >> I have read this and believe it to be useful. >> >> Nit: >> I think that the acronyms in the tables (e.g DO8, FH512) should be >> expanded, preferably close to the table. >> >> W >> >> >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/ > * > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ > * > =============================================== > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e01160edc6b61d30525822bc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear all,

    I've read this docum= ent and think it provides valuable information to the community in terms of= what is the reality with ipv6 extension headers.
    =C2=A0
    I like Eric's proposal = to remove the (mostly duplicate) tables.
    <= br>
    Best wishes
    Qiong

    On Tue, Nov 24, 2015 at 12:41 PM, Qiong <bingxuere@gmail.com><= /span> wrote:


    On Thu, = Nov 12, 2015 at 2:04 AM, Warren Kumari <warren@kumari.net> w= rote:
    On Mon, Nov 9, 2015 at 4:00 AM,=C2=A0 <<= a href=3D"mailto:fred@cisco.com" target=3D"_blank">fred@cisco.com> w= rote:
    > This is to initiate a two week working group last call of
    > http://tools.ietf.org/html/dr= aft-ietf-v6ops-ipv6-ehs-in-real-world.
    > Please read it now. If you find nits (spelling errors, minor suggested=
    > wording changes, etc), comment to the authors; if you find greater
    > issues, such as disagreeing with a statement or finding additional
    > issues that need to be addressed, please post your comments to the
    > list.
    >
    > We are looking specifically for comments on the importance of the
    > document as well as its content. If you have read the document and
    > believe it to be of operational utility, that is also an important
    > comment to make.

    I have read this and believe it to be useful.

    Nit:
    I think that the acronyms in the tables (e.g DO8, FH512) should be
    expanded, preferably close to the table.

    W


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



    --
    I don't think the execution is relevant when it was obviously a bad
    idea in the first place.
    This is like putting rabid weasels in your pants, and later expressing
    regret at having chosen those particular rabid weasels and that pair
    of pants.
    =C2=A0 =C2=A0---maf

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



    <= /div>--
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Qiong Sun
    China Tele= com Beijing Research Institude


    Open source code:
    lightweight = 4over6: http://sourceforge.net/projects/laft6/
    PCP-natcoord: = http://sourceforge.net/projects/pcpportsetdemo/
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    Qiong Sun
    China Telecom Beijing Research Institude

    <= br>Open source code:
    lightweight 4over6: http://sourceforge.net/projects/la= ft6/
    PCP-natcoord: http://sourceforge.net/projects/pcpport= setdemo/
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    --089e01160edc6b61d30525822bc1-- From nobody Fri Nov 27 01:21: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 E432C1B2A10 for ; Fri, 27 Nov 2015 01:21:20 -0800 (PST) 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 Z6OCRp2aLhKR for ; Fri, 27 Nov 2015 01:21:19 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 E06321B2A11 for ; Fri, 27 Nov 2015 01:21:18 -0800 (PST) Received: by iouu10 with SMTP id u10so110661791iou.0 for ; Fri, 27 Nov 2015 01:21:18 -0800 (PST) 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 :content-type; bh=58bby7Xj8o9dtVoBT7dFhZxmAsxIBgIvxBwxG2aB1zU=; b=thM98UsurifMupuDPcM5rtrp00iVc6LqwIu/C+FygMSSjoGlt5xumWbQP5Dijv6lPz yulsEXw2pvAuu/S8lysVi2o9UMvWinCFhDpXe+AqixiyP+JYJpMyigbGYgbp5WIiEM5b OoFXDUf25wdB+uhGoVQaSRTtpLppKTF1KoCdnXnfMo7aDh47GZoO4hhNp/PxsbsbvXLW N6my9dgUj5LUclzNsgbDLfJ5TlgXdMzJhkkArfHTu/iZEi6UVF1+8z/D3fA17BLgIaqN D1c3te6nV7e+WthE0qph0osk62q4F/e7dqsfQ4r1G5BAnQb7f8ao7nYLQ5O7NWNR6zlO bfwQ== X-Received: by 10.107.167.78 with SMTP id q75mr11021296ioe.36.1448616078316; Fri, 27 Nov 2015 01:21:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.142.68 with HTTP; Fri, 27 Nov 2015 01:20:38 -0800 (PST) In-Reply-To: References: <201511081900.tA8J02iD007338@irp-lnx1.cisco.com> From: Qiong Date: Fri, 27 Nov 2015 17:20:38 +0800 Message-ID: To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a114293a8c399f505258236ba Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-in-real-world 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, 27 Nov 2015 09:21:21 -0000 --001a114293a8c399f505258236ba Content-Type: text/plain; charset=UTF-8 Dear all, I've read this document and think it provides valuable information to the community in terms of what is the reality with ipv6 extension headers. I like Eric's proposal to remove the (mostly duplicate) tables. Best wishes Qiong On Tue, Nov 24, 2015 at 12:41 PM, Qiong wrote: > > > On Thu, Nov 12, 2015 at 2:04 AM, Warren Kumari wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, wrote: >> > This is to initiate a two week working group last call of >> > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. >> > Please read it now. If you find nits (spelling errors, minor suggested >> > wording changes, etc), comment to the authors; if you find greater >> > issues, such as disagreeing with a statement or finding additional >> > issues that need to be addressed, please post your comments to the >> > list. >> > >> > We are looking specifically for comments on the importance of the >> > document as well as its content. If you have read the document and >> > believe it to be of operational utility, that is also an important >> > comment to make. >> >> I have read this and believe it to be useful. >> >> Nit: >> I think that the acronyms in the tables (e.g DO8, FH512) should be >> expanded, preferably close to the table. >> >> W >> >> >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/ > * > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ > * > =============================================== > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a114293a8c399f505258236ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear all,

    I've read this docum= ent and think it provides valuable information to the community in terms of= what is the reality with ipv6 extension headers.
    =C2=A0
    I like Eric's proposal = to remove the (mostly duplicate) tables.
    <= br>
    Best wishes
    Qiong

    On Tue, Nov 24, 2015 at 12:41 PM, Qiong <bingxuere@gmail.com><= /span> wrote:


    On Thu, = Nov 12, 2015 at 2:04 AM, Warren Kumari <warren@kumari.net> w= rote:
    On Mon, Nov 9, 2015 at 4:00 AM,=C2=A0 <<= a href=3D"mailto:fred@cisco.com" target=3D"_blank">fred@cisco.com> w= rote:
    > This is to initiate a two week working group last call of
    > http://tools.ietf.org/html/dr= aft-ietf-v6ops-ipv6-ehs-in-real-world.
    > Please read it now. If you find nits (spelling errors, minor suggested=
    > wording changes, etc), comment to the authors; if you find greater
    > issues, such as disagreeing with a statement or finding additional
    > issues that need to be addressed, please post your comments to the
    > list.
    >
    > We are looking specifically for comments on the importance of the
    > document as well as its content. If you have read the document and
    > believe it to be of operational utility, that is also an important
    > comment to make.

    I have read this and believe it to be useful.

    Nit:
    I think that the acronyms in the tables (e.g DO8, FH512) should be
    expanded, preferably close to the table.

    W


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



    --
    I don't think the execution is relevant when it was obviously a bad
    idea in the first place.
    This is like putting rabid weasels in your pants, and later expressing
    regret at having chosen those particular rabid weasels and that pair
    of pants.
    =C2=A0 =C2=A0---maf

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



    <= /div>--
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Qiong Sun
    China Tele= com Beijing Research Institude


    Open source code:
    lightweight = 4over6: http://sourceforge.net/projects/laft6/
    PCP-natcoord: = http://sourceforge.net/projects/pcpportsetdemo/
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    Qiong Sun
    China Telecom Beijing Research Institude

    <= br>Open source code:
    lightweight 4over6: http://sourceforge.net/projects/la= ft6/
    PCP-natcoord: http://sourceforge.net/projects/pcpport= setdemo/
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    --001a114293a8c399f505258236ba-- From nobody Sun Nov 29 11:00: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 C542E1B31DD for ; Sun, 29 Nov 2015 11:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.086 X-Spam-Level: X-Spam-Status: No, score=-115.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 wVZyLTEIF6PT for ; Sun, 29 Nov 2015 11:00:06 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6011A1B31DC for ; Sun, 29 Nov 2015 11:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=623; q=dns/txt; s=iport; t=1448823606; x=1450033206; h=date:from:message-id:to:subject:cc; bh=senlBGDVr3pqkBepFKHBgYqngLnPIm5IhaDRcgacC/s=; b=S7IQiwzInvCp+7V5cyOsQPleWMzQfrEMWqXLP+Se3uEblnpoIMwo4G9K ne87E+8U94+S7Q+bqfdgFCrEkCM6SW0sVSnE2hHK7OAmswKid+vXemoLD m+yRBHrFVJ+Bu8IGDGuXbLeRMuuBg4FgC1HmESuxFf6G/NuxWOBf87p7+ 4=; X-IronPort-AV: E=Sophos;i="5.20,360,1444694400"; d="scan'208";a="48898261" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2015 19:00:05 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tATJ057O018283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Nov 2015 19:00:05 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id tATJ04cO009758; Sun, 29 Nov 2015 11:00:05 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id tATJ04fK009754; Sun, 29 Nov 2015 11:00:04 -0800 Date: Sun, 29 Nov 2015 11:00:04 -0800 From: fred@cisco.com Message-Id: <201511291900.tATJ04fK009754@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-bao-v6ops-rfc6145bis 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: Sun, 29 Nov 2015 19:00:07 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Mon Nov 30 14:53: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 F3F821B322B for ; Mon, 30 Nov 2015 14:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 M8VDNIs2egZv for ; Mon, 30 Nov 2015 14:52:57 -0800 (PST) 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 889D11B3228 for ; Mon, 30 Nov 2015 14:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1448923977; x=2312837577; 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=tCkNOxoNvXEq5V0RKLQGkQbJPXzOGFKwFxf4sytwoSs=; b=SKmfccX5kQBNbzvlQNDNjirWsoR9xsZ0LRBqm57YVu0vRtYkDhuDKfYZniefv8Qb wac2+g/GoLh1j0eFNUxF1dJ4jv3vSe53ljcMK/8/8kInveYmp2U8kP01uq1s7LJm FC0++T1BgiwuhhnVaM3sw/Pt0g3wBcNo7yTsXYd8wvXF8JaOywtTlHT2wVe8Kl66 E80vftti1QYsTGODPleXvpdtnylzYradBStQo2GiNuJuLlP9JEPX6aKvlqeoIp7+ c19FvyndDnDTZg4ofN8c1ikjZfOVb3q5lCtMDLYOm0tzAK4gubnawiS6w5skYW4C QvkYy2ddl8bYEoNW/wIKtA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id D8.9D.13397.843DC565; Mon, 30 Nov 2015 14:52:56 -0800 (PST) X-AuditID: 11973e13-f798b6d000003455-66-565cd348cea8 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 32.48.29028.843DC565; Mon, 30 Nov 2015 14:52:56 -0800 (PST) Received: from dschinazi.apple.com (dschinazi.apple.com [17.226.40.22]) by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0NYN00MIJGW87D40@kencur.apple.com> for v6ops@ietf.org; Mon, 30 Nov 2015 14:52:56 -0800 (PST) Sender: dschinazi@apple.com Date: Mon, 30 Nov 2015 14:52:56 -0800 From: David Schinazi To: David Farmer Message-id: In-reply-to: <56387AFB.9030308@umn.edu> References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <563817CB.6080506@umn.edu> <563864DD.2010309@umn.edu> <56387AFB.9030308@umn.edu> X-Mailer: Airmail (335) MIME-version: 1.0 Content-type: multipart/alternative; boundary=565cd348_50011d99_480 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUi2FCYput5OSbM4NJ0RovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9fZlewFR4wqnr/4w9zAuFC7i5GTQ0LAROLkgW/sELaYxIV7 69m6GLk4hAT2MUo8fNnODFO06MR7VohEL5PEuh8vmCGc+UwSdw6tAGsXFpCW6LpwlxXEZhFQ lVg38xzQKA4ONgEtiQNrjEDCIgKKEu+PtzKC2MwCxhKnDzxjBynhFbCVmPCnECTMKaAuMb9v KdQRC5kkmh/sYYQY7y6x9c4zVoiDxCWeb17GBGLzCghK/Jh8jwViprPEtU3nWECaJQSOsEn0 v5jDPoFReBaSullI6mYB7WYW0JRYv0sfIqwtsWzha2aIsLTE8n8cEGENidY5c9lxKFnAyLGK USg3MTNHNzPPVC+xoCAnVS85P3cTIyh2ptsJ72A8vcrqEKMAB6MSD6/E2pgwIdbEsuLK3EOM 0hwsSuK8i0uAQgLpiSWp2ampBalF8UWlOanFhxiZODilGhh37+cwjY6edbp0x8fbtjcl3qb+ L35yvM/szY3XDY3eaTLBZ1ckphnGCInf7fR5/Ky0JXyFQf3EzNX8P3/9ZpyrteTKxuu5q4+v NTkcevKKa6nZTzGFL1/EN/Tt2H+51/TgJ89dmg0RNZ+qonb5lwouu+PIsWh76IdTtyZcM1u3 uHLK/Gk3GTdPUmIpzkg01GIuKk4EAI5nK/V+AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUiON1OTdfjckyYwe0uC4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9fZlewFR4wqnr/4w9zAuFC7i5GTQ0LARGLRifesELaYxIV7 69m6GLk4hAR6mSTW/XjBDOHMZ5K4c2gFO0iVsIC0RNeFu2AdLAKqEutmngPq4OBgE9CSOLDG CCQsIqAo8f54KyOIzSxgLHH6wDN2kBJeAVuJCX8KQcKcAuoS8/uWQu1ayCTR/GAPI8R4d4mt d55BHSQu8XzzMiYQm1dAUOLH5HssEDOdJa5tOscygVFgFpLULCSpWUDrmAU0Jdbv0ocIa0ss W/iaGSIsLbH8HwdEWEOidc5cdhxKFjByrGIUKErNSay00EssKMhJ1UvOz93ECAr1hsK0HYxN y60OMQpwMCrx8EqsjQkTYk0sK67MPcQowcGsJML7ag9QiDclsbIqtSg/vqg0J7X4EONERmCo TWSWEk3OB0ZiXkm8oYmJgYmxsZmxsbmJOS2FlcR5K1b5hwkJpCeWpGanphakFsEcxcTBKdXA yMxW2zFNukHcJO1H/m6ufpZJBc7SiWbv70ndY4p6KSzBfmviJLs9+ix/TTMPp/bGtJ64v85l 1Z0qpVf/nTYHX/MRLUpcZHFDOUZfIrNTzfmixIOp+xt3vZvqsa1tnqdhxUSfohu7FvY2r99e F/3vfENn98eZZzhmlTlUzd9YfiIl/lfhGmVnJZbijERDLeai4kQA5SyzpugCAAA= Archived-At: Cc: "=?utf-8?Q?v6ops=40ietf.org?=" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion 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, 30 Nov 2015 22:53:01 -0000 --565cd348_50011d99_480 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David, I believe we should not recommend limiting the number of addresses a host= can use. Networks are already free to punish misbehaving clients (by number of pac= kets or addresses for example), that doesn=E2=80=99t need to be explicitly specified in this document. I understand your concerns about abuse, but hosts can already use this ma= ny addresses today and our document will not impact how many addresses hosts choose to use - only how many ar= e available to them from the network. Thanks, David On November 3, 2015 at 01:16:53, David =46armer (farmer=40umn.edu) wrote:= On 11/3/15 02:02 , Lorenzo Colitti wrote: =20 > On Tue, Nov 3, 2015 at 4:40 PM, David =46armer > wrote: =20 > =20 > I'm not stuck on those words, I'm just looking for something that =20 > acknowledges if networks impose no hard limit on the number of IPv6 =20 > addresses, that is not a excuse for hosts and applications to go crazy.= =20 > =20 > =46urthermore, I'm a little worried if I set a threshold of lets say =20 > 1000 IPv6 addresses and then quarantine a host as a network abuser, =20 > am I violating the spirit of this draft=3F Is 500 too low=3F 250=3F =20 > =20 > =20 > I think this concern can be addressed without placing requirements on =20 > the host and thus host creep. =46or example, would it address your =20 > concerns if the draft said that a network can pose limits on IPv6 =20 > addresses if the device uses an unreasonable number of addresses (e.g.,= =20 > hundreds)=3F =20 Something like that will probably work. Where are you thinking of =20 putting it=3F =20 -- =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=3D =20 David =46armer Email: farmer=40umn.edu =20 Office of Information Technology =20 University of Minnesota =20 2218 University Ave SE Phone: 1-612-626-0815 =20 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 =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=3D =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 v6ops mailing list =20 v6ops=40ietf.org =20 https://www.ietf.org/mailman/listinfo/v6ops =20 --565cd348_50011d99_480 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline