Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Owen DeLong <owen@delong.com> Fri, 13 November 2015 17:34 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
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 <v6ops@ietfa.amsl.com>; 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 <v6ops@ietfa.amsl.com>; 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 <v6ops@ietf.org>; 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 <owen@delong.com>
In-Reply-To: <D26B84F0.5DF41%evyncke@cisco.com>
Date: Fri, 13 Nov 2015 09:31:24 -0800
Message-Id: <7F92C0D6-A6A6-4226-A479-849BF4F07A8A@delong.com>
References: <D25D5920.C914E%Lee.Howard@twcable.com> <CAKD1Yr3jip0NBkDxg=MvgZXg0LMS+PtREDw2jSRx0xJLqHwhGQ@mail.gmail.com> <563C7C01.6010703@foobar.org> <CAKD1Yr1rKjkDhhuD9L=R_MJ+ofOAZ2Nt+5mszZKQxCh-kH4vqw@mail.gmail.com> <563FA84C.7030601@si6networks.com> <CAKD1Yr0F888Aw0opSigtC8HV6esUrE1JECKQ4gT737s+43ayfw@mail.gmail.com> <CAG6TeAs8ie=c0F8RMioBpemCw949Bf9c7ZTNvqgaZP=10rmNcQ@mail.gmail.com> <CAKD1Yr1EqbiGJ8EZo8E909zujUt49skcz1SNe8stEWfHnbUsTw@mail.gmail.com> <CAG6TeAsHMTyhbRrOenb1kA9XEDdOCBBbuN3ZGF3LJ=8ToyGtiQ@mail.gmail.com> <CAKD1Yr3RUc9FEw7VyJ=ENH_sJY85m1BESo77v_maShPvCkj6rA@mail.gmail.com> <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com> <CAKD1Yr2VXVFareTk-J_+pcr_UW9Do-zf_uYcyjNW-MTPts6hRQ@mail.gmail.com> <CAG6TeAt2JJJmALy=pJFaojbnZrQRE0e0i-D=XtTce=rmbf08tQ@mail.gmail.com> <CAKD1Yr1H2HgxBNOZBrx-ttoB6z6caLAck3csF=ti6CDUzW57ng@mail.gmail.com> <D267B9E3.5DB8C%evyncke@cisco.com> <CAKD1Yr2zY9qr76f-KO7DTnYXQEmMJ0O6M22nFczfjGfL5Dk=dA@mail.gmail.com> <564537A7! .90102@si6networks.com> <CAKD1Yr3dUMEoG-De5YWDFyjGehhxBq-uyN-NSqbYgvinDUy8Wg@mail.gmail.com> <D26B5654.5DE76%evyncke@cisco.com> <CAKD1Yr3PaEojRyXzhmdJ+mnXOe6eGi38dBkdjXC=jHL98Eo2sg@mail.gmail.com> <D26B84F0.5DF41%evyncke@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/T5liUO_ctXtaO0cZ3LURFd6bAEI>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <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 <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 17:34:37 -0000

> 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