From nobody Sat Nov 1 02:06:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0251A8876 for ; Sat, 1 Nov 2014 02:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dE4hWQ6KCsE for ; Sat, 1 Nov 2014 02:06:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E111E1A8875 for ; Sat, 1 Nov 2014 02:06:36 -0700 (PDT) Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sA196Cvu065276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2014 10:06:13 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> Date: Sat, 1 Nov 2014 10:06:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GkAPJvf9HF_BQmc3F3gtrUqQEyE Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Nov 2014 09:06:39 -0000 On 01 Nov 2014, at 0:07, Templin, Fred L = wrote: > Just a couple of quick comments: Famous last words... Here are mine: I haven't followed the previous discussions, but what problem are we = trying to solve, exactly? Yes, 6to4 has tons of issues. All the same, there are still people using = it out there today, and I would hazard to guess that they don't have a = better alternative. So why make life worse for them by going out of our = way to kill 6to4? Implementations already prefer IPv4 over 6to4, so I don't think having = 6to4 enabled causes too many problems these days anyway. >> 4. However the above actions are labeled, they make it all the more = obvious that the Internet community lacks an obvious, recommended, and = generally-applicable IPv6-over-IPv4 tunneling mechanism that can be = implemented in a host or router > Maybe, but it does not necessarily need to be ip-proto-41 based. I'll go one step further and say it MUST NOT be protocol 41 based. > And, it need not be specific to IPv6-over-IPv4 =E2=80=93 it would be = much better to have a single mechanism that can support tunneling of = IPvX-over-IPvY for any values of X and Y. Not so sure. If it's strictly IPv6-over-IPv4 there are many = optimizations and simplifications that are possible. However, if we want to go down this path (and we should have done that = 10 years ago, it could very well be too late now) I strongly suggest we = do it right and start with requirements. Here are a few: - if at all possible, autoconfigure everything, if not, configuration = should be limited to something no more complex than a username/password - must be reliable and predictable, so if A - B works and B - C works, A = - C should also work 99.9% of the time - explicit reachability check, so traffic doesn't continue to be sent = into a black hole - work through NAT - work through CGN - automatically adapts to changing addresses - low overhead in gateways (preferably completely stateless) - can be terminated on a home gateway or on a host - doesn't require ISP cooperation - traffic flows are reasonably optimized (i.e., if ISP offers gateway = service, by default, that gateway is used) As I read this, I'm pretty sure that some of the existing tunnel broker = stuff that works over UDP today already does pretty much all of this as = far as the actual tunneling goes. What would be needed is more = streamlined signup and setup processes. Perhaps it could look like this: as a user, you either automatically get = an account using your existing email / cloud service credentials, or you = sign up for a separate account, like iljitsch@ipv6tunnels.example.com. = You enter your username and password into the home gateways and hosts = that you want to have tunneled IPv6 connectivity. The router or host, when it notices that there is no native IPv6, = connects to _tunserv._tcp. or something like that and = authenticates. The setup server then does a lookup of the source IPv4 = address and redirects to a gateway serving that address range. Ideally, = that would be the ISP providing service for those addresses. Or a public = gateway that has good connectivity to those addresses. (There would be = communication between the gateway and setup server operators to avoid = lame delegations. And perhaps the setup server returns multiple = delegations so if one gateway doesn't work the client tries the next = one.) The router or host then talks to that gateway to obtain a prefix and = other configuration info and sets up the tunnel. The host or home = gateway is then responsible for keeping NAT mappings open and = reconnecting when connectivity goes away for some reason. I guess it would be possible for devices to log in using their MAC = address by default. Not sure how much authentication we really need for = this. An account would still be better because that way any errors could = be communicated through email. And logging in using a known service = means the user's activities aren't exposed to additional parties.= From nobody Sat Nov 1 02:14:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09EF1A6FE8 for ; Sat, 1 Nov 2014 02:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeiNphqFbUY4 for ; Sat, 1 Nov 2014 02:14:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654AA1A6F57 for ; Sat, 1 Nov 2014 02:14:55 -0700 (PDT) Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sA19EYRa065327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2014 10:14:35 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> Date: Sat, 1 Nov 2014 10:14:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KKr87WS1nRF_LZafMhUlR-ylZYM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Nov 2014 09:14:57 -0000 On 01 Nov 2014, at 10:06, Iljitsch van Beijnum = wrote: > Perhaps it could look like this: as a user, you either automatically = get an account using your existing email / cloud service credentials [...] Another thing: we could set aside a range of IPv6 addresses to be used = by "tunnels of last resort". These addresses would get a lower priority = than IPv4 addresses in the policy table, so if a tunnel broker / gateway = hands out these addresses it can provide IPv6 connectivity towards = IPv6-only destinations, but dual stack destinations are handled over = IPv4, so the load on the gateway would be much less than in the = situation where regular IPv6 addresses with a higher priority than IPv4 = addresses are used. 3ffe::/16 perhaps? = From nobody Sat Nov 1 02:50:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1878B1A6F3C for ; Sat, 1 Nov 2014 02:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tixxJ6lhrmi for ; Sat, 1 Nov 2014 02:50:31 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAE51A6FEA for ; Sat, 1 Nov 2014 02:50:31 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so2752044ier.30 for ; Sat, 01 Nov 2014 02:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bHixOYK4SoyvlvG0XBQYAWOz+4veW2/NTvqL9fPQcLY=; b=BTQV6GrdKwjZ7FoIF5hFuAoaTI+LBXPVq7QIJkkj1fB4OMHdqL1HlPapT+1TndSRA8 zPSZxOOCGeUi8Sz3cW30yHOKrHWNC5lw+L0OV7I52sXX8DgI2DUeGR3w/6wlN93+uxpE 2N/ZNC3aqzgQWjo9XC90C/jZVBFiJcmltW3FX/U/g6G9QGp8n0NKGI/yFL0f+YgCrkc9 +gi87KJuwMsmRSVhlX3IThGCHcJ1z0myhNRLPgaxfI+r0Ssn4LDewCrx3ft8gkqOI9zw J97L4os4V72FL1RLwaT+VwPdRRn+kNNMOyHyN9KKIYQt7g2hEMQvAIO8CiRmXKGw2/Co 5fGQ== 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=bHixOYK4SoyvlvG0XBQYAWOz+4veW2/NTvqL9fPQcLY=; b=O2U5cFfS6T3VT6nDsZRTD9QSqU/aeRFGOhEDiIZ2ZCDaxehroToJoYwoQEqt3K3GRy Dy59xvcp8asiZgoVUb/ANUuBuKpI2mBLUFS4qofglHxSgRqdnoy3IwfNmDjbbfztRCx+ SKES2ZxiJXfExOh4KXvkzC0K5OfTsEs9JcOdS7Jw2Goehjg9XqaUTQviCZ4LnniIw1y8 Em/pTm4X8vr9IrBsdS7J1LPQGQvk0y62RSWLihqM9Pu1N6YBiiUHFnTtq0kCPMGLV/ow +97UqUfY+5tHionWYUb1rT06tw09+3CI8Jl+V1iqGr7X90UN/SCnrycm+wHKnA5+SpKD 7nWg== X-Gm-Message-State: ALoCoQk0fEkBNJ25guWoXIrMvjDUV4WCH1+LRTeVaPQJ7d0oejteJApIyuROKQLl98BbFecN5Y5d X-Received: by 10.50.136.230 with SMTP id qd6mr2065268igb.2.1414835430625; Sat, 01 Nov 2014 02:50:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.203 with HTTP; Sat, 1 Nov 2014 02:50:10 -0700 (PDT) In-Reply-To: <5452D3F3.50304@gmail.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> From: Lorenzo Colitti Date: Sat, 1 Nov 2014 18:50:10 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0129555e423b830506c90bcb Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g6eRup3mrRzfQP5sPWeYw6xBVDk Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 09:50:34 -0000 --089e0129555e423b830506c90bcb Content-Type: text/plain; charset=UTF-8 On Fri, Oct 31, 2014 at 9:12 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Anyway, please suggest text changes. > So, the problem is not peer-to-peer 6to4 or even relayed 6to4. Both of these work fine, if the clients, the relay routers, and the native nodes are in the same administrative domain. The problem is attempting to run an service where: 1. Users and servers may be anywhere on the Internet. 2. No single entity is responsible for the relay router functionality. 3. The reverse path is essentially random. 4. Implementations use the service by default. Note that neither #1 or #2 apply to successful anycast services like the root servers, because a) there is always a single entity responsible for each anycasted root server prefix, and b) the return path is via standard unicast. I think we all agree that there is ample evidence that this operational model does not work on the Internet. But it can be made to work in limited domains, e.g., inside one network, or between two or more parties that all maintain and support a 6to4 relay router (and that for some reason cannot use native IPv6). Therefore, I think the document should say: 1. Experience with RFC3068-style anycast 6to4 relay routers on the Internet shows that service is often slow and unreliable, because . 2. Pointing a default route at a relay router is NOT RECOMMENDED. 3. Implementations of 6to4 MAY allow configuring the IPv4 address of a relay router, but MUST NOT use a 6to4 relay router by default. 4. Using the 192.88.99.1 anycast address is NOT RECOMMENDED. Thoughts? Cheers, Lorenzo --089e0129555e423b830506c90bcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 9:12 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
Anyway,=C2=A0please s= uggest text changes.

So, the problem is= not peer-to-peer 6to4 or even relayed 6to4. Both of these work fine, if th= e clients, the relay routers, and the native nodes are in the same administ= rative domain. The problem is attempting to run an service where:
  1. Users and servers may be anywhere on the Internet.
  2. No sing= le entity is responsible for the relay router functionality.
  3. The re= verse path is essentially random.
  4. Implementations use the service b= y default.
Note that neither #1 or #2 apply to successful any= cast services like the root servers, because a) there is always a single en= tity responsible for each anycasted root server prefix, and b) the return p= ath is via standard unicast.

I think we = all agree that there is ample evidence that this operational model does not= work on the Internet. But it can be made to work in limited domains, e.g.,= inside one network, or between two or more parties that all maintain and s= upport a 6to4 relay router (and that for some reason cannot use native IPv6= ). Therefore, I think the document should say:
  1. Experience= with RFC3068-style anycast 6to4 relay routers on the Internet shows that s= ervice is often slow and unreliable, because <whatever reasons we can ge= t consensus on; either the ones above, or whatever others>.
  2. = Pointing a default route at a relay router is NOT RECOMMENDED.
  3. Impl= ementations of 6to4 MAY allow configuring the IPv4 address of a relay route= r, but MUST NOT use a 6to4 relay router by default.
  4. Using the 192.8= 8.99.1 anycast address is NOT RECOMMENDED.
Thoughts?

Cheers,
Lorenzo
--089e0129555e423b830506c90bcb-- From nobody Sat Nov 1 03:35:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C707F1A6FEA for ; Sat, 1 Nov 2014 03:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_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 UhYjSstf1EIe for ; Sat, 1 Nov 2014 03:35:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5934D1A1B8C for ; Sat, 1 Nov 2014 03:35:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sA1AZZiZ017536; Sat, 1 Nov 2014 10:35:35 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sA1AZZiZ017536 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1414838137; bh=nzC497epH9ursw5xNx5dghH/NaQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=P0OBSXRxgeaYL78kVKuNrp8BboeMnHqVbZJh184IKY+yvtv+wsj4BUrXDKDw6OiSP +aOH1/OdL+EBBoEfb5E1rglT6fNXNRbGnFE9RoYr7cmz/OLsRbdL9NUNFZE7s6W7e+ HlnfXXjFbUZhdtw+gBYZs3Jokky9ft12VeIK7jJs= 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 qA0AZZ1648601502Qn ret-id none; Sat, 01 Nov 2014 10:35:37 +0000 Received: from [10.67.225.102] (94.197.120.175.threembb.co.uk [94.197.120.175]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sA1AZOGd008036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2014 10:35:27 GMT Content-Type: multipart/alternative; boundary=Apple-Mail-893E1C15-5137-4C0B-8DEC-2700842A5813 Mime-Version: 1.0 (1.0) From: Tim Chown X-Mailer: iPhone Mail (12B411) In-Reply-To: <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> Date: Sat, 1 Nov 2014 10:35:23 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> <18AA8E08-3A39-4555-A842-A486F310486A@ecs.soton.ac.uk> To: Owen DeLong X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qA0AZZ164860150200; tid=qA0AZZ1648601502Qn; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: sA1AZZiZ017536 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/M7JU0NeW6ixs8Nszp83hKuQVHko Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 10:35:53 -0000 --Apple-Mail-893E1C15-5137-4C0B-8DEC-2700842A5813 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30 Oct 2014, at 23:06, Owen DeLong wrote: >>=20 >>=20 >>> On 31/10/2014 06:06, Antonio Querubin wrote:. >>>=20 >>> I suspect there are many other places where this would be true. If the >>> response is 'go get a tunnel' I would ask how easily/quickly could you >>> set that up for a new residential DSL or cable modem user using a single= >>> computer? >=20 > I could set it up very quickly and easily. I could probably do it in under= 15 minutes, > but let=E2=80=99s say 1/2 hour to be overly cautious. >=20 > http://tunnelbroker.net >=20 > There=E2=80=99s even help for exactly how to configure a variety of system= s and routers. Exactly. This works. It's conceptually/practically as easy to use as a VPN service.=20 Tim= --Apple-Mail-893E1C15-5137-4C0B-8DEC-2700842A5813 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 30 Oct 2014, at 23:06, Owen DeLong &= lt;owen@delong.com> wrote:


On 3= 1/10/2014 06:06, Antonio Querubin wrote:.

I suspect there are many other places where this would be t= rue.  If the
response is 'go get a tunnel' I would ask ho= w easily/quickly could you
set that up for a new residential D= SL or cable modem user using a single
computer?
=

I could set it up v= ery quickly and easily. I could probably do it in under 15 minutes,
but let=E2=80=99s say 1/2 hour to be overly cautious.


There=E2=80=99s even help f= or exactly how to configure a variety of systems and routers.

Exactly. This works.

It's conceptually= /practically as easy to use as a VPN service. 

Tim= --Apple-Mail-893E1C15-5137-4C0B-8DEC-2700842A5813-- From nobody Sat Nov 1 08:22:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968981A88F3 for ; Sat, 1 Nov 2014 08:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab0op4zIMZqb for ; Sat, 1 Nov 2014 08:21:59 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618BA1A88E7 for ; Sat, 1 Nov 2014 08:21:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA1FLwJn012750; Sat, 1 Nov 2014 08:21:58 -0700 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA1FLr2U012279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 1 Nov 2014 08:21:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.18]) with mapi id 14.03.0210.002; Sat, 1 Nov 2014 08:21:52 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum Thread-Topic: [v6ops] my recommendation re: 6to4 Thread-Index: AQHP9VzQ4wRvtBZjb0mzKuHwNHu235xK0P5wgAEf1AD//+7toA== Date: Sat, 1 Nov 2014 15:21:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> In-Reply-To: <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.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: http://mailarchive.ietf.org/arch/msg/v6ops/sHCbM_14dhaWT2Emz7peRedBH4s Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Nov 2014 15:22:02 -0000 SGkgSWxqaXRzY2gsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWxq aXRzY2ggdmFuIEJlaWpudW0gW21haWx0bzppbGppdHNjaEBtdWFkYS5jb21dDQo+IFNlbnQ6IFNh dHVyZGF5LCBOb3ZlbWJlciAwMSwgMjAxNCAyOjA2IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwN Cj4gQ2M6IEtlaXRoIE1vb3JlOyB2Nm9wc0BpZXRmLm9yZyBXRw0KPiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBteSByZWNvbW1lbmRhdGlvbiByZTogNnRvNA0KPiANCj4gT24gMDEgTm92IDIwMTQsIGF0 IDA6MDcsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6 DQo+IA0KPiA+IEp1c3QgYSBjb3VwbGUgb2YgcXVpY2sgY29tbWVudHM6DQo+IA0KPiBGYW1vdXMg bGFzdCB3b3Jkcy4uLiBIZXJlIGFyZSBtaW5lOg0KPiANCj4gSSBoYXZlbid0IGZvbGxvd2VkIHRo ZSBwcmV2aW91cyBkaXNjdXNzaW9ucywgYnV0IHdoYXQgcHJvYmxlbSBhcmUgd2UgdHJ5aW5nIHRv IHNvbHZlLCBleGFjdGx5Pw0KPiANCj4gWWVzLCA2dG80IGhhcyB0b25zIG9mIGlzc3Vlcy4gQWxs IHRoZSBzYW1lLCB0aGVyZSBhcmUgc3RpbGwgcGVvcGxlIHVzaW5nIGl0IG91dCB0aGVyZSB0b2Rh eSwgYW5kIEkgd291bGQgaGF6YXJkIHRvIGd1ZXNzIHRoYXQgdGhleSBkb24ndA0KPiBoYXZlIGEg YmV0dGVyIGFsdGVybmF0aXZlLiBTbyB3aHkgbWFrZSBsaWZlIHdvcnNlIGZvciB0aGVtIGJ5IGdv aW5nIG91dCBvZiBvdXIgd2F5IHRvIGtpbGwgNnRvND8NCj4gDQo+IEltcGxlbWVudGF0aW9ucyBh bHJlYWR5IHByZWZlciBJUHY0IG92ZXIgNnRvNCwgc28gSSBkb24ndCB0aGluayBoYXZpbmcgNnRv NCBlbmFibGVkIGNhdXNlcyB0b28gbWFueSBwcm9ibGVtcyB0aGVzZSBkYXlzIGFueXdheS4NCj4g DQo+ID4+IDQuICBIb3dldmVyIHRoZSBhYm92ZSBhY3Rpb25zIGFyZSBsYWJlbGVkLCB0aGV5IG1h a2UgaXQgYWxsIHRoZSBtb3JlIG9idmlvdXMgdGhhdCB0aGUgSW50ZXJuZXQgY29tbXVuaXR5IGxh Y2tzIGFuIG9idmlvdXMsDQo+IHJlY29tbWVuZGVkLCBhbmQgZ2VuZXJhbGx5LWFwcGxpY2FibGUg SVB2Ni1vdmVyLUlQdjQgdHVubmVsaW5nIG1lY2hhbmlzbSB0aGF0IGNhbiBiZSBpbXBsZW1lbnRl ZCBpbiBhIGhvc3Qgb3Igcm91dGVyDQo+IA0KPiA+IE1heWJlLCBidXQgaXQgZG9lcyAgbm90IG5l Y2Vzc2FyaWx5IG5lZWQgdG8gYmUgaXAtcHJvdG8tNDEgYmFzZWQuDQo+IA0KPiBJJ2xsIGdvIG9u ZSBzdGVwIGZ1cnRoZXIgYW5kIHNheSBpdCBNVVNUIE5PVCBiZSBwcm90b2NvbCA0MSBiYXNlZC4N Cg0KT0suDQoNCj4gPiBBbmQsIGl0IG5lZWQgbm90IGJlIHNwZWNpZmljIHRvIElQdjYtb3Zlci1J UHY0IOKAkyBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBoYXZlIGEgc2luZ2xlIG1lY2hhbmlz bSB0aGF0IGNhbiBzdXBwb3J0IHR1bm5lbGluZyBvZg0KPiBJUHZYLW92ZXItSVB2WSBmb3IgYW55 IHZhbHVlcyBvZiBYIGFuZCBZLg0KPiANCj4gTm90IHNvIHN1cmUuIElmIGl0J3Mgc3RyaWN0bHkg SVB2Ni1vdmVyLUlQdjQgdGhlcmUgYXJlIG1hbnkgb3B0aW1pemF0aW9ucyBhbmQgc2ltcGxpZmlj YXRpb25zIHRoYXQgYXJlIHBvc3NpYmxlLg0KDQpXaXRoIHJlc3BlY3QgdG8gQUVSTyBhdCBsZWFz dDsgdGhlIG9ubHkgYWR2YW50YWdlIEkgc2VlIGlzIHRoYXQgZW5jYXBzdWxhdGlvbiBvdmVyIElQ djQNCmluc3RlYWQgb2YgSVB2NiBzYXZlcyAyMCBieXRlcyBwZXIgcGFja2V0LiBJIGd1ZXNzIGFs c28gdGhhdCBkZWFsaW5nIHdpdGggImRlZmF1bHQiIGlzDQpzaW1wbGVyIHRoYW4gZm9yIElQdjYv Zm9vL0lQdjYgZW5jYXBzdWxhdGlvbi4NCg0KPiBIb3dldmVyLCBpZiB3ZSB3YW50IHRvIGdvIGRv d24gdGhpcyBwYXRoIChhbmQgd2Ugc2hvdWxkIGhhdmUgZG9uZSB0aGF0IDEwIHllYXJzIGFnbywg aXQgY291bGQgdmVyeSB3ZWxsIGJlIHRvbyBsYXRlIG5vdykgSSBzdHJvbmdseQ0KDQpUb28gbGF0 ZT8gSWYgd2UgY2FuIGJlIDIweXJzIGludG8gdGhpcyBhbmQgc3RpbGwgbm90IGhhdmUgdWJpcXVp dG91cyBJUHY2IGRlcGxveW1lbnQNCnRoZW4gd2UgYXJlIGNsZWFybHkgbm90IHRvbyBsYXRlLiBJ UHY2IGlzIGEgdmVyeSBvbGQgcHJvdG9jb2wgLSBhbmNpZW50IHJlYWxseSAtIHdlIGp1c3QNCm5l ZWQgdG8gbGVhcm4gdG8gZGVhbCB3aXRoIGl0IGluIG5ldyB3YXlzLg0KDQo+IHN1Z2dlc3Qgd2Ug ZG8gaXQgcmlnaHQgYW5kIHN0YXJ0IHdpdGggcmVxdWlyZW1lbnRzLiBIZXJlIGFyZSBhIGZldzoN Cj4gDQo+IC0gaWYgYXQgYWxsIHBvc3NpYmxlLCBhdXRvY29uZmlndXJlIGV2ZXJ5dGhpbmcsIGlm IG5vdCwgY29uZmlndXJhdGlvbiBzaG91bGQgYmUgbGltaXRlZCB0byBzb21ldGhpbmcgbm8gbW9y ZSBjb21wbGV4IHRoYW4gYQ0KPiB1c2VybmFtZS9wYXNzd29yZA0KDQpPciBhIHNpZ25lZCBjZXJ0 aWZpY2F0ZT8NCg0KPiAtIG11c3QgYmUgcmVsaWFibGUgYW5kIHByZWRpY3RhYmxlLCBzbyBpZiBB IC0gQiB3b3JrcyBhbmQgQiAtIEMgd29ya3MsIEEgLSBDIHNob3VsZCBhbHNvIHdvcmsgOTkuOSUg b2YgdGhlIHRpbWUNCg0KVHJhbnNpdGl2ZSByZWFjaGFiaWxpdHkgY2FuIG5ldmVyIGJlIGFzc3Vt ZWQsIGFuZCBuZWVkcyB0byBiZSB0ZXN0ZWQuICBJIGNhbid0DQpnaXZlIHlvdSBhICUgdGhhdCB3 b3VsZCBob2xkIHRydWUgZm9yIGV2ZXJ5IGRlcGxveW1lbnQgc2NlbmFyaW8uDQoNCj4gLSBleHBs aWNpdCByZWFjaGFiaWxpdHkgY2hlY2ssIHNvIHRyYWZmaWMgZG9lc24ndCBjb250aW51ZSB0byBi ZSBzZW50IGludG8gYSBibGFjayBob2xlDQoNCklQdjYgTkQgTmVpZ2hib3IgVW5yZWFjaGFiaWxp dHkgRGV0ZWN0aW9uIChOVUQpDQoNCj4gLSB3b3JrIHRocm91Z2ggTkFUDQo+IC0gd29yayB0aHJv dWdoIENHTg0KDQpObyBwcm9ibGVtIHRoZXJlLg0KDQo+IC0gYXV0b21hdGljYWxseSBhZGFwdHMg dG8gY2hhbmdpbmcgYWRkcmVzc2VzDQoNCllvdSBtZWFuIGZvciBtb2JpbGl0eSBzdXBwb3J0PyBT dXJlLg0KDQo+IC0gbG93IG92ZXJoZWFkIGluIGdhdGV3YXlzIChwcmVmZXJhYmx5IGNvbXBsZXRl bHkgc3RhdGVsZXNzKQ0KDQpHYXRld2F5cyB0aGF0IHRlcm1pbmF0ZSBhIHR1bm5lbCwgb3IgZ2F0 ZXdheXMgdGhhdCBmb3J3YXJkIHR1bm5lbGVkIHBhY2tldD8NCg0KPiAtIGNhbiBiZSB0ZXJtaW5h dGVkIG9uIGEgaG9tZSBnYXRld2F5IG9yIG9uIGEgaG9zdA0KDQpPSy4NCg0KPiAtIGRvZXNuJ3Qg cmVxdWlyZSBJU1AgY29vcGVyYXRpb24NCg0KT0suDQoNCj4gLSB0cmFmZmljIGZsb3dzIGFyZSBy ZWFzb25hYmx5IG9wdGltaXplZCAoaS5lLiwgaWYgSVNQIG9mZmVycyBnYXRld2F5IHNlcnZpY2Us IGJ5IGRlZmF1bHQsIHRoYXQgZ2F0ZXdheSBpcyB1c2VkKQ0KDQpSb3V0ZSBvcHRpbWl6YXRpb24s IHllcy4NCg0KPiBBcyBJIHJlYWQgdGhpcywgSSdtIHByZXR0eSBzdXJlIHRoYXQgc29tZSBvZiB0 aGUgZXhpc3RpbmcgdHVubmVsIGJyb2tlciBzdHVmZiB0aGF0IHdvcmtzIG92ZXIgVURQIHRvZGF5 IGFscmVhZHkgZG9lcyBwcmV0dHkgbXVjaCBhbGwgb2YNCj4gdGhpcyBhcyBmYXIgYXMgdGhlIGFj dHVhbCB0dW5uZWxpbmcgZ29lcy4gV2hhdCB3b3VsZCBiZSBuZWVkZWQgaXMgbW9yZSBzdHJlYW1s aW5lZCBzaWdudXAgYW5kIHNldHVwIHByb2Nlc3Nlcy4NCg0KREhDUHY2IFBEPw0KDQo+IFBlcmhh cHMgaXQgY291bGQgbG9vayBsaWtlIHRoaXM6IGFzIGEgdXNlciwgeW91IGVpdGhlciBhdXRvbWF0 aWNhbGx5IGdldCBhbiBhY2NvdW50IHVzaW5nIHlvdXIgZXhpc3RpbmcgZW1haWwgLyBjbG91ZCBz ZXJ2aWNlIGNyZWRlbnRpYWxzLCBvcg0KPiB5b3Ugc2lnbiB1cCBmb3IgYSBzZXBhcmF0ZSBhY2Nv dW50LCBsaWtlIGlsaml0c2NoQGlwdjZ0dW5uZWxzLmV4YW1wbGUuY29tLiBZb3UgZW50ZXIgeW91 ciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgaW50byB0aGUgaG9tZQ0KPiBnYXRld2F5cyBhbmQgaG9z dHMgdGhhdCB5b3Ugd2FudCB0byBoYXZlIHR1bm5lbGVkIElQdjYgY29ubmVjdGl2aXR5Lg0KDQpU aGUgZGV2aWNlcyBuZWVkIHRvIGJlIGVucm9sbGVkIGluIHRoZSBzZXJ2aWNlLCBzdXJlLg0KDQo+ IFRoZSByb3V0ZXIgb3IgaG9zdCwgd2hlbiBpdCBub3RpY2VzIHRoYXQgdGhlcmUgaXMgbm8gbmF0 aXZlIElQdjYsIGNvbm5lY3RzIHRvIF90dW5zZXJ2Ll90Y3AuPGRvbWFpbj4gb3Igc29tZXRoaW5n IGxpa2UgdGhhdCBhbmQNCj4gYXV0aGVudGljYXRlcy4gVGhlIHNldHVwIHNlcnZlciB0aGVuIGRv ZXMgYSBsb29rdXAgb2YgdGhlIHNvdXJjZSBJUHY0IGFkZHJlc3MgYW5kIHJlZGlyZWN0cyB0byBh IGdhdGV3YXkgc2VydmluZyB0aGF0IGFkZHJlc3MgcmFuZ2UuDQo+IElkZWFsbHksIHRoYXQgd291 bGQgYmUgdGhlIElTUCBwcm92aWRpbmcgc2VydmljZSBmb3IgdGhvc2UgYWRkcmVzc2VzLiBPciBh IHB1YmxpYyBnYXRld2F5IHRoYXQgaGFzIGdvb2QgY29ubmVjdGl2aXR5IHRvIHRob3NlDQo+IGFk ZHJlc3Nlcy4gKFRoZXJlIHdvdWxkIGJlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgZ2F0ZXdh eSBhbmQgc2V0dXAgc2VydmVyIG9wZXJhdG9ycyB0byBhdm9pZCBsYW1lIGRlbGVnYXRpb25zLiBB bmQNCj4gcGVyaGFwcyB0aGUgc2V0dXAgc2VydmVyIHJldHVybnMgbXVsdGlwbGUgZGVsZWdhdGlv bnMgc28gaWYgb25lIGdhdGV3YXkgZG9lc24ndCB3b3JrIHRoZSBjbGllbnQgdHJpZXMgdGhlIG5l eHQgb25lLikNCg0KVGhlIENsaWVudCBzaG91bGQgYmUgYWJsZSB0byBjaGVjayBmb3IgYSBkaWZm ZXJlbnQgU2VydmVyIGlmIG9uZSBvciBtb3JlIG90aGVyDQpTZXJ2ZXJzIGFyZSBub3Qgd29ya2lu ZywgeWVzLg0KDQo+IFRoZSByb3V0ZXIgb3IgaG9zdCB0aGVuIHRhbGtzIHRvIHRoYXQgZ2F0ZXdh eSB0byBvYnRhaW4gYSBwcmVmaXggYW5kIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mbyBhbmQgc2V0 cyB1cCB0aGUgdHVubmVsLiBUaGUgaG9zdCBvciBob21lDQo+IGdhdGV3YXkgaXMgdGhlbiByZXNw b25zaWJsZSBmb3Iga2VlcGluZyBOQVQgbWFwcGluZ3Mgb3BlbiBhbmQgcmVjb25uZWN0aW5nIHdo ZW4gY29ubmVjdGl2aXR5IGdvZXMgYXdheSBmb3Igc29tZSByZWFzb24uDQoNCkh1aD8gSWYgdGhl IGNvbm5lY3Rpb24gZGllcywgdGhlIE5BVCBtYXBwaW5ncyB3aWxsIGJlIHJlLWVzdGFibGlzaGVk IHdoZW4gdGhlIGNvbm5lY3Rpb24NCmlzIHJlLWVzdGFibGlzaGVkLg0KDQo+IEkgZ3Vlc3MgaXQg d291bGQgYmUgcG9zc2libGUgZm9yIGRldmljZXMgdG8gbG9nIGluIHVzaW5nIHRoZWlyIE1BQyBh ZGRyZXNzIGJ5IGRlZmF1bHQuIE5vdCBzdXJlIGhvdyBtdWNoIGF1dGhlbnRpY2F0aW9uIHdlIHJl YWxseSBuZWVkDQo+IGZvciB0aGlzLiBBbiBhY2NvdW50IHdvdWxkIHN0aWxsIGJlIGJldHRlciBi ZWNhdXNlIHRoYXQgd2F5IGFueSBlcnJvcnMgY291bGQgYmUgY29tbXVuaWNhdGVkIHRocm91Z2gg ZW1haWwuIEFuZCBsb2dnaW5nIGluIHVzaW5nIGENCj4ga25vd24gc2VydmljZSBtZWFucyB0aGUg dXNlcidzIGFjdGl2aXRpZXMgYXJlbid0IGV4cG9zZWQgdG8gYWRkaXRpb25hbCBwYXJ0aWVzLg0K DQpESENQdjYgRFVJRCBkb2VzIG5vdCBuZWVkIHRvIGJlIGJhc2VkIG9uIE1BQyBhZGRyZXNzLg0K DQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo= From nobody Sat Nov 1 08:34:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F961A8910 for ; Sat, 1 Nov 2014 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnP-K5T2WnCN for ; Sat, 1 Nov 2014 08:34:22 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1313A1A890E for ; Sat, 1 Nov 2014 08:34:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA1FYLog020859; Sat, 1 Nov 2014 08:34:21 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA1FYFEd020849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 1 Nov 2014 08:34:15 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.184]) with mapi id 14.03.0210.002; Sat, 1 Nov 2014 08:34:14 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Keith Moore Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP9WfZWwON9vu93Ui5VNj8/MCQtJxL5yrg Date: Sat, 1 Nov 2014 15:34:12 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D763CF@XCH-BLV-504.nw.nos.boeing.com> References: <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <5454244C.6060507@gmail.com> In-Reply-To: <5454244C.6060507@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6V5kuiYMUT0875hlE-PONIEF-oM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 15:34:24 -0000 Hi Brian, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Friday, October 31, 2014 5:08 PM > To: Keith Moore > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt >=20 > Bundling up a few short points: >=20 > On 01/11/2014 03:17, Keith Moore wrote: > ... > >> Doesn't make a big difference in the grand scheme - peer to peer 6to4 > >> is known to work, no matter how implemented, while 6to4-to-native is > >> known to not-work except in controlled environments > > > > The latter statement is simply false. >=20 > Well, the statement needs to be deconstructed. >=20 > 1. 6to4-to-native, not using the anycast method, works if and > only if routing is carefully configured as described in RFC 3056. > It's critical, for example, that every native IPv6 host involved sees > a route to 2002::/16 that leads to a properly configured return relay. >=20 > 2. 6to4-to-native using the anycast method fails in a quite high > proportion of cases because of all the issues descrived in RFC 6343. >=20 > On 01/11/2014 06:15, Templin, Fred L wrote: >=20 > > While I have the floor, I know of at least one enterprise that uses pub= lic IPv4 addresses > > internally. Some devices inside the enterprise see the public addresses= and then assume > > they can use 6to4. They then set up a 6to4 virtual interface with a 200= 2:* address assigned, > > i.e., even though the enterprise has not deployed a 6to4 service. > > > > What would deprecation mean to this class of devices? >=20 > Until somebody upgrades the host software in a way that removes 6to4, > nothing, as far as I can see. It's just the same as p2p 6to4 on the > Internet, isn't it? Can I read this as: "Why fix what a'int broken"? Thanks - Fred fred.l.templin@boeing.com > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Nov 1 12:16:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469911A0143 for ; Sat, 1 Nov 2014 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YTAafX1bqiL8 for ; Sat, 1 Nov 2014 12:16:24 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BAA1A0368 for ; Sat, 1 Nov 2014 12:16:23 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id r10so9202147pdi.31 for ; Sat, 01 Nov 2014 12:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RFqgsb9lDL75KwLUCW6ua3znwMzvB5h4FloBnzSkJD8=; b=v5zSOuabsRgwXq/EmbzlnovkxGFTTSMNZm3pPZv0TlTXEpNBy0oPgYvlbsEhOvUpck k8MqFM2CdN7m+YXOGkyDdAvtcP4CZHejR6jeIrzoz0HNCBECoMik4Yyn5mOr7TD2za5r jks0+Uukx0job2y12u6e1bp1HuWH92MafU36TeEUDQfQabF89SeHLgGsf7Un5ncu0OC2 vq+2JUfTeYoX1fDvIgVJdQzw92MwXEvdzcQ+otadQ8iosTheyfjBqtyk6ktIrw2D3FBW o5i7ODx9hrvL5sHv6QupkEnLO5/pnIDDk7L62qn+8EzMq6mh9BS1BiZvFD0I3t8Niz+r nELg== X-Received: by 10.66.148.74 with SMTP id tq10mr37830pab.122.1414869383480; Sat, 01 Nov 2014 12:16:23 -0700 (PDT) Received: from [192.168.178.23] (26.199.69.111.dynamic.snap.net.nz. [111.69.199.26]) by mx.google.com with ESMTPSA id d17sm13149548pdj.32.2014.11.01.12.16.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 12:16:22 -0700 (PDT) Message-ID: <54553181.1080904@gmail.com> Date: Sun, 02 Nov 2014 08:16:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> <18AA8E08-3A39-4555-A842-A486F310486A@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gzjN-sj5_-UBA2dv0wpzyu8Clhk Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 19:16:26 -0000 On 01/11/2014 23:35, Tim Chown wrote: > On 30 Oct 2014, at 23:06, Owen DeLong wrote: >>> >>>> On 31/10/2014 06:06, Antonio Querubin wrote:. >>>> >>>> I suspect there are many other places where this would be true. If = the >>>> response is 'go get a tunnel' I would ask how easily/quickly could y= ou >>>> set that up for a new residential DSL or cable modem user using a si= ngle >>>> computer? >> I could set it up very quickly and easily. I could probably do it in u= nder 15 minutes, >> but let=E2=80=99s say 1/2 hour to be overly cautious. >> >> http://tunnelbroker.net >> >> There=E2=80=99s even help for exactly how to configure a variety of sy= stems and routers. >=20 > Exactly. This works. >=20 > It's conceptually/practically as easy to use as a VPN service.=20 Which means that it's not zerotouch. It is not fixed by "Did you try switching it off and on again?" The problem with anycast 6to4 is that it was a failed attempt at zerotouch IPv6, and that's what we're really trying to get away from. Brian >=20 > Tim From nobody Sat Nov 1 12:23:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3663E1A035F for ; Sat, 1 Nov 2014 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ovAmoUMN4eM for ; Sat, 1 Nov 2014 12:23:35 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE641A0386 for ; Sat, 1 Nov 2014 12:23:35 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id r10so9207822pdi.31 for ; Sat, 01 Nov 2014 12:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CZEpf+rNEvjgMmCypdQfpDIMB3VW2tlT5h8DIMv4/HI=; b=OeZwtb2j+shs71C9wWn8ZMTvMb6kx0TU5G8Mp6mIH71/CmeYs2UOq/hvDlVlKVgp7/ GsPLnaZZpD8TDfG5pKRGkWQMts+2x/GA7HVUEB2mf9hhHfRi5Obp1O393CqOSFsUURwi G7g3zzpP2MFB94fAzT520ZNayLfwq/8/+vvwQdqyB9Me8bTLpJjrv2lNp/PHvxfUsO9g fOH18ntu+AspiyTToqxx1B+gwNGnKVTSbnqBPaLt2wW6RcDmN4dhZPxbTHmIc6MWEfvA 2dSuGXuWebbJmoKBQxhRIsIbW4dOAC3pFuNMvaM4iKYjqzc5jedtV580K+cPL6Io5GHa nKwA== X-Received: by 10.69.20.74 with SMTP id ha10mr2624072pbd.122.1414869814960; Sat, 01 Nov 2014 12:23:34 -0700 (PDT) Received: from [192.168.178.23] (26.199.69.111.dynamic.snap.net.nz. [111.69.199.26]) by mx.google.com with ESMTPSA id o13sm13105935pby.54.2014.11.01.12.23.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 12:23:33 -0700 (PDT) Message-ID: <54553330.9070800@gmail.com> Date: Sun, 02 Nov 2014 08:23:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xp2uE9Zt9JVsh-JQX00BhFQCBw4 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 19:23:37 -0000 Lorenzo, On 01/11/2014 22:50, Lorenzo Colitti wrote: > On Fri, Oct 31, 2014 at 9:12 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Anyway, please suggest text changes. >> > > So, the problem is not peer-to-peer 6to4 or even relayed 6to4. Both of > these work fine, if the clients, the relay routers, and the native nodes > are in the same administrative domain. The problem is attempting to run an > service where: > > 1. Users and servers may be anywhere on the Internet. > 2. No single entity is responsible for the relay router functionality. > 3. The reverse path is essentially random. > 4. Implementations use the service by default. > > Note that neither #1 or #2 apply to successful anycast services like the > root servers, because a) there is always a single entity responsible for > each anycasted root server prefix, and b) the return path is via standard > unicast. > > I think we all agree that there is ample evidence that this operational > model does not work on the Internet. But it can be made to work in limited > domains, e.g., inside one network, or between two or more parties that all > maintain and support a 6to4 relay router (and that for some reason cannot > use native IPv6). Therefore, I think the document should say: > > 1. Experience with RFC3068-style anycast 6to4 relay routers on the > Internet shows that service is often slow and unreliable, because reasons we can get consensus on; either the ones above, or whatever others>. Actually we've been there and done that: RFC 6343 gives details. No need to rehash it IMHO. > 2. Pointing a default route at a relay router is NOT RECOMMENDED. Hang on, which default route do you mean? > 3. Implementations of 6to4 MAY allow configuring the IPv4 address of a > relay router, but MUST NOT use a 6to4 relay router by default. The new point here is the MAY. The rest is already stated, in different words. > 4. Using the 192.88.99.1 anycast address is NOT RECOMMENDED. Sure. But again, I think that is a restatement of what the draft already says. Anyway: I'm taking this as a hands up for deprecate 3068, leave 3056 alone. > > Thoughts? > > Cheers, > Lorenzo > From nobody Sat Nov 1 18:48:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F91A6EDE for ; Sat, 1 Nov 2014 18:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 6_X2uPtvzBys for ; Sat, 1 Nov 2014 18:48:36 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB31A3B9D for ; Sat, 1 Nov 2014 18:48:36 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA21jJUp024742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Nov 2014 18:45:19 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA21jJUp024742 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414892721; bh=yCAqUJ/3UqdFYR8KRZk7AMTztOw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wMFJjO9YMYOX4ElVSxvtyRa9b5zjrwqxYZUruE+CP4nMyJ+S3MlJCyCSuT9IUKYrp MwEKP1R9kRGV3LypEr1TV5+slxw6toEDLdvCrrtC11Lfo7aFEQ2m1w/rUT6iK37RaA PF/D7I31PtwF7ZawS4vhEly4epPggUkoqzQn8SjA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> Date: Sat, 1 Nov 2014 18:45:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5306B6-0B01-43EB-9B7B-A1CCBE986A51@delong.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 01 Nov 2014 18:45:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mZuj2MMwZdqxEVSK8UxkQXKEe2M Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 01:48:39 -0000 On Nov 1, 2014, at 02:06 , Iljitsch van Beijnum = wrote: > On 01 Nov 2014, at 0:07, Templin, Fred L = wrote: >=20 >> Just a couple of quick comments: >=20 > Famous last words... Here are mine: >=20 > I haven't followed the previous discussions, but what problem are we = trying to solve, exactly? >=20 > Yes, 6to4 has tons of issues. All the same, there are still people = using it out there today, and I would hazard to guess that they don't = have a better alternative. So why make life worse for them by going out = of our way to kill 6to4? >=20 > Implementations already prefer IPv4 over 6to4, so I don't think having = 6to4 enabled causes too many problems these days anyway. >=20 >>> 4. However the above actions are labeled, they make it all the more = obvious that the Internet community lacks an obvious, recommended, and = generally-applicable IPv6-over-IPv4 tunneling mechanism that can be = implemented in a host or router >=20 >> Maybe, but it does not necessarily need to be ip-proto-41 based. >=20 > I'll go one step further and say it MUST NOT be protocol 41 based. Why not? What's wrong with explicitly configured 6in4 tunnels? I'll = grant they don't buy much vs. protocol 45 IPv6 in GRE/IPv4 tunnels, but = there's a little less overhead and the mechanism is already defined, = working, and in fairly wide implementation in various systems, routers, = etc. >=20 >> And, it need not be specific to IPv6-over-IPv4 =96 it would be much = better to have a single mechanism that can support tunneling of = IPvX-over-IPvY for any values of X and Y. >=20 > Not so sure. If it's strictly IPv6-over-IPv4 there are many = optimizations and simplifications that are possible. That seems to argue for preserving 6in4 over protocol 41. >=20 > However, if we want to go down this path (and we should have done that = 10 years ago, it could very well be too late now) I strongly suggest we = do it right and start with requirements. Here are a few: >=20 > - if at all possible, autoconfigure everything, if not, configuration = should be limited to something no more complex than a username/password APIs can accomplish this for 6in4, actually. It's not there yet, but = there's no reason this couldn't be built on existing systems. http://tunnelbroker.net already does this for the "server-side" of the = equation. Username/Password and basically point-click-tunnel. > - must be reliable and predictable, so if A - B works and B - C works, = A - C should also work 99.9% of the time I would argue that is by and large the case with HE's protocol 41 = tunnelbroker. Can you point to reasons you believe otherwise? > - explicit reachability check, so traffic doesn't continue to be sent = into a black hole This would be a lovely addition, but I think it can be added either to = the existing protocol 41 tunnels or on top of them. For example, to some extent, my BGP over 6in4 tunnels have this feature = for some interpretations of the request. > - work through NAT > - work through CGN Meh... There are tunnel mechanisms that achieve this, but they create = unnecessary pain in other areas where these are not a factor. OTOH, I'm = not sure there needs to be "one true tunneling mechanism". Requiring the = additional overhead of UDP in all cases and STUN in general doesn't feel = like a win in the cases where NAT traversal is not required. > - automatically adapts to changing addresses Harder problem to solve. I could, however, do this today with some = development work on an HE tunnel. > - low overhead in gateways (preferably completely stateless) 6in4 already meets this requirement. > - can be terminated on a home gateway or on a host 6in4 already meets this requirement. > - doesn't require ISP cooperation Since all packet forwarding requires some level of ISP cooperation, I = think you need to be a little more clear about your meaning here. If you think this eliminates 6in4 because some ISPs are obnoxious enough = to block protocol 41, then I would suggest there is a reasonable = likelihood that said ISPs will block whatever they have to in order to = block IPv6 tunneling for the same reasons they blocked protocol 41. If you mean something else, then please explicate. > - traffic flows are reasonably optimized (i.e., if ISP offers gateway = service, by default, that gateway is used) This requires some form of service discovery mechanism that can somehow = be aware of what ISP you are using or otherwise has some mechanism for = automatically interfacing with said ISPs provisioning. In the tradition = of rough consensus and running code, it would be great if you put = forward your vision for how this would work. > As I read this, I'm pretty sure that some of the existing tunnel = broker stuff that works over UDP today already does pretty much all of = this as far as the actual tunneling goes. What would be needed is more = streamlined signup and setup processes. I think that could be achieved as an API on top of what exists. However, = see my above comments as to why I don't think that should be the only = available solution and I definitely think that deprecation of configured = 6in4 tunnels would be very premature and somewhat harmful in general. > Perhaps it could look like this: as a user, you either automatically = get an account using your existing email / cloud service credentials, or = you sign up for a separate account, like = iljitsch@ipv6tunnels.example.com. You enter your username and password = into the home gateways and hosts that you want to have tunneled IPv6 = connectivity. It's not UDP based, but FWIW there is an API to the HE tunnelbroker that = was designed to allow home gateway implementers to do essentially just = that through the web API on their gateways. > The router or host, when it notices that there is no native IPv6, = connects to _tunserv._tcp. or something like that and = authenticates. The setup server then does a lookup of the source IPv4 = address and redirects to a gateway serving that address range. Ideally, = that would be the ISP providing service for those addresses. Or a public = gateway that has good connectivity to those addresses. (There would be = communication between the gateway and setup server operators to avoid = lame delegations. And perhaps the setup server returns multiple = delegations so if one gateway doesn't work the client tries the next = one.) This assumes a tremendous amount of cooperation and coordination not in = evidence. Who runs this central "setup server" service? Why? How is it = paid for? > The router or host then talks to that gateway to obtain a prefix and = other configuration info and sets up the tunnel. The host or home = gateway is then responsible for keeping NAT mappings open and = reconnecting when connectivity goes away for some reason. >=20 > I guess it would be possible for devices to log in using their MAC = address by default. Not sure how much authentication we really need for = this. An account would still be better because that way any errors could = be communicated through email. And logging in using a known service = means the user's activities aren't exposed to additional parties. There's also the issue that MAC addresses are only guaranteed to be = segment unique. There are many cases where they are _NOT_ globally = unique. Owen From nobody Sat Nov 1 19:03:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0A31A6F01 for ; Sat, 1 Nov 2014 19:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 hbIY0XROFoF8 for ; Sat, 1 Nov 2014 19:03:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 320DF1A6EFF for ; Sat, 1 Nov 2014 19:03:28 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA221Jdf025364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Nov 2014 19:01:19 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA221Jdf025364 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414893680; bh=eAVUTkitypzi2dtWeer1Kn/a0b0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ago5y5drfkiIxpKZ5NLUrF5FfuK0LR9eVpljyu3KBemJdbADPSgReDRabPQ+iCJiP +HpE89LqfLAFHwd+txcTpb0/rJvJ0EmTB1R8rqApAc1x8VBmzcu0pDUupqujOpZE63 8Rt9heWPP4s7Wry6MO9TUHKl1FiQ7aF4tF5SJYLg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> Date: Sat, 1 Nov 2014 19:01:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> To: "Metzler, Dan J" X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 01 Nov 2014 19:01:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aL3k0Q-hfdWiz_VpvVWtBq3scAc Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 02:03:30 -0000 >=20 > I don't have any kind of business relationship with AT&T, but if I = were a customer, I'd be asking them for my native IPv6 access at that = point. I don't pretend to suggest that there aren't people blocking = protocol 41 for no reason other than fear, and I generally don't think = it's good for a provider to block protocol 41 until they've provided = some alternative. Many have tried. Unfortunately, attempts to put pressure on AT&T by = consumers are roughly equivalant to attempting to use one's thumb to = compress a marshmallow into submission. Your thumb gets messy, but the = marshmallow doesn't care. In this regard, think of AT&T as a giant death-star shaped marshmallow = only more bitter than sweet. > Here's a conversation I had with someone from a somewhat small ISP = downstream from a larger ISP. > Q: "So do you have any plans for deploying IPv6?" > A: "Not really. We've got other projects we're working on, and our = customers haven't really asked for it." > Q: "Well if you wait until your customers are demanding it, = considering most of them are unaware of anything called IPv4, let alone = IPv6, won't it be too late?" > A: "Well, we've been watching the traffic, and we just haven't seen = any demand for it." > Q: "How would you recognize the demand?" > A: "Well, we haven't seen any tunneling, like Teredo or 6to4 traffic." >=20 > I've never forgotten that exchange because I think it is somewhat = representative of the attitude of some ISPs in general, who are not = simply running out of IPv4 address space because they obtained it long = ago, and one benefit of tunneling like this, is just to show ISPs that = there is demand. For situations like that, an ISP can get rid of these = tunnels by beginning an IPv6 implementation, which perhaps just starts = as 6rd. Yep. > With regard to the document in question though, since it does not = deprecate protocol 41 or even lobby against its use, I don't see how = that particular issue is relevant. We're just talking about 6to4, which = is a layer above protocol 41. The point is I'm in favor of providing = reliable tunnel mechanisms to get IPv6 connectivity where network = providers refuse to provide native IPv6, but 6to4 as implemented today, = is probably not the best option for that. I agree. However, I'm not quite to the point of saying it should = certainly be declared deprecated as yet. Owen From nobody Sat Nov 1 22:49:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B481A6FBE for ; Sat, 1 Nov 2014 22:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TFxtsIOO2e1 for ; Sat, 1 Nov 2014 22:49:03 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847E31A6FB9 for ; Sat, 1 Nov 2014 22:49:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA25n2JG022457; Sat, 1 Nov 2014 22:49:02 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA25mua6022441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 1 Nov 2014 22:48:57 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.157]) with mapi id 14.03.0210.002; Sat, 1 Nov 2014 22:48:55 -0700 From: "Templin, Fred L" To: Owen DeLong , Iljitsch van Beijnum Thread-Topic: [v6ops] my recommendation re: 6to4 Thread-Index: AQHP9VzQ4wRvtBZjb0mzKuHwNHu235xK0P5wgAHCkfaAADw6QA== Date: Sun, 2 Nov 2014 05:48:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D768B0@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <6D5306B6-0B01-43EB-9B7B-A1CCBE986A51@delong.com> In-Reply-To: <6D5306B6-0B01-43EB-9B7B-A1CCBE986A51@delong.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: http://mailarchive.ietf.org/arch/msg/v6ops/4AmCOBlEPsSwD3_eYVjovUbh3G4 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 05:49:07 -0000 FWIW, AERO works fine over ip-proto-41 when UDP is not needed. It's just th= at there are lots of places UDP can go that ip-proto-41 can't - and that is without = even taking NATs into account. (UDP can also be easier to work with in application-laye= r implementations, but that is a different subject.) Also, ip-proto-41 does have path MTU challenges. We all know that PMTUD is unreliable, which means the tunnel ingress has to set a "safe" MTU - usuall= y to something on the order of 1480 or smaller. But, that is incongruent with al= l of the hosts that have become conditioned to expect an MTU of at least 1500. On to= p of that, if the tunnel fragments at the IPv4 layer even after setting a "sa= fe" MTU there can be real problems. Unfortunately, after many years of study I fina= lly have to agree that *IPv4* fragmentation is indeed harmful. The transitive connectivity question is an interesting one, and it may depe= nd on specific use cases and deployment scenarios. In enterprise networks, for ex= ample, if A can send a tunneled packet to B, and B can send a tunneled packet to C= , it does not necessarily follow that A can send a tunneled packet to C. Chances are = good that it will work, but the best course of action is to test the path, i.e.,= even if you take an initial optimistic leap of faith that the direct path works. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Saturday, November 01, 2014 6:46 PM > To: Iljitsch van Beijnum > Cc: Templin, Fred L; v6ops@ietf.org WG; Keith Moore > Subject: Re: [v6ops] my recommendation re: 6to4 >=20 >=20 > On Nov 1, 2014, at 02:06 , Iljitsch van Beijnum wrot= e: >=20 > > On 01 Nov 2014, at 0:07, Templin, Fred L wr= ote: > > > >> Just a couple of quick comments: > > > > Famous last words... Here are mine: > > > > I haven't followed the previous discussions, but what problem are we tr= ying to solve, exactly? > > > > Yes, 6to4 has tons of issues. All the same, there are still people usin= g it out there today, and I would hazard to guess that they don't > have a better alternative. So why make life worse for them by going out o= f our way to kill 6to4? > > > > Implementations already prefer IPv4 over 6to4, so I don't think having = 6to4 enabled causes too many problems these days anyway. > > > >>> 4. However the above actions are labeled, they make it all the more = obvious that the Internet community lacks an obvious, > recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism = that can be implemented in a host or router > > > >> Maybe, but it does not necessarily need to be ip-proto-41 based. > > > > I'll go one step further and say it MUST NOT be protocol 41 based. >=20 > Why not? What's wrong with explicitly configured 6in4 tunnels? I'll grant= they don't buy much vs. protocol 45 IPv6 in GRE/IPv4 tunnels, > but there's a little less overhead and the mechanism is already defined, = working, and in fairly wide implementation in various systems, > routers, etc. >=20 >=20 > > > >> And, it need not be specific to IPv6-over-IPv4 - it would be much bett= er to have a single mechanism that can support tunneling of > IPvX-over-IPvY for any values of X and Y. > > > > Not so sure. If it's strictly IPv6-over-IPv4 there are many optimizatio= ns and simplifications that are possible. >=20 > That seems to argue for preserving 6in4 over protocol 41. >=20 > > > > However, if we want to go down this path (and we should have done that = 10 years ago, it could very well be too late now) I strongly > suggest we do it right and start with requirements. Here are a few: > > > > - if at all possible, autoconfigure everything, if not, configuration s= hould be limited to something no more complex than a > username/password >=20 > APIs can accomplish this for 6in4, actually. It's not there yet, but ther= e's no reason this couldn't be built on existing systems. > http://tunnelbroker.net already does this for the "server-side" of the eq= uation. Username/Password and basically point-click-tunnel. >=20 > > - must be reliable and predictable, so if A - B works and B - C works, = A - C should also work 99.9% of the time >=20 > I would argue that is by and large the case with HE's protocol 41 tunnelb= roker. Can you point to reasons you believe otherwise? >=20 > > - explicit reachability check, so traffic doesn't continue to be sent i= nto a black hole >=20 > This would be a lovely addition, but I think it can be added either to th= e existing protocol 41 tunnels or on top of them. >=20 > For example, to some extent, my BGP over 6in4 tunnels have this feature f= or some interpretations of the request. >=20 > > - work through NAT > > - work through CGN >=20 > Meh... There are tunnel mechanisms that achieve this, but they create unn= ecessary pain in other areas where these are not a factor. > OTOH, I'm not sure there needs to be "one true tunneling mechanism". Requ= iring the additional overhead of UDP in all cases and > STUN in general doesn't feel like a win in the cases where NAT traversal = is not required. >=20 > > - automatically adapts to changing addresses >=20 > Harder problem to solve. I could, however, do this today with some develo= pment work on an HE tunnel. >=20 > > - low overhead in gateways (preferably completely stateless) >=20 > 6in4 already meets this requirement. >=20 > > - can be terminated on a home gateway or on a host >=20 > 6in4 already meets this requirement. >=20 > > - doesn't require ISP cooperation >=20 > Since all packet forwarding requires some level of ISP cooperation, I thi= nk you need to be a little more clear about your meaning here. > If you think this eliminates 6in4 because some ISPs are obnoxious enough = to block protocol 41, then I would suggest there is a > reasonable likelihood that said ISPs will block whatever they have to in = order to block IPv6 tunneling for the same reasons they > blocked protocol 41. >=20 > If you mean something else, then please explicate. >=20 > > - traffic flows are reasonably optimized (i.e., if ISP offers gateway s= ervice, by default, that gateway is used) >=20 > This requires some form of service discovery mechanism that can somehow b= e aware of what ISP you are using or otherwise has > some mechanism for automatically interfacing with said ISPs provisioning.= In the tradition of rough consensus and running code, it > would be great if you put forward your vision for how this would work. >=20 > > As I read this, I'm pretty sure that some of the existing tunnel broker= stuff that works over UDP today already does pretty much all > of this as far as the actual tunneling goes. What would be needed is more= streamlined signup and setup processes. >=20 > I think that could be achieved as an API on top of what exists. However, = see my above comments as to why I don't think that should > be the only available solution and I definitely think that deprecation of= configured 6in4 tunnels would be very premature and > somewhat harmful in general. >=20 > > Perhaps it could look like this: as a user, you either automatically ge= t an account using your existing email / cloud service credentials, > or you sign up for a separate account, like iljitsch@ipv6tunnels.example.= com. You enter your username and password into the home > gateways and hosts that you want to have tunneled IPv6 connectivity. >=20 > It's not UDP based, but FWIW there is an API to the HE tunnelbroker that = was designed to allow home gateway implementers to do > essentially just that through the web API on their gateways. >=20 > > The router or host, when it notices that there is no native IPv6, conne= cts to _tunserv._tcp. or something like that and > authenticates. The setup server then does a lookup of the source IPv4 add= ress and redirects to a gateway serving that address range. > Ideally, that would be the ISP providing service for those addresses. Or = a public gateway that has good connectivity to those > addresses. (There would be communication between the gateway and setup se= rver operators to avoid lame delegations. And > perhaps the setup server returns multiple delegations so if one gateway d= oesn't work the client tries the next one.) >=20 > This assumes a tremendous amount of cooperation and coordination not in e= vidence. Who runs this central "setup server" service? > Why? How is it paid for? >=20 > > The router or host then talks to that gateway to obtain a prefix and ot= her configuration info and sets up the tunnel. The host or > home gateway is then responsible for keeping NAT mappings open and reconn= ecting when connectivity goes away for some reason. > > > > I guess it would be possible for devices to log in using their MAC addr= ess by default. Not sure how much authentication we really > need for this. An account would still be better because that way any erro= rs could be communicated through email. And logging in > using a known service means the user's activities aren't exposed to addit= ional parties. >=20 > There's also the issue that MAC addresses are only guaranteed to be segme= nt unique. There are many cases where they are _NOT_ > globally unique. >=20 > Owen From nobody Sun Nov 2 04:32:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D341A871D for ; Sun, 2 Nov 2014 04:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 M2TOBu93GNMV for ; Sun, 2 Nov 2014 04:32:06 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF8A1A8717 for ; Sun, 2 Nov 2014 04:32:05 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:6d03:cbec:da7a:cee5] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sA2CVZn7072137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2014 13:31:36 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> Date: Sun, 2 Nov 2014 13:31:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , Owen DeLong X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qqvjSGL7GdlikIoqSjvJwBPRt3g Cc: "v6ops@ietf.org WG" Subject: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 12:32:10 -0000 If we want to come up with a tunneling mechanism that can replace 6to4 = as the simple, easy choice to get tunneled IPv6 when native isn't = available, perhaps it would be helpful to get together and discuss some = options in Honolulu. If anyone is interested in attending a 6to4 replacement bar BoF, please = email me privately with an indication of your availability and anything = else that may be pertinent. Replying to three messages at once: On 01 Nov 2014, at 16:21, Templin, Fred L = wrote: >>> And, it need not be specific to IPv6-over-IPv4 =E2=80=93 it would be = much better to have a single mechanism that can support tunneling of = IPvX-over-IPvY for any values of X and Y. >> Not so sure. If it's strictly IPv6-over-IPv4 there are many = optimizations and simplifications that are possible. > With respect to AERO at least; the only advantage I see is that = encapsulation over IPv4 instead of IPv6 saves 20 bytes per packet. I = guess also that dealing with "default" is simpler than for IPv6/foo/IPv6 = encapsulation. I had a quick look at the AERO document, and it looks like AERO does = much more than what's needed here. What's the intended use for AERO? >> However, if we want to go down this path (and we should have done = that 10 years ago, it could very well be too late now) I strongly > Too late? If we can be 20yrs into this and still not have ubiquitous = IPv6 deployment > then we are clearly not too late. IPv6 is a very old protocol - = ancient really - we just > need to learn to deal with it in new ways. Good point. It's easy be impressed by 4% IPv6 deployment after it having = been so much lower for more than a decade, but of course that still = leaves 96% on IPv4. >> - if at all possible, autoconfigure everything, if not, configuration = should be limited to something no more complex than a username/password > Or a signed certificate? Hm, that seems pretty complex to me! As an alternative, that would be = fine, but as the sole means to get a tunnel I don't think this would = work well. >> - must be reliable and predictable, so if A - B works and B - C = works, A - C should also work 99.9% of the time > Transitive reachability can never be assumed, and needs to be tested. = I can't > give you a % that would hold true for every deployment scenario. I didn't have transitive connectivity in mind, but rather, that if the = tunnel works, it should work for all destinations, rather than the = situation with Teredo (and also somewhat with 6to4) where A may be able = to talk to B over the tunnel, but can't reach C because tunneled packets = to C follow a different path with different NATs and firewalls. >> - explicit reachability check, so traffic doesn't continue to be sent = into a black hole > IPv6 ND Neighbor Unreachability Detection (NUD) Doesn't that only kick in when there are active sessions? What I have in = mind is a keepalive to determine when the tunnel has gone away (and also = keeps the NAT mappings alive). Such a keepalive wouldn't have to contain = an IPv6 packet but could be an empty (or nearly empty) outer header. >> - automatically adapts to changing addresses > You mean for mobility support? Sure. The tunnel being torn down and a new one being created would also work. >> - low overhead in gateways (preferably completely stateless) > Gateways that terminate a tunnel, or gateways that forward tunneled = packet? Both. :-) >> As I read this, I'm pretty sure that some of the existing tunnel = broker stuff that works over UDP today already does pretty much all of >> this as far as the actual tunneling goes. What would be needed is = more streamlined signup and setup processes. > DHCPv6 PD? Although that has the advantage of being a general purpose mechanism, I = don't think it's the best solution, because now you first need the = tunnel to work before you can discover the prefix that you get. If = there's going to be some kind of negotiation for setting up the tunnel = (which there is in what I have in mind, but not in 6to4 and many other = mechanisms) then it's easy enough to incorporate prefix discovery there = and reduce the number of dependencies. >> The router or host then talks to that gateway to obtain a prefix and = other configuration info and sets up the tunnel. The host or home >> gateway is then responsible for keeping NAT mappings open and = reconnecting when connectivity goes away for some reason. > Huh? If the connection dies, the NAT mappings will be re-established = when the connection is re-established. Yes, but wouldn't it be better to avoid having the connection die? >> I guess it would be possible for devices to log in using their MAC = address by default. Not sure how much authentication we really need >> for this. An account would still be better because that way any = errors could be communicated through email. And logging in using a >> known service means the user's activities aren't exposed to = additional parties. > DHCPv6 DUID does not need to be based on MAC address. If we require DHCPv6 then this would be an option. However, how do you = know your DHCPv6 DUID? Finding a system's MAC address is easy enough. On 02 Nov 2014, at 2:45, Owen DeLong wrote: >> I'll go one step further and say it MUST NOT be protocol 41 based. > Why not? Because you're limited to one proto 41 user behind an IPv4 address and = thus won't work for CGN users. > What's wrong with explicitly configured 6in4 tunnels? I use one every day so there's a lot right with them. The trouble is = that they involve too much configuration and aren't flexible enough. For = instance, when I get a new IPv4 address from my ISP I need to go into = the tunnelbroker.net web interface to update my tunnel endpoint. But like I mentioned later in my message, I think much of what's = required can already be found in existing tunnel broker systems, perhaps = all that's needed is to bring it all together in a way that allows it to = be almost as easy to use as 6to4, while continuing to benefit from the = much better reliability of explicitly created tunnels. >> - work through NAT >> - work through CGN > Meh... There are tunnel mechanisms that achieve this, but they create = unnecessary pain in other areas where these are not a factor. OTOH, I'm = not sure there needs to be "one true tunneling mechanism". Requiring the = additional overhead of UDP in all cases and STUN in general doesn't feel = like a win in the cases where NAT traversal is not required. Even in the case where the tunnel is terminated on a home gateway and = the user isn't behind a CGN, it's not uncommon for NAT to be in the = middle because the tunnel endpoint is on a different box than the = ISP-provided NAT box. So I'd say: eat the 8 bytes of UDP for the case of = simplicity, even when it's not necessary. No need for STUN or = Teredo-like complexity if the tunnel is set up from the inside to a = single outside destination, you just need to generate traffic = periodically to keep the NAT state in place. And you want keepalives = anyway to determine when the tunnel has gone down for another reason = (such as an IPv4 address change). Another way to go would be to allow a few different types of existing = tunnel mechanisms, most notably 6rd. This would make the system a little = more complex on the client side, but allows for reusing existing gateway = side implementations. If we go down that route, it would be easy enough = to include the option for the new system to simply retrieve a fixed = proto 41 configuration and be fully compatible with existing tunnel = brokers. >> - automatically adapts to changing addresses > Harder problem to solve. I could, however, do this today with some = development work on an HE tunnel. Tunnel down -> reinitiate it from scratch. Simple enough for the client. = The tunnel broker would need some way to get the new client address, = though. >> - doesn't require ISP cooperation > Since all packet forwarding requires some level of ISP cooperation, I = think you need to be a little more clear about your meaning here. I mean in the sense that it still works if the ISP doesn't do anything = to help. It still working if the ISP goes out of its way to filter would be = another step. And I don't think we should attempt that, as it would be = hard to do and also because non-ISP networks such as businesses and = universities have a reasonably legitimate reason to not want to have = arbitrary tunnels on their networks. Obviously we'd want those networks to offer native IPv6, but if our new = tunnel mechanism can be terminated on the inside of such networks and = then firewalled the same way as other traffic would also be a good = solution. >> - traffic flows are reasonably optimized (i.e., if ISP offers gateway = service, by default, that gateway is used) > This requires some form of service discovery mechanism that can = somehow be aware of what ISP you are using or otherwise has some = mechanism for automatically interfacing with said ISPs provisioning. Yes. > In the tradition of rough consensus and running code, it would be = great if you put forward your vision for how this would work. What I have in mind is that there is a list of gateways and users are = connected to the gateway that serves them best, which would typically be = their ISP's gateway if they run one. > I definitely think that deprecation of configured 6in4 tunnels would = be very premature and somewhat harmful in general. I agree; existing tunnel brokers should definitely keep doing for some = time to come. But do you agree that the current tunnel broker system is too complex to = serve the role that 6to4 was intended to serve? >> The router or host, when it notices that there is no native IPv6, = connects to _tunserv._tcp. or something like that and = authenticates. The setup server then does a lookup of the source IPv4 = address and redirects to a gateway... > This assumes a tremendous amount of cooperation and coordination not = in evidence. Who runs this central "setup server" service? Why? How is = it paid for? What I imagine is that existing cloud services would incorporate that, = most notably Apple, Google and Microsoft, who all have shown various = levels of interest in getting IPv6 working well. But also any other = interested party, such as the existing tunnel brokers. The technical = part is basically running a web server and a user database, which = doesn't cost a meaningful amount of money. The harder part is the coordination, but the benefit is huge: you get a = tunnel that's terminated as close to the user as possible without = requiring any action from the user to accomplish this. >> I guess it would be possible for devices to log in using their MAC = address by default. > There's also the issue that MAC addresses are only guaranteed to be = segment unique. There are many cases where they are _NOT_ globally = unique. If the u/l bit is set to "unique" then they really are supposed to be = globally unique... Obviously there's ample evidence of failures in this = area, but how many affected devices are we talking about here? A = fraction of a fraction of a percent? There is no reason why one account couldn't set up multiple tunnels, so = this shouldn't be an issue. The reason to have accounts at all is to be = able to block them if people do bad things. Then you are blocked if you = use the default account and the user of a clone of your MAC address does = bad things. So set up a real account and your tunnel is back. On 02 Nov 2014, at 6:48, Templin, Fred L = wrote: > Also, ip-proto-41 does have path MTU challenges. We all know that = PMTUD is > unreliable, which means the tunnel ingress has to set a "safe" MTU - = usually to > something on the order of 1480 or smaller. This is hard to avoid. Hopefully, with IPv6 there is enough tunneling = that people will clean up their PMTUD breakage rather than let those = with path MTUs below 1500 suffer, like what happens with IPv4. A solution could be for home gateways that terminate a tunnel to = advertise the tunnel MTU in their RAs so hosts use the tunnel MTU and = also put that MTU in their TCP MSS. Iljitsch From nobody Sun Nov 2 05:16:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6E61A8796 for ; Sun, 2 Nov 2014 05:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 4HW7PPFDMzWM for ; Sun, 2 Nov 2014 05:15:59 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC381A878C for ; Sun, 2 Nov 2014 05:15:59 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 9AEE3100A111B; Sun, 2 Nov 2014 13:15:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414934155; bh=HjIx0LidfWGFWnMhvRQIDRi7HxPGUwQ9ORW9ZPJ+TvY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=0nnWRbEpblMuGt2mhHjgM2J9X42KmVSz1q1AiwsZcA4nOIDtAecWbKu6xEz1A2AU5 IK81Or95/VKAkXZfEYP9+uZpu3hlqawTaWi38QdaHPanTuuHR9Zdt6qpKbjTSzo7r4 PQ3PKQmZ2sFiFgRaM0SIGaBFnqLnCjwzVRXXTLdXJg8SppDHRUevXJ+/zszvvsIONl 95Zv+KOAqab7UKbVSpXsuh+jB6K1KdPfo2uQxlGQtwTawcKCCrZFHISDNPBwOYq0iM G9vL479RophXr1MgxKhbfs69rHYk8YNijU5fElKq+ZmH0S30thRp1aiO8C+sAFGyFt fWvLNjZRWaogQ== Message-ID: <54562E86.7000208@massar.ch> Date: Sun, 02 Nov 2014 14:15:50 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum , "Templin, Fred L" , Owen DeLong References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MvY82L1MaeVmM4WeenzSwDxmwKk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 13:16:02 -0000 On 2014-11-02 13:31, Iljitsch van Beijnum wrote: > If we want to come up with a tunneling mechanism that can replace > 6to4 as the simple, easy choice to get tunneled IPv6 when native > isn't available, perhaps it would be helpful to get together and > discuss some options in Honolulu. (Note that not everybody gets to take holiday trips to exotic destinations for "work"; rather go there for vacation and enjoy the scenery then sitting in a conference room over there...). I don't think that "replacing" 6to4 is going to bring anything useful at this point in time. This "transition" game has been running for close to 20 years already... And during that time several tools have come into existence and have gained wide deployment that solve these issues. Teredo is the generic thing, no signup required, used heavily by Xbox One when no native is available. But like 6to4 it has the anycast problem: unreliable, hard to debug what goes wrong. Tunnel Broker related (somebody needs to provide the service and keep things working): - heartbeat https://www.sixxs.net/tools/heartbeat/ - sidechannel to proto-41 packets - solves the problem that people have dynamic IPv4 addresses - 10+ years old and heavily in use - as it still uses proto-41, does not work behind NAT[*] - RFC 5572 - TSP / Tunnel Setup Protocol http://tools.ietf.org/html/rfc5572 - solves setup/configuration + NAT traversal (using UDP packets) - AYIYA https://www.sixxs.net/tools/ayiya/ https://en.wikipedia.org/wiki/Anything_In_Anything (never went to RFC as "ipv6 WG does not do tunnels anymore" was the argument back then, hence also why TSP is a 'experimental' non-wg document) - solves dynamic IP + NAT traversal (signed UDP packets) - TIC https://www.sixxs.net/tools/tic/ - solves configuring a tunnel, the very simple way (linebased, no XML) As for implementation. Both TSP and TIC/heartbeat/AYIYA can be found in a variety of off-the-shelf hardware NAT boxes aka "consumer routers": AVM Fritz!Box, Motorola, DrayTek etc. Or just download the software for your favourite platform: - tspc (eg https://packages.debian.org/sid/tspc) - aiccu (https://www.sixxs.net/tools/aiccu/ or https://packages.debian.org/sid/aiccu) of course available for a variety of platforms (heartbeat even for Cisco IOS ;). And then, I am not even going to the route of OpenVPN/tinc and thousands of other tunneling techniques that can carry IPv6 packets inside IPv4 and can do VPNs. What part of '6to4 exactly needs a replacement while all these things have been available for years already? Greets, Jeroen [*] setting your NAT box to DMZ mode so that a specific host gets all packets and that that host terminates the tunnel is an option. Not all users get that though and not all boxes handle it properly... From nobody Sun Nov 2 05:37:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0797B1A879A for ; Sun, 2 Nov 2014 05:37:15 -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, 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 x8AlOqfAgLYx for ; Sun, 2 Nov 2014 05:37:13 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D194E1A8799 for ; Sun, 2 Nov 2014 05:37:12 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Sun, 2 Nov 2014 07:37:11 -0600 From: "Metzler, Dan J" To: Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEIAAb7GA///B4hCAAoRIgIAAUB2A Date: Sun, 2 Nov 2014 13:37:10 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/d8KRPENtRqaOCSrRc1pCnOV6y18 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 13:37:15 -0000 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Saturday, November 1, 2014 9:02 PM > To: Metzler, Dan J > Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt= - > alternatives to 6to4 >=20 > > > > I don't have any kind of business relationship with AT&T, but if I were= a > customer, I'd be asking them for my native IPv6 access at that point. I = don't > pretend to suggest that there aren't people blocking protocol 41 for no > reason other than fear, and I generally don't think it's good for a provi= der to > block protocol 41 until they've provided some alternative. >=20 > Many have tried. Unfortunately, attempts to put pressure on AT&T by > consumers are roughly equivalant to attempting to use one's thumb to > compress a marshmallow into submission. Your thumb gets messy, but the > marshmallow doesn't care. >=20 > In this regard, think of AT&T as a giant death-star shaped marshmallow on= ly > more bitter than sweet. >=20 While I understand that there is a large degree of truth to this, I disagre= e with regard to the notion that any real attempts have been made to put pr= essure on AT&T or similar ISPs. To put it in a less confrontational way, I= don't think there have been attempts to provide ISPs with the necessary gu= idance or tools to know what the correct behavior is. For example how abou= t an RFC that defines standards of acceptable ISP behavior and provides a g= rading system. This is something that customers can use when shopping for = ISPs. We could give classifications based on certain standards. For example from an IPv6 perspective: "A" - ISP implements Native IPv6 and/or 6rd "D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does not = block any traffic including that which might allow a customer to implement = IPv6. "F" - ISP blocks traffic according to its own policies without customer end= orsement. (Not the function of an ISP.) Something like this would allow for a meaningful conversation with ISPs lik= e AT&T, and provide context for rating ISPs in terms of brokenness of their= implementations, and a basis for publishing that information. Of course t= hese categories would not just be limited to the context of IPv6 adoption, = would have to be maintained as technologies come and go, and would provide = a more general measure for reliability and basic functionality. ISPs that claim grade A according to RFC #### could advertise that, and cus= tomers could be assured by sticking with grade A ISPs, they can accomplish = anything they need to in terms of standard internet functionality. A simpl= e Wiki could be maintained by communities regarding what the grades or for = various ISPs. =20 In any case, my point is, while individuals may have complained to somebody= working at AT&T, at various times, no real pressure has been put on AT&T o= r any other ISP, even to adopt IPv6 or to allow for customers to do so. No= incentives have been provided either. We've thus far relied only on the n= otion that they will work toward the goal as they see an impact from lack o= f IPv4 addresses. The idea that I would, as a customer ask, "where is my n= ative IPv6", was less about applying pressure, and more about starting the = conversation about what they could provide me as a customer. From nobody Sun Nov 2 05:45:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF6D1A87A3 for ; Sun, 2 Nov 2014 05:45:05 -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 2lcQA_0KGBv5 for ; Sun, 2 Nov 2014 05:45:04 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8811D1A879E for ; Sun, 2 Nov 2014 05:45:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA2Dj2YS024101; Sun, 2 Nov 2014 05:45:02 -0800 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA2DiqKL023420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Nov 2014 05:44:53 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.92]) with mapi id 14.03.0210.002; Sun, 2 Nov 2014 05:44:52 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum , Owen DeLong Thread-Topic: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9qMt4BbbQDigd0q453hkDOpXZw== Date: Sun, 2 Nov 2014 13:44:52 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76A91@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@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: http://mailarchive.ietf.org/arch/msg/v6ops/rjlUhwrTSmcJB-SwH1H8iuWyXJg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 13:45:06 -0000 SGkgSWxqaXRzY2gsDQoNCkRvbid0IGJlIHRvbyBxdWljayB0byB3cml0ZSBvZmYgQUVSTy4gQUVS TyBpcyBOQk1BIC0geW91IHNob3VsZCBsaWtlIHRoYXQsIGJlY2F1c2UNCml0IGhhcyBhIGxvdCBp biBjb21tb24gd2l0aCBFdGhlcm5ldCBleGNlcHQgZm9yIGxhY2sgb2YgbGluay1zY29wZWQgbXVs dGljYXN0LiBUaGluayBvZg0KeW91ciBjdXN0b21lciB0dW5uZWwgZW5kcG9pbnRzIGFzIEFFUk8g Q2xpZW50cyBhbmQgeW91ciBwcm92aWRlciB0dW5uZWwgZW5kcG9pbnRzDQphcyBBRVJPIFNlcnZl cnMuIFJvdXRlIG9wdGltaXphdGlvbiBnaXZlcyB5b3UgQ2xpZW50LXRvLUNsaWVudC4gREhDUHY2 IFBEIGlzIHRoZSBjb250cm9sDQpwbGFuZSBzaWduYWxpbmcgYmV0d2VlbiBDbGllbnRzIGFuZCBT ZXJ2ZXJzLCBhbmQgSVB2NiBORCBpcyB0aGUgY29udHJvbCBwbGFuZSBzaWduYWxpbmcNCmJldHdl ZW4gcGFpcnMgb2YgQ2xpZW50cy4NCg0KQWJvdXQgTVRVOg0KDQogPiBPbiAwMiBOb3YgMjAxNCwg YXQgNjo0OCwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90 ZToNCj4gDQo+ID4gQWxzbywgaXAtcHJvdG8tNDEgZG9lcyBoYXZlIHBhdGggTVRVIGNoYWxsZW5n ZXMuIFdlIGFsbCBrbm93IHRoYXQgUE1UVUQgaXMNCj4gPiB1bnJlbGlhYmxlLCB3aGljaCBtZWFu cyB0aGUgdHVubmVsIGluZ3Jlc3MgaGFzIHRvIHNldCBhICJzYWZlIiBNVFUgLSB1c3VhbGx5IHRv DQo+ID4gc29tZXRoaW5nIG9uIHRoZSBvcmRlciBvZiAxNDgwIG9yIHNtYWxsZXIuDQo+IA0KPiBU aGlzIGlzIGhhcmQgdG8gYXZvaWQuIEhvcGVmdWxseSwgd2l0aCBJUHY2IHRoZXJlIGlzIGVub3Vn aCB0dW5uZWxpbmcgdGhhdCBwZW9wbGUgd2lsbCBjbGVhbiB1cCB0aGVpciBQTVRVRCBicmVha2Fn ZSByYXRoZXIgdGhhbiBsZXQNCj4gdGhvc2Ugd2l0aCBwYXRoIE1UVXMgYmVsb3cgMTUwMCBzdWZm ZXIsIGxpa2Ugd2hhdCBoYXBwZW5zIHdpdGggSVB2NC4NCg0KTm90IGlmIHlvdSB1c2UgdHVubmVs IGZyYWdtZW50YXRpb24gYW5kIHByb2JpbmcuIFRoaXMgaXMgc3BlY2lmaWNhbGx5IE5PVCBJUHY0 LWxheWVyDQpmcmFnbWVudGF0aW9uLCBOT1QgSVB2Ni1sYXllciBmcmFnbWVudGF0aW9uIGFuZCBO T1QgUkZDNDgyMSBwcm9iaW5nIC0gaXQgaXMgYSBwcml2YXRlDQphcnJhbmdlbWVudCBiZXR3ZWVu IHRoZSB0dW5uZWwgaW5ncmVzcyBhbmQgZWdyZXNzIHRoYXQgaXMgbm90IHZpc2libGUgYXQgdGhl IGlubmVyIG9yDQpvdXRlciBJUCBsYXllci4gQW4gYXNzdXJlZCBtaW5pbXVtIG9mIDE1MDAgYnl0 ZXMgaXMgdGhlcmVmb3JlIHByb3ZpZGVkLCBhbmQgaWYgbGFyZ2VyDQpwYWNrZXRzIGNhbiBmaXQg dGhleSB3aWxsIGJlIGFjY29tbW9kYXRlZCBhcyB3ZWxsLg0KDQo+IEEgc29sdXRpb24gY291bGQg YmUgZm9yIGhvbWUgZ2F0ZXdheXMgdGhhdCB0ZXJtaW5hdGUgYSB0dW5uZWwgdG8gYWR2ZXJ0aXNl IHRoZSB0dW5uZWwgTVRVIGluIHRoZWlyIFJBcyBzbyBob3N0cyB1c2UgdGhlIHR1bm5lbCBNVFUN Cj4gYW5kIGFsc28gcHV0IHRoYXQgTVRVIGluIHRoZWlyIFRDUCBNU1MuDQoNClRoaXMgY2FuIGhh dmUgYSBjYXNjYWRpbmcgZGVnZW5lcmF0ZSBNVFUgcHJvYmxlbXMgaWYgdGhlcmUgYXJlIHR1bm5l bHMgd2l0aGluIHR1bm5lbHMNCmluc2lkZSB0aGUgc2l0ZS4gVXNlIGEgcmVhbCB0dW5uZWwgTVRV IG1pdGlnYXRpb24sIGFuZCB0aGUgc2l0ZSB3aWxsIG5ldmVyIHNlZSBhbiBNVFUNCnNtYWxsZXIg dGhhbiAxNTAwIChpLmUuLCBhIGRlZ2VuZXJhdGUgTVRVKS4NCg0KVGhhbmtzIC0gRnJlZA0KZnJl ZC5sLnRlbXBsaW5AYm9laW5nLmNvbSANCiANCj4gSWxqaXRzY2gNCg0K From nobody Sun Nov 2 06:56:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044A1A8860 for ; Sun, 2 Nov 2014 06:56:29 -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 z_oW2TBQ4d11 for ; Sun, 2 Nov 2014 06:56:26 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82371A885F for ; Sun, 2 Nov 2014 06:56:26 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h3so3432958igd.2 for ; Sun, 02 Nov 2014 06:56: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:date:message-id:subject:from:to :cc:content-type; bh=9VcqxT5zx1kHu/hfTVI7mxtbDnqmLs1rGOFYUNVLJ0c=; b=XOqOBKQPIip7yvcSbcYATU7Yv4+ukq1wKmmIKYYjThrwWAbMCaL9gddYA9TkNwvK/M skT+jJH5cL7ftE5XNu1bcYrmqOrDi23SXVM3VEnMr65QD2mUx3xDK8PMf9teWy7eSZmo p/kE8SCDENlkNv/KxV1s12OqbiYFVYpzP2qLGVJsTl5z33S6MNDV6wC8uJczTL98Ul+H 7eyypoEqkLSXNAqs5fdiSGnqXSWZQ6w6G41VuilztSNh6slcL2JvvOeglxLvWcmgd2XK ODi+9H0TuxlXYvx1Kh4eOqBlVXaecyynv8rTJnNMq4xeFP1eKGRUK9F/NE6Vs64bxBdK gKuA== 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=9VcqxT5zx1kHu/hfTVI7mxtbDnqmLs1rGOFYUNVLJ0c=; b=TuA1WESZnFYqpw1KmMINj/c6McrXgFenxL6MDDQ/84ucwjZD3ueKaWpzM5qjuVsCD2 V/rzVEN3RIpo3Q5Zhy8YtHpjCWXqQb7u5cRr0tXKylPbyrhaO03LJqnPyqeAv7hnW7Yb XKAP6nFYTmXtuVH12YuksBfeF4cd1+iV3sUPpp5mts+nwx48G46Galnt9hx/YVW1A2hE 0x2wRA/p1BEBr3Z3/cvo12oFhKKo2wvWWM9ekOEiYGSoDjvLDXVuH/RndpPZa6vtjDpr jqyzgkas4vOrb+ZOO4uB0WW+O6i+9o0a6mzC9wASCqkLxNz+5pofLTHsHw4WuWMjwgJK iEaQ== X-Gm-Message-State: ALoCoQkx0wM28+4T5TWi4lpdE4D+e3eaeBPlr+gSsSdb0Z/BQl2+EvOBMgVUfv5H7yF9XPTcd6zy MIME-Version: 1.0 X-Received: by 10.43.181.69 with SMTP id ph5mr1575885icc.83.1414940185946; Sun, 02 Nov 2014 06:56:25 -0800 (PST) Received: by 10.64.176.203 with HTTP; Sun, 2 Nov 2014 06:56:25 -0800 (PST) Received: by 10.64.176.203 with HTTP; Sun, 2 Nov 2014 06:56:25 -0800 (PST) In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> Date: Sun, 2 Nov 2014 23:56:25 +0900 Message-ID: From: Lorenzo Colitti To: "Metzler, Dan J" Content-Type: multipart/alternative; boundary=001a11c3b40c2999b30506e16f95 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/n24yqKx7IIg3vFank7S-_kiOplQ Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 14:56:29 -0000 --001a11c3b40c2999b30506e16f95 Content-Type: text/plain; charset=UTF-8 You are aware that fully 25% of AT&T's users do have IPv6, right? On 2 Nov 2014 10:37 pm, "Metzler, Dan J" wrote: > > > > -----Original Message----- > > From: Owen DeLong [mailto:owen@delong.com] > > Sent: Saturday, November 1, 2014 9:02 PM > > To: Metzler, Dan J > > Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; v6ops@ietf.org > WG > > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-6to4-to-historic-06.txt - > > alternatives to 6to4 > > > > > > > > I don't have any kind of business relationship with AT&T, but if I > were a > > customer, I'd be asking them for my native IPv6 access at that point. I > don't > > pretend to suggest that there aren't people blocking protocol 41 for no > > reason other than fear, and I generally don't think it's good for a > provider to > > block protocol 41 until they've provided some alternative. > > > > Many have tried. Unfortunately, attempts to put pressure on AT&T by > > consumers are roughly equivalant to attempting to use one's thumb to > > compress a marshmallow into submission. Your thumb gets messy, but the > > marshmallow doesn't care. > > > > In this regard, think of AT&T as a giant death-star shaped marshmallow > only > > more bitter than sweet. > > > > While I understand that there is a large degree of truth to this, I > disagree with regard to the notion that any real attempts have been made to > put pressure on AT&T or similar ISPs. To put it in a less confrontational > way, I don't think there have been attempts to provide ISPs with the > necessary guidance or tools to know what the correct behavior is. For > example how about an RFC that defines standards of acceptable ISP behavior > and provides a grading system. This is something that customers can use > when shopping for ISPs. We could give classifications based on certain > standards. > For example from an IPv6 perspective: > "A" - ISP implements Native IPv6 and/or 6rd > "D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does not > block any traffic including that which might allow a customer to implement > IPv6. > "F" - ISP blocks traffic according to its own policies without customer > endorsement. (Not the function of an ISP.) > > Something like this would allow for a meaningful conversation with ISPs > like AT&T, and provide context for rating ISPs in terms of brokenness of > their implementations, and a basis for publishing that information. Of > course these categories would not just be limited to the context of IPv6 > adoption, would have to be maintained as technologies come and go, and > would provide a more general measure for reliability and basic > functionality. > > ISPs that claim grade A according to RFC #### could advertise that, and > customers could be assured by sticking with grade A ISPs, they can > accomplish anything they need to in terms of standard internet > functionality. A simple Wiki could be maintained by communities regarding > what the grades or for various ISPs. > > In any case, my point is, while individuals may have complained to > somebody working at AT&T, at various times, no real pressure has been put > on AT&T or any other ISP, even to adopt IPv6 or to allow for customers to > do so. No incentives have been provided either. We've thus far relied > only on the notion that they will work toward the goal as they see an > impact from lack of IPv4 addresses. The idea that I would, as a customer > ask, "where is my native IPv6", was less about applying pressure, and more > about starting the conversation about what they could provide me as a > customer. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c3b40c2999b30506e16f95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You are aware that fully 25% of AT&T's users do have= IPv6, right?

On 2 Nov 2014 10:37 pm, "Metzler, Dan J&quo= t; <dan-metzler@uiowa.edu&g= t; wrote:


> -----Original Message-----
> From: Owen DeLong [mailto:owen@delo= ng.com]
> Sent: Saturday, November 1, 2014 9:02 PM
> To: Metzler, Dan J
> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; v6ops@ietf.org WG
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.= txt -
> alternatives to 6to4
>
> >
> > I don't have any kind of business relationship with AT&T,= but if I were a
> customer, I'd be asking them for my native IPv6 access at that poi= nt.=C2=A0 I don't
> pretend to suggest that there aren't people blocking protocol 41 f= or no
> reason other than fear, and I generally don't think it's good = for a provider to
> block protocol 41 until they've provided some alternative.
>
> Many have tried. Unfortunately, attempts to put pressure on AT&T b= y
> consumers are roughly equivalant to attempting to use one's thumb = to
> compress a marshmallow into submission. Your thumb gets messy, but the=
> marshmallow doesn't care.
>
> In this regard, think of AT&T as a giant death-star shaped marshma= llow only
> more bitter than sweet.
>

While I understand that there is a large degree of truth to this, I disagre= e with regard to the notion that any real attempts have been made to put pr= essure on AT&T or similar ISPs.=C2=A0 To put it in a less confrontation= al way, I don't think there have been attempts to provide ISPs with the= necessary guidance or tools to know what the correct behavior is.=C2=A0 Fo= r example how about an RFC that defines standards of acceptable ISP behavio= r and provides a grading system.=C2=A0 This is something that customers can= use when shopping for ISPs.=C2=A0 We could give classifications based on c= ertain standards.
For example from an IPv6 perspective:
"A" - ISP implements Native IPv6 and/or 6rd
"D" - ISP implements no Native IPv6, and provides no 6rd, but ISP= does not block any traffic including that which might allow a customer to = implement IPv6.
"F" - ISP blocks traffic according to its own policies without cu= stomer endorsement. (Not the function of an ISP.)

Something like this would allow for a meaningful conversation with ISPs lik= e AT&T, and provide context for rating ISPs in terms of brokenness of t= heir implementations, and a basis for publishing that information.=C2=A0 Of= course these categories would not just be limited to the context of IPv6 a= doption, would have to be maintained as technologies come and go, and would= provide a more general measure for reliability and basic functionality.
ISPs that claim grade A according to RFC #### could advertise that, and cus= tomers could be assured by sticking with grade A ISPs, they can accomplish = anything they need to in terms of standard internet functionality.=C2=A0 A = simple Wiki could be maintained by communities regarding what the grades or= for various ISPs.

In any case, my point is, while individuals may have complained to somebody= working at AT&T, at various times, no real pressure has been put on AT= &T or any other ISP, even to adopt IPv6 or to allow for customers to do= so.=C2=A0 No incentives have been provided either.=C2=A0 We've thus fa= r relied only on the notion that they will work toward the goal as they see= an impact from lack of IPv4 addresses.=C2=A0 The idea that I would, as a c= ustomer ask, "where is my native IPv6", was less about applying p= ressure, and more about starting the conversation about what they could pro= vide me as a customer.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a11c3b40c2999b30506e16f95-- From nobody Sun Nov 2 07:17:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3742F1A8A72 for ; Sun, 2 Nov 2014 07:17:42 -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 yOmJC79fynAt for ; Sun, 2 Nov 2014 07:17:40 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B16B1A8892 for ; Sun, 2 Nov 2014 07:17:39 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:ad0e:ba8d:740e:bf71] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sA2FHCrl072830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2014 16:17:12 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <54562E86.7000208@massar.ch> Date: Sun, 2 Nov 2014 16:17:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KzPBCw7lvtS4g75-7Wm7vX5Evic Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 15:17:42 -0000 On 02 Nov 2014, at 14:15, Jeroen Massar wrote: > I don't think that "replacing" 6to4 is going to bring anything useful = at > this point in time. This "transition" game has been running for close = to > 20 years already... I agree somewhat. But the real question is how much longer it's going to = take rather than how long it's been under way already... Native IPv6 = deployment is picking up speed, but on the other hand even under the = most optimistic assumptions it's going to take at least another half a = decade to reach ubiquity. > And during that time several tools have come into existence and have > gained wide deployment that solve these issues. Compared to 6to4 and Teredo? I don't think so. And those two have = significant issues that make them as good as unworkable. > - heartbeat > - RFC 5572 - TSP / Tunnel Setup Protocol > - AYIYA > - TIC You missed a few. :-) See RFC 7059. (-: You and Owen make a good point that existing tunnel brokers already do = good work, and of course adding one new protocol to rule them all hasn't = historically been very successful. But... wouldn't it be great if we could have a tunnel mechanism that = couples the reliability of a tunnel broker tunnel with the ease of use = (i.e., it's enabled by default without the user having to do anything) = of 6to4/Teredo? I think it could be done with a simple front end that allows a home = gateway (or a host, of course) to obtain configuration info so it can = connect to an appropriate tunnel endpoint. The actual encapsulation is easy enough to negotiate: let the client = indicate whether it can handle plain proto 41, 6rd, IPv6 in UDP, AYIYA, = AERO, whatever. (Of course one would have to be the "lingua franca".) = The server can then see if the user is signed up to any services that = provide compatible tunnels, if the client's IP address map to a service = provider tunnel gateway or if there is a public gateway that serves = those addresses and then provides the provisioning details. This would probably require some back end changes in places like = tunnelbroker.net and sixxs.net, but it would otherwise let users = continue to use those services but with the benefit that if home gateway = makers implement the new setup protocol, the tunnels can be terminated = using those home gateways, which makes for a much better user experience = than doing it on a computer. And because everything is=20 Iljitsch= From nobody Sun Nov 2 07:28:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712DD1A88A5 for ; Sun, 2 Nov 2014 07:28:28 -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 bVW3Ozb85Y1T for ; Sun, 2 Nov 2014 07:28:26 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10911A88A4 for ; Sun, 2 Nov 2014 07:28:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA2FSQ00024658; Sun, 2 Nov 2014 07:28:26 -0800 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA2FSGjL024185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Nov 2014 07:28:17 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.52]) with mapi id 14.03.0210.002; Sun, 2 Nov 2014 07:28:16 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum , Jeroen Massar Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9rGf608NTgduBkuEflA3chqO+w== Date: Sun, 2 Nov 2014 15:28:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> In-Reply-To: <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.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: http://mailarchive.ietf.org/arch/msg/v6ops/pj53k6RvgoAE71PjMjU4bO46zmI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 15:28:28 -0000 > This would probably require some back end changes in places like tunnelbr= oker.net and sixxs.net, but it would otherwise let users > continue to use those services but with the benefit that if home gateway = makers implement the new setup protocol, the tunnels can > be terminated using those home gateways, which makes for a much better us= er experience than doing it on a computer. And because > everything is I say turn the tunnel brokers into DHCPv6 servers and the home gateways int= o DHCPv6 clients. Let them use DHCPv6 PD and DHCPv6 security to make sure that only authorize= d clients get IPv6 prefix delegations. Then, layer an NBMA interface model on top of ever= ything and use IPv6 ND to coordinate route optimization and mobility management. It just m= ight get us to a fully IPv6 and fully mobile Internet... Thanks - Fred fred.l.templin@boeing.com From nobody Sun Nov 2 07:38:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA61A88C2 for ; Sun, 2 Nov 2014 07:37:58 -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 b0lW7lA_-SNz for ; Sun, 2 Nov 2014 07:37:56 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D42C1A88B6 for ; Sun, 2 Nov 2014 07:37:56 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:ad0e:ba8d:740e:bf71] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sA2FbWl5073102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2014 16:37:32 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> Date: Sun, 2 Nov 2014 16:37:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TIcHIndUwIcnY38z5uXJPCDDqIE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 15:37:58 -0000 On 02 Nov 2014, at 16:28, Templin, Fred L = wrote: > I say turn the tunnel brokers into DHCPv6 servers and the home = gateways into DHCPv6 clients. That doesn't work, because you need the remote tunnel endpoint = configuration info before you can talk to the tunnel broker over IPv6 so = you can send your DHCPv6 request in order to get your configuration = info... Apart from that, I'm not a huge fan of putting everything in DHCP(v6) = because DHCP is hard to get at from the outside. Life is so much easier = if you can simply use HTTP.= From nobody Sun Nov 2 07:50:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0E1A88E1 for ; Sun, 2 Nov 2014 07:50: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 g6EwtgfLIqrl for ; Sun, 2 Nov 2014 07:50:25 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DBF1A88DE for ; Sun, 2 Nov 2014 07:50:25 -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 sA2FoONr022101; Sun, 2 Nov 2014 09:50:24 -0600 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA2FoGW7021457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Nov 2014 09:50:17 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.170]) with mapi id 14.03.0210.002; Sun, 2 Nov 2014 07:50:15 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9rGf608NTgduBkuEflA3chqO+5xN/pmA//98F3A= Date: Sun, 2 Nov 2014 15:50:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@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: http://mailarchive.ietf.org/arch/msg/v6ops/VC6rHcNNsz25uHss_-tRni-2TDE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 15:50:27 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, November 02, 2014 7:38 AM > To: Templin, Fred L > Cc: Jeroen Massar; Owen DeLong; v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendatio= n re: 6to4 >=20 > On 02 Nov 2014, at 16:28, Templin, Fred L wro= te: >=20 > > I say turn the tunnel brokers into DHCPv6 servers and the home gateways= into DHCPv6 clients. >=20 > That doesn't work, because you need the remote tunnel endpoint configurat= ion info before you can talk to the tunnel broker over > IPv6 so you can send your DHCPv6 request in order to get your configurati= on info... The tunnel broker address is automatically derived from the DNS. However, t= he client does need to be enrolled in the service offered by the tunnel broker in order to= get an IPv6 prefix delegation. Is that any different than what current tunnel broker se= rvices require? > Apart from that, I'm not a huge fan of putting everything in DHCP(v6) bec= ause DHCP is hard to get at from the outside. I'm struggling to understand what that means: "hard to get at from the outs= ide"? Thanks - Fred fred.l.templin@boeing.com > Life is so much easier if you can simply use HTTP. From nobody Sun Nov 2 08:35:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612DE1A9093 for ; Sun, 2 Nov 2014 08:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UyWVLAmLs7J for ; Sun, 2 Nov 2014 08:35:44 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019851A907F for ; Sun, 2 Nov 2014 08:35:41 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Sun, 2 Nov 2014 10:35:39 -0600 From: "Metzler, Dan J" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEIAAb7GA///B4hCAAoRIgIAAUB2AgACIU4D//7SI4A== Date: Sun, 2 Nov 2014 16:35:38 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: multipart/alternative; boundary="_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886BITSNT440iowauio_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rl17Hn3dp11RprAwYSOE6HGGT9Y Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 16:35:46 -0000 --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886BITSNT440iowauio_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8uICAoVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4pICBBbmQgSSBkaWRu4oCZdCBuZWNl c3NhcmlseSBtZWFuIHRvIHNpbmdsZSBvdXQgQVQmVCBiZXlvbmQgcmVzcG9uZGluZyB0byB0aGUg ZWFybGllciBjb21tZW50IHRoYXQgZGlkLiAgKEFzIEkgc2FpZCBJIGhhdmUgbm8gYnVzaW5lc3Mg cmVsYXRpb25zaGlwIHdpdGggQVQmVCwgbm9yIGFueSBwYXN0IGV4cGVyaWVuY2Ugd2l0aCB0aGVt LikNCg0KVGhhdCBzYWlkLCBiYWNrIHRvIHRoZSBvcmlnaW5hbCBkaXNjdXNzaW9uLCBpbnZvbHZp bmcgcHJvdG9jb2wgNDEsIGlmIEFUJlQgaXMgdHJ1bHkgYmxvY2tpbmcgcHJvdG9jb2wgNDEgYmVj YXVzZSB0aGV5IHByb3ZpZGUgSVB2NiBuYXRpdmUgc3VwcG9ydCBhY3Jvc3MgdGhlIGJvYXJkIGFs cmVhZHksIHRoYXQgc2VlbXMgYSBsb3QgbGVzcyB1bnJlYXNvbmFibGUuICBBbmQsIGlmIEkgYXMg YSBjdXN0b21lciB0aGVuIGdvIGFzayBmb3IgbXkgbmF0aXZlIElQdjYgY29ubmVjdGlvbnMsIHRo ZW4gdGhlIGFuc3dlciB3aWxsIGJlLCDigJxjZXJ0YWlubHksIGhlcmUgeW91IGdvLuKAnQ0KDQpU aGFua3MsDQoNCg0KLSAgICAgICAgRGFuDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMiwgMjAxNCA4OjU2 IEFNDQpUbzogTWV0emxlciwgRGFuIEoNCkNjOiBLZWl0aCBNb29yZTsgT3dlbiBEZUxvbmc7IHY2 b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDYudHh0IC0gYWx0ZXJuYXRpdmVzIHRvIDZ0bzQN Cg0KDQpZb3UgYXJlIGF3YXJlIHRoYXQgZnVsbHkgMjUlIG9mIEFUJlQncyB1c2VycyBkbyBoYXZl IElQdjYsIHJpZ2h0Pw0KT24gMiBOb3YgMjAxNCAxMDozNyBwbSwgIk1ldHpsZXIsIERhbiBKIiA8 ZGFuLW1ldHpsZXJAdWlvd2EuZWR1PG1haWx0bzpkYW4tbWV0emxlckB1aW93YS5lZHU+PiB3cm90 ZToNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE93ZW4gRGVMb25n IFttYWlsdG86b3dlbkBkZWxvbmcuY29tPG1haWx0bzpvd2VuQGRlbG9uZy5jb20+XQ0KPiBTZW50 OiBTYXR1cmRheSwgTm92ZW1iZXIgMSwgMjAxNCA5OjAyIFBNDQo+IFRvOiBNZXR6bGVyLCBEYW4g Sg0KPiBDYzogS2VpdGggTW9vcmU7IEFsZXhhbmRydSBQZXRyZXNjdTsgQnJpYW4gRSBDYXJwZW50 ZXI7IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4gV0cNCj4gU3ViamVjdDog UmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3Rvcmlj LTA2LnR4dCAtDQo+IGFsdGVybmF0aXZlcyB0byA2dG80DQo+DQo+ID4NCj4gPiBJIGRvbid0IGhh dmUgYW55IGtpbmQgb2YgYnVzaW5lc3MgcmVsYXRpb25zaGlwIHdpdGggQVQmVCwgYnV0IGlmIEkg d2VyZSBhDQo+IGN1c3RvbWVyLCBJJ2QgYmUgYXNraW5nIHRoZW0gZm9yIG15IG5hdGl2ZSBJUHY2 IGFjY2VzcyBhdCB0aGF0IHBvaW50LiAgSSBkb24ndA0KPiBwcmV0ZW5kIHRvIHN1Z2dlc3QgdGhh dCB0aGVyZSBhcmVuJ3QgcGVvcGxlIGJsb2NraW5nIHByb3RvY29sIDQxIGZvciBubw0KPiByZWFz b24gb3RoZXIgdGhhbiBmZWFyLCBhbmQgSSBnZW5lcmFsbHkgZG9uJ3QgdGhpbmsgaXQncyBnb29k IGZvciBhIHByb3ZpZGVyIHRvDQo+IGJsb2NrIHByb3RvY29sIDQxIHVudGlsIHRoZXkndmUgcHJv dmlkZWQgc29tZSBhbHRlcm5hdGl2ZS4NCj4NCj4gTWFueSBoYXZlIHRyaWVkLiBVbmZvcnR1bmF0 ZWx5LCBhdHRlbXB0cyB0byBwdXQgcHJlc3N1cmUgb24gQVQmVCBieQ0KPiBjb25zdW1lcnMgYXJl IHJvdWdobHkgZXF1aXZhbGFudCB0byBhdHRlbXB0aW5nIHRvIHVzZSBvbmUncyB0aHVtYiB0bw0K PiBjb21wcmVzcyBhIG1hcnNobWFsbG93IGludG8gc3VibWlzc2lvbi4gWW91ciB0aHVtYiBnZXRz IG1lc3N5LCBidXQgdGhlDQo+IG1hcnNobWFsbG93IGRvZXNuJ3QgY2FyZS4NCj4NCj4gSW4gdGhp cyByZWdhcmQsIHRoaW5rIG9mIEFUJlQgYXMgYSBnaWFudCBkZWF0aC1zdGFyIHNoYXBlZCBtYXJz aG1hbGxvdyBvbmx5DQo+IG1vcmUgYml0dGVyIHRoYW4gc3dlZXQuDQo+DQoNCldoaWxlIEkgdW5k ZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgbGFyZ2UgZGVncmVlIG9mIHRydXRoIHRvIHRoaXMsIEkg ZGlzYWdyZWUgd2l0aCByZWdhcmQgdG8gdGhlIG5vdGlvbiB0aGF0IGFueSByZWFsIGF0dGVtcHRz IGhhdmUgYmVlbiBtYWRlIHRvIHB1dCBwcmVzc3VyZSBvbiBBVCZUIG9yIHNpbWlsYXIgSVNQcy4g IFRvIHB1dCBpdCBpbiBhIGxlc3MgY29uZnJvbnRhdGlvbmFsIHdheSwgSSBkb24ndCB0aGluayB0 aGVyZSBoYXZlIGJlZW4gYXR0ZW1wdHMgdG8gcHJvdmlkZSBJU1BzIHdpdGggdGhlIG5lY2Vzc2Fy eSBndWlkYW5jZSBvciB0b29scyB0byBrbm93IHdoYXQgdGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMu ICBGb3IgZXhhbXBsZSBob3cgYWJvdXQgYW4gUkZDIHRoYXQgZGVmaW5lcyBzdGFuZGFyZHMgb2Yg YWNjZXB0YWJsZSBJU1AgYmVoYXZpb3IgYW5kIHByb3ZpZGVzIGEgZ3JhZGluZyBzeXN0ZW0uICBU aGlzIGlzIHNvbWV0aGluZyB0aGF0IGN1c3RvbWVycyBjYW4gdXNlIHdoZW4gc2hvcHBpbmcgZm9y IElTUHMuICBXZSBjb3VsZCBnaXZlIGNsYXNzaWZpY2F0aW9ucyBiYXNlZCBvbiBjZXJ0YWluIHN0 YW5kYXJkcy4NCkZvciBleGFtcGxlIGZyb20gYW4gSVB2NiBwZXJzcGVjdGl2ZToNCiJBIiAtIElT UCBpbXBsZW1lbnRzIE5hdGl2ZSBJUHY2IGFuZC9vciA2cmQNCiJEIiAtIElTUCBpbXBsZW1lbnRz IG5vIE5hdGl2ZSBJUHY2LCBhbmQgcHJvdmlkZXMgbm8gNnJkLCBidXQgSVNQIGRvZXMgbm90IGJs b2NrIGFueSB0cmFmZmljIGluY2x1ZGluZyB0aGF0IHdoaWNoIG1pZ2h0IGFsbG93IGEgY3VzdG9t ZXIgdG8gaW1wbGVtZW50IElQdjYuDQoiRiIgLSBJU1AgYmxvY2tzIHRyYWZmaWMgYWNjb3JkaW5n IHRvIGl0cyBvd24gcG9saWNpZXMgd2l0aG91dCBjdXN0b21lciBlbmRvcnNlbWVudC4gKE5vdCB0 aGUgZnVuY3Rpb24gb2YgYW4gSVNQLikNCg0KU29tZXRoaW5nIGxpa2UgdGhpcyB3b3VsZCBhbGxv dyBmb3IgYSBtZWFuaW5nZnVsIGNvbnZlcnNhdGlvbiB3aXRoIElTUHMgbGlrZSBBVCZULCBhbmQg cHJvdmlkZSBjb250ZXh0IGZvciByYXRpbmcgSVNQcyBpbiB0ZXJtcyBvZiBicm9rZW5uZXNzIG9m IHRoZWlyIGltcGxlbWVudGF0aW9ucywgYW5kIGEgYmFzaXMgZm9yIHB1Ymxpc2hpbmcgdGhhdCBp bmZvcm1hdGlvbi4gIE9mIGNvdXJzZSB0aGVzZSBjYXRlZ29yaWVzIHdvdWxkIG5vdCBqdXN0IGJl IGxpbWl0ZWQgdG8gdGhlIGNvbnRleHQgb2YgSVB2NiBhZG9wdGlvbiwgd291bGQgaGF2ZSB0byBi ZSBtYWludGFpbmVkIGFzIHRlY2hub2xvZ2llcyBjb21lIGFuZCBnbywgYW5kIHdvdWxkIHByb3Zp ZGUgYSBtb3JlIGdlbmVyYWwgbWVhc3VyZSBmb3IgcmVsaWFiaWxpdHkgYW5kIGJhc2ljIGZ1bmN0 aW9uYWxpdHkuDQoNCklTUHMgdGhhdCBjbGFpbSBncmFkZSBBIGFjY29yZGluZyB0byBSRkMgIyMj IyBjb3VsZCBhZHZlcnRpc2UgdGhhdCwgYW5kIGN1c3RvbWVycyBjb3VsZCBiZSBhc3N1cmVkIGJ5 IHN0aWNraW5nIHdpdGggZ3JhZGUgQSBJU1BzLCB0aGV5IGNhbiBhY2NvbXBsaXNoIGFueXRoaW5n IHRoZXkgbmVlZCB0byBpbiB0ZXJtcyBvZiBzdGFuZGFyZCBpbnRlcm5ldCBmdW5jdGlvbmFsaXR5 LiAgQSBzaW1wbGUgV2lraSBjb3VsZCBiZSBtYWludGFpbmVkIGJ5IGNvbW11bml0aWVzIHJlZ2Fy ZGluZyB3aGF0IHRoZSBncmFkZXMgb3IgZm9yIHZhcmlvdXMgSVNQcy4NCg0KSW4gYW55IGNhc2Us IG15IHBvaW50IGlzLCB3aGlsZSBpbmRpdmlkdWFscyBtYXkgaGF2ZSBjb21wbGFpbmVkIHRvIHNv bWVib2R5IHdvcmtpbmcgYXQgQVQmVCwgYXQgdmFyaW91cyB0aW1lcywgbm8gcmVhbCBwcmVzc3Vy ZSBoYXMgYmVlbiBwdXQgb24gQVQmVCBvciBhbnkgb3RoZXIgSVNQLCBldmVuIHRvIGFkb3B0IElQ djYgb3IgdG8gYWxsb3cgZm9yIGN1c3RvbWVycyB0byBkbyBzby4gIE5vIGluY2VudGl2ZXMgaGF2 ZSBiZWVuIHByb3ZpZGVkIGVpdGhlci4gIFdlJ3ZlIHRodXMgZmFyIHJlbGllZCBvbmx5IG9uIHRo ZSBub3Rpb24gdGhhdCB0aGV5IHdpbGwgd29yayB0b3dhcmQgdGhlIGdvYWwgYXMgdGhleSBzZWUg YW4gaW1wYWN0IGZyb20gbGFjayBvZiBJUHY0IGFkZHJlc3Nlcy4gIFRoZSBpZGVhIHRoYXQgSSB3 b3VsZCwgYXMgYSBjdXN0b21lciBhc2ssICJ3aGVyZSBpcyBteSBuYXRpdmUgSVB2NiIsIHdhcyBs ZXNzIGFib3V0IGFwcGx5aW5nIHByZXNzdXJlLCBhbmQgbW9yZSBhYm91dCBzdGFydGluZyB0aGUg Y29udmVyc2F0aW9uIGFib3V0IHdoYXQgdGhleSBjb3VsZCBwcm92aWRlIG1lIGFzIGEgY3VzdG9t ZXIuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2 Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886BITSNT440iowauio_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0ODM2MTYx MTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDIx MzE0OTAyIC0yOTQzNjI4NjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vLiZuYnNwOyAoVGhhbmtzIGZvciBwb2ludGluZyB0 aGF0IG91dC4pJm5ic3A7IEFuZCBJIGRpZG7igJl0IG5lY2Vzc2FyaWx5IG1lYW4gdG8gc2luZ2xl IG91dCBBVCZhbXA7VCBiZXlvbmQgcmVzcG9uZGluZyB0byB0aGUgZWFybGllciBjb21tZW50IHRo YXQgZGlkLiZuYnNwOyAoQXMgSSBzYWlkIEkgaGF2ZSBubw0KIGJ1c2luZXNzIHJlbGF0aW9uc2hp cCB3aXRoIEFUJmFtcDtULCBub3IgYW55IHBhc3QgZXhwZXJpZW5jZSB3aXRoIHRoZW0uKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdCBzYWlkLCBiYWNrIHRv IHRoZSBvcmlnaW5hbCBkaXNjdXNzaW9uLCBpbnZvbHZpbmcgcHJvdG9jb2wgNDEsIGlmIEFUJmFt cDtUIGlzIHRydWx5IGJsb2NraW5nIHByb3RvY29sIDQxIGJlY2F1c2UgdGhleSBwcm92aWRlIElQ djYgbmF0aXZlIHN1cHBvcnQgYWNyb3NzIHRoZSBib2FyZA0KIGFscmVhZHksIHRoYXQgc2VlbXMg YSBsb3QgbGVzcyB1bnJlYXNvbmFibGUuJm5ic3A7IEFuZCwgaWYgSSBhcyBhIGN1c3RvbWVyIHRo ZW4gZ28gYXNrIGZvciBteSBuYXRpdmUgSVB2NiBjb25uZWN0aW9ucywgdGhlbiB0aGUgYW5zd2Vy IHdpbGwgYmUsIOKAnGNlcnRhaW5seSwgaGVyZSB5b3UgZ28u4oCdJm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+RGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g TG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFN1bmRheSwgTm92ZW1iZXIgMiwgMjAxNCA4OjU2IEFNPGJyPg0KPGI+VG86PC9iPiBN ZXR6bGVyLCBEYW4gSjxicj4NCjxiPkNjOjwvYj4gS2VpdGggTW9vcmU7IE93ZW4gRGVMb25nOyB2 Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDYudHh0IC0gYWx0ZXJuYXRp dmVzIHRvIDZ0bzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5Zb3UgYXJlIGF3YXJlIHRo YXQgZnVsbHkgMjUlIG9mIEFUJmFtcDtUJ3MgdXNlcnMgZG8gaGF2ZSBJUHY2LCByaWdodD88bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyIE5vdiAyMDE0IDEw OjM3IHBtLCAmcXVvdDtNZXR6bGVyLCBEYW4gSiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRh bi1tZXR6bGVyQHVpb3dhLmVkdSI+ZGFuLW1ldHpsZXJAdWlvd2EuZWR1PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogT3dl biBEZUxvbmcgW21haWx0bzo8YSBocmVmPSJtYWlsdG86b3dlbkBkZWxvbmcuY29tIj5vd2VuQGRl bG9uZy5jb208L2E+XTxicj4NCiZndDsgU2VudDogU2F0dXJkYXksIE5vdmVtYmVyIDEsIDIwMTQg OTowMiBQTTxicj4NCiZndDsgVG86IE1ldHpsZXIsIERhbiBKPGJyPg0KJmd0OyBDYzogS2VpdGgg TW9vcmU7IEFsZXhhbmRydSBQZXRyZXNjdTsgQnJpYW4gRSBDYXJwZW50ZXI7IDxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyI+DQp2Nm9wc0BpZXRmLm9yZzwvYT4gV0c8YnI+DQomZ3Q7IFN1 YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNnRvNC10by1o aXN0b3JpYy0wNi50eHQgLTxicj4NCiZndDsgYWx0ZXJuYXRpdmVzIHRvIDZ0bzQ8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgZG9uJ3QgaGF2ZSBhbnkga2luZCBvZiBi dXNpbmVzcyByZWxhdGlvbnNoaXAgd2l0aCBBVCZhbXA7VCwgYnV0IGlmIEkgd2VyZSBhPGJyPg0K Jmd0OyBjdXN0b21lciwgSSdkIGJlIGFza2luZyB0aGVtIGZvciBteSBuYXRpdmUgSVB2NiBhY2Nl c3MgYXQgdGhhdCBwb2ludC4mbmJzcDsgSSBkb24ndDxicj4NCiZndDsgcHJldGVuZCB0byBzdWdn ZXN0IHRoYXQgdGhlcmUgYXJlbid0IHBlb3BsZSBibG9ja2luZyBwcm90b2NvbCA0MSBmb3Igbm88 YnI+DQomZ3Q7IHJlYXNvbiBvdGhlciB0aGFuIGZlYXIsIGFuZCBJIGdlbmVyYWxseSBkb24ndCB0 aGluayBpdCdzIGdvb2QgZm9yIGEgcHJvdmlkZXIgdG88YnI+DQomZ3Q7IGJsb2NrIHByb3RvY29s IDQxIHVudGlsIHRoZXkndmUgcHJvdmlkZWQgc29tZSBhbHRlcm5hdGl2ZS48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBNYW55IGhhdmUgdHJpZWQuIFVuZm9ydHVuYXRlbHksIGF0dGVtcHRzIHRvIHB1dCBw cmVzc3VyZSBvbiBBVCZhbXA7VCBieTxicj4NCiZndDsgY29uc3VtZXJzIGFyZSByb3VnaGx5IGVx dWl2YWxhbnQgdG8gYXR0ZW1wdGluZyB0byB1c2Ugb25lJ3MgdGh1bWIgdG88YnI+DQomZ3Q7IGNv bXByZXNzIGEgbWFyc2htYWxsb3cgaW50byBzdWJtaXNzaW9uLiBZb3VyIHRodW1iIGdldHMgbWVz c3ksIGJ1dCB0aGU8YnI+DQomZ3Q7IG1hcnNobWFsbG93IGRvZXNuJ3QgY2FyZS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJbiB0aGlzIHJlZ2FyZCwgdGhpbmsgb2YgQVQmYW1wO1QgYXMgYSBnaWFudCBk ZWF0aC1zdGFyIHNoYXBlZCBtYXJzaG1hbGxvdyBvbmx5PGJyPg0KJmd0OyBtb3JlIGJpdHRlciB0 aGFuIHN3ZWV0Ljxicj4NCiZndDs8YnI+DQo8YnI+DQpXaGlsZSBJIHVuZGVyc3RhbmQgdGhhdCB0 aGVyZSBpcyBhIGxhcmdlIGRlZ3JlZSBvZiB0cnV0aCB0byB0aGlzLCBJIGRpc2FncmVlIHdpdGgg cmVnYXJkIHRvIHRoZSBub3Rpb24gdGhhdCBhbnkgcmVhbCBhdHRlbXB0cyBoYXZlIGJlZW4gbWFk ZSB0byBwdXQgcHJlc3N1cmUgb24gQVQmYW1wO1Qgb3Igc2ltaWxhciBJU1BzLiZuYnNwOyBUbyBw dXQgaXQgaW4gYSBsZXNzIGNvbmZyb250YXRpb25hbCB3YXksIEkgZG9uJ3QgdGhpbmsgdGhlcmUg aGF2ZSBiZWVuIGF0dGVtcHRzDQogdG8gcHJvdmlkZSBJU1BzIHdpdGggdGhlIG5lY2Vzc2FyeSBn dWlkYW5jZSBvciB0b29scyB0byBrbm93IHdoYXQgdGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMuJm5i c3A7IEZvciBleGFtcGxlIGhvdyBhYm91dCBhbiBSRkMgdGhhdCBkZWZpbmVzIHN0YW5kYXJkcyBv ZiBhY2NlcHRhYmxlIElTUCBiZWhhdmlvciBhbmQgcHJvdmlkZXMgYSBncmFkaW5nIHN5c3RlbS4m bmJzcDsgVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBjdXN0b21lcnMgY2FuIHVzZSB3aGVuIHNob3Bw aW5nDQogZm9yIElTUHMuJm5ic3A7IFdlIGNvdWxkIGdpdmUgY2xhc3NpZmljYXRpb25zIGJhc2Vk IG9uIGNlcnRhaW4gc3RhbmRhcmRzLjxicj4NCkZvciBleGFtcGxlIGZyb20gYW4gSVB2NiBwZXJz cGVjdGl2ZTo8YnI+DQomcXVvdDtBJnF1b3Q7IC0gSVNQIGltcGxlbWVudHMgTmF0aXZlIElQdjYg YW5kL29yIDZyZDxicj4NCiZxdW90O0QmcXVvdDsgLSBJU1AgaW1wbGVtZW50cyBubyBOYXRpdmUg SVB2NiwgYW5kIHByb3ZpZGVzIG5vIDZyZCwgYnV0IElTUCBkb2VzIG5vdCBibG9jayBhbnkgdHJh ZmZpYyBpbmNsdWRpbmcgdGhhdCB3aGljaCBtaWdodCBhbGxvdyBhIGN1c3RvbWVyIHRvIGltcGxl bWVudCBJUHY2Ljxicj4NCiZxdW90O0YmcXVvdDsgLSBJU1AgYmxvY2tzIHRyYWZmaWMgYWNjb3Jk aW5nIHRvIGl0cyBvd24gcG9saWNpZXMgd2l0aG91dCBjdXN0b21lciBlbmRvcnNlbWVudC4gKE5v dCB0aGUgZnVuY3Rpb24gb2YgYW4gSVNQLik8YnI+DQo8YnI+DQpTb21ldGhpbmcgbGlrZSB0aGlz IHdvdWxkIGFsbG93IGZvciBhIG1lYW5pbmdmdWwgY29udmVyc2F0aW9uIHdpdGggSVNQcyBsaWtl IEFUJmFtcDtULCBhbmQgcHJvdmlkZSBjb250ZXh0IGZvciByYXRpbmcgSVNQcyBpbiB0ZXJtcyBv ZiBicm9rZW5uZXNzIG9mIHRoZWlyIGltcGxlbWVudGF0aW9ucywgYW5kIGEgYmFzaXMgZm9yIHB1 Ymxpc2hpbmcgdGhhdCBpbmZvcm1hdGlvbi4mbmJzcDsgT2YgY291cnNlIHRoZXNlIGNhdGVnb3Jp ZXMgd291bGQgbm90IGp1c3QgYmUNCiBsaW1pdGVkIHRvIHRoZSBjb250ZXh0IG9mIElQdjYgYWRv cHRpb24sIHdvdWxkIGhhdmUgdG8gYmUgbWFpbnRhaW5lZCBhcyB0ZWNobm9sb2dpZXMgY29tZSBh bmQgZ28sIGFuZCB3b3VsZCBwcm92aWRlIGEgbW9yZSBnZW5lcmFsIG1lYXN1cmUgZm9yIHJlbGlh YmlsaXR5IGFuZCBiYXNpYyBmdW5jdGlvbmFsaXR5Ljxicj4NCjxicj4NCklTUHMgdGhhdCBjbGFp bSBncmFkZSBBIGFjY29yZGluZyB0byBSRkMgIyMjIyBjb3VsZCBhZHZlcnRpc2UgdGhhdCwgYW5k IGN1c3RvbWVycyBjb3VsZCBiZSBhc3N1cmVkIGJ5IHN0aWNraW5nIHdpdGggZ3JhZGUgQSBJU1Bz LCB0aGV5IGNhbiBhY2NvbXBsaXNoIGFueXRoaW5nIHRoZXkgbmVlZCB0byBpbiB0ZXJtcyBvZiBz dGFuZGFyZCBpbnRlcm5ldCBmdW5jdGlvbmFsaXR5LiZuYnNwOyBBIHNpbXBsZSBXaWtpIGNvdWxk IGJlIG1haW50YWluZWQgYnkgY29tbXVuaXRpZXMNCiByZWdhcmRpbmcgd2hhdCB0aGUgZ3JhZGVz IG9yIGZvciB2YXJpb3VzIElTUHMuPGJyPg0KPGJyPg0KSW4gYW55IGNhc2UsIG15IHBvaW50IGlz LCB3aGlsZSBpbmRpdmlkdWFscyBtYXkgaGF2ZSBjb21wbGFpbmVkIHRvIHNvbWVib2R5IHdvcmtp bmcgYXQgQVQmYW1wO1QsIGF0IHZhcmlvdXMgdGltZXMsIG5vIHJlYWwgcHJlc3N1cmUgaGFzIGJl ZW4gcHV0IG9uIEFUJmFtcDtUIG9yIGFueSBvdGhlciBJU1AsIGV2ZW4gdG8gYWRvcHQgSVB2NiBv ciB0byBhbGxvdyBmb3IgY3VzdG9tZXJzIHRvIGRvIHNvLiZuYnNwOyBObyBpbmNlbnRpdmVzIGhh dmUgYmVlbiBwcm92aWRlZCBlaXRoZXIuJm5ic3A7DQogV2UndmUgdGh1cyBmYXIgcmVsaWVkIG9u bHkgb24gdGhlIG5vdGlvbiB0aGF0IHRoZXkgd2lsbCB3b3JrIHRvd2FyZCB0aGUgZ29hbCBhcyB0 aGV5IHNlZSBhbiBpbXBhY3QgZnJvbSBsYWNrIG9mIElQdjQgYWRkcmVzc2VzLiZuYnNwOyBUaGUg aWRlYSB0aGF0IEkgd291bGQsIGFzIGEgY3VzdG9tZXIgYXNrLCAmcXVvdDt3aGVyZSBpcyBteSBu YXRpdmUgSVB2NiZxdW90Oywgd2FzIGxlc3MgYWJvdXQgYXBwbHlpbmcgcHJlc3N1cmUsIGFuZCBt b3JlIGFib3V0IHN0YXJ0aW5nDQogdGhlIGNvbnZlcnNhdGlvbiBhYm91dCB3aGF0IHRoZXkgY291 bGQgcHJvdmlkZSBtZSBhcyBhIGN1c3RvbWVyLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886BITSNT440iowauio_-- From nobody Sun Nov 2 08:59:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E51A897A for ; Sun, 2 Nov 2014 08:59:02 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=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 4cmNrGOY09EF for ; Sun, 2 Nov 2014 08:59:00 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E391A8956 for ; Sun, 2 Nov 2014 08:59:00 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 9113E100A111B; Sun, 2 Nov 2014 16:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414947536; bh=3B6O3HgUsyK434IDnjc0gU2yTHcxZjLvnorvdYD2TyM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pjhm9GmPhV8Ou0pDNC/IG4OC6MQQQ6vC/nKecuj6+9fQRvrpVFld2fyK0VJ1hskKb KXwl41Ty4XZW86fC3Zo9FGhHci5mllFfmwLRl0bdrwSjdy0kLDFZ98F0tNhNGFn6oP XJ/dSIMQoHlFVmcJJ/8JJy7TPWcMBT2zl9Vf2qjR3+4fIlclM38s1jcQRCxuOSa6fx I/xdjzdiZEDOcCwxiK4FUQTJ93toWbj+mS44tZqGodvzNAREhG3WyVVZKGXFHDFPB/ hNrT8ozqztXiLXb7w7oK+kSBMb1OIG3tiePpQmlzn4o7mhPU7dYl115Rg5s8QPV6+K k9ao1foDjs9WA== Message-ID: <545662CD.7040305@massar.ch> Date: Sun, 02 Nov 2014 17:58:53 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> In-Reply-To: <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cwVk-qORH8UlUlN91B9aw5Mnt34 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 16:59:03 -0000 On 2014-11-02 16:17, Iljitsch van Beijnum wrote: > On 02 Nov 2014, at 14:15, Jeroen Massar wrote: > >> I don't think that "replacing" 6to4 is going to bring anything >> useful at this point in time. This "transition" game has been >> running for close to 20 years already... > > I agree somewhat. But the real question is how much longer it's going > to take rather than how long it's been under way already... Native > IPv6 deployment is picking up speed, but on the other hand even under > the most optimistic assumptions it's going to take at least another > half a decade to reach ubiquity. ISPs who are not moving will not move, the will wait till their customers move to another. Users who want IPv6 have already for a decade been choosing to use Tunnel Brokers. Users who do not care, well, they do not care. >> And during that time several tools have come into existence and >> have gained wide deployment that solve these issues. > > Compared to 6to4 and Teredo? I don't think so. You don't think what part? > And those two have > significant issues that make them as good as unworkable. You mean that 6to4 + Teredo have issues I guess? >> - heartbeat - RFC 5572 - TSP / Tunnel Setup Protocol - AYIYA - TIC > > You missed a few. :-) See RFC 7059. (-: I don't miss anything significant as most of those are not used anywhere. 6in4 = See [1], 10k at SixXS, probably another 10k at HE (they do not report active tunnels, just 'count', thus unknown what that means active or 'configured and not used'?), what every TB does, hence definitely used a lot. "Automatic Tunneling" nothing uses that. 6over = nothing does that GRE = happens sometimes (and actually, because some platforms do GRE but not 6in4 there is this sixxsd beta with GRE tunnels, not much different protocol from 6in4 anyway :) 6to4 = the one that has to go away AYIYA = 25k tunnels, see [1], used a *lot* ISATAP = maybe some "enterprise", but outside of that very little Teredo = the other anycast thing (Xbox One primarily + BitTorrent) 6rd = lots of ISP-pushed deployment; 6in4 based 6a44 = never even seen code or deployment LISP = just some people playing test setup, no real deployment SEAL = never seen code or deployment 6bed4 = never seen code or deployment TSP = About 10k tunnels: http://go6.net:3653/graph_image.php?action=view&local_graph_id=547&rra_id=1 [1] = https://www.sixxs.net/misc/usage/ as a general sample of how these are used. > You and Owen make a good point that existing tunnel brokers already > do good work, and of course adding one new protocol to rule them all > hasn't historically been very successful. As per [1] above, 6in4 is only 25% of the SixXS user base, >50% is AYIYA simply because of the NAT piercing. If you can do 6in4 directly you are lucky to have a public IP or are able to force that IP to become exposed with "DMZ mode" or similar. > But... wouldn't it be great if we could have a tunnel mechanism that > couples the reliability of a tunnel broker tunnel with the ease of > use (i.e., it's enabled by default without the user having to do > anything) of 6to4/Teredo? You can't. One of the very much overseen problems with running a Tunnel Broker is abuse handling. SixXS 'solved' this by asking for personal details and verifying these and pouncing hard on abuse, thus leaving the others Tunnel Brokers to handle the people who like mischief. > I think it could be done with a simple front end that allows a home > gateway (or a host, of course) to obtain configuration info so it can > connect to an appropriate tunnel endpoint. As noted quite a few products out there have TIC or TSP implemented already, eg: https://www.sixxs.net/wiki/Fritz!Box_general or directly the important picture: https://www.sixxs.net/wiki/File:FritzboxHowto.jpg Oh, and yes, if Hurricane Electric wanted to use that protocol they could have taken that feature a long time ago too and have it. Nothing tricky about it, solves exactly what it needs to solve. > The actual encapsulation is easy enough to negotiate: let the client > indicate whether it can handle plain proto 41, 6rd, IPv6 in UDP, > AYIYA, AERO, whatever. The client does not know that. Also note that more and more people become mobile and switch connection / SSID mid-session. Just using AYIYA solves all of that. The sixxsd mentioned above that does GRE, and thus beta, does allow automatic switching between GRE/proto-41/AYIYA though using the signed heartbeat to verify that the source is really that source. > (Of course one would have to be the "lingua > franca".) The server can then see if the user is signed up to any > services that provide compatible tunnels, if the client's IP address > map to a service provider tunnel gateway or if there is a public > gateway that serves those addresses and then provides the > provisioning details. TIC handles all of that already. > This would probably require some back end changes in places like > tunnelbroker.net and sixxs.net, but it would otherwise let users > continue to use those services but with the benefit that if home > gateway makers implement the new setup protocol, the tunnels can be > terminated using those home gateways, which makes for a much better > user experience than doing it on a computer. And because everything > is TIC is already implemented in these machines. Go shop around for AVM Fritz!Box, Draytek, ZyXEL, Motorola and various more, lots of them have added 'aiccu' to their setup as they are just Linux boxes anyway and as AICCU is BSD-licensed, they can do so without any problems. Some support just proto-41/heartbeat, others also have AYIYA support. And there are also boxes that support TSP, next to Hexago/Go6/Gogo6 having their GoGoCPE: http://www.gogo6.com/gogoware/gogocpe that is a mini-CPE that does the work for you for a small amount of $$$. Greets, Jeroen From nobody Sun Nov 2 09:01:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F731A88FF for ; Sun, 2 Nov 2014 09:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 41NR3o3oUp7T for ; Sun, 2 Nov 2014 09:01:52 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FAD1A90AE for ; Sun, 2 Nov 2014 09:01:52 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 05F01100A111B; Sun, 2 Nov 2014 17:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414947709; bh=Fv7qma5csaEXk3BWgiZ8NlOgk2KJCQRKjk52Ef9tZfY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=hlQndvjVnwpOoMLhZTcqAdikPDMWnb3nNLyKZTJMFTo/qbotMmEdlndUU4xpCVF92 a6DBD0YmpMRZUL5bPmA6GbKfEbyejcX/hGBq+vjg6WVNRC7iPuq3hYAetbjsZVZrIF Qzu6XwN6p4sSkzOJvtumN0qYqkzz2MkS1k4t8ddZu4y9fH0DxLNiAssunU7M7i2zSN Tvr+w+63mplVrpND2St26udnm9oJ9gvI2MyruLUPNGfZ3xEmtIut5WWdbgbesIJI+R WhVjNCsKR6OSHWhd2aaesMGS32gyH0rKdpOQstL4gqckF7YKSF4/q5CMOpTdf4A0Bl Dv5wNom7hhp2A== Message-ID: <5456637B.5090302@massar.ch> Date: Sun, 02 Nov 2014 18:01:47 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" , Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nW8j8bKKyFIhEj1wE_S3HtQ8yko Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 17:01:53 -0000 On 2014-11-02 16:50, Templin, Fred L wrote: >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Sunday, November 02, 2014 7:38 AM >> To: Templin, Fred L >> Cc: Jeroen Massar; Owen DeLong; v6ops@ietf.org WG >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 >> >> On 02 Nov 2014, at 16:28, Templin, Fred L wrote: >> >>> I say turn the tunnel brokers into DHCPv6 servers and the home gateways into DHCPv6 clients. >> >> That doesn't work, because you need the remote tunnel endpoint configuration info before you can talk to the tunnel broker over >> IPv6 so you can send your DHCPv6 request in order to get your configuration info... > > The tunnel broker address is automatically derived from the DNS. Or you just get those details from a protocol like TIC or TSP and let the actual Tunnel Broker decide on these details. > However, the client does need to be enrolled in the service offered by the tunnel broker in order to get an IPv6 > prefix delegation. Is that any different than what current tunnel broker services require? No difference at all. But there is absolutely no reason to do DHCPv6. Both SixXS and HE do static prefix delegation. Per default there is a _routed_ /64, and otherwise you request a large one. As the user gets a _static_ prefix, if somebody wants to bother with DHCPv6, let them do that on their end. Greets, Jeroen From nobody Sun Nov 2 09:26:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31D51A8985 for ; Sun, 2 Nov 2014 09:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 6e_QBzR-YP7i for ; Sun, 2 Nov 2014 09:26:19 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A241A8983 for ; Sun, 2 Nov 2014 09:26:19 -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 sA2HQI0u019026; Sun, 2 Nov 2014 09:26:18 -0800 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA2HQCur019002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Nov 2014 09:26:12 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.226]) with mapi id 14.03.0210.002; Sun, 2 Nov 2014 09:26:12 -0800 From: "Templin, Fred L" To: Jeroen Massar , Iljitsch van Beijnum Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9rGf608NTgduBkuEflA3chqO+5xN/pmA//98F3CAAJtogP//fIhw Date: Sun, 2 Nov 2014 17:26:11 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> In-Reply-To: <5456637B.5090302@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/dzrEfhRb3y6rL1mxUhnV7EDMrKw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 17:26:20 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Sunday, November 02, 2014 9:02 AM > To: Templin, Fred L; Iljitsch van Beijnum > Cc: Owen DeLong; v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendatio= n re: 6to4 >=20 > On 2014-11-02 16:50, Templin, Fred L wrote: > >> -----Original Message----- > >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > >> Sent: Sunday, November 02, 2014 7:38 AM > >> To: Templin, Fred L > >> Cc: Jeroen Massar; Owen DeLong; v6ops@ietf.org WG > >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommenda= tion re: 6to4 > >> > >> On 02 Nov 2014, at 16:28, Templin, Fred L = wrote: > >> > >>> I say turn the tunnel brokers into DHCPv6 servers and the home gatewa= ys into DHCPv6 clients. > >> > >> That doesn't work, because you need the remote tunnel endpoint configu= ration info before you can talk to the tunnel broker over > >> IPv6 so you can send your DHCPv6 request in order to get your configur= ation info... > > > > The tunnel broker address is automatically derived from the DNS. >=20 > Or you just get those details from a protocol like TIC or TSP and let > the actual Tunnel Broker decide on these details. Well, looking up a FQDN to get A or AAAA records gives you some assurance t= hat the tunnel broker you are talking to has properly registered itself in the = DNS. > > However, the client does need to be enrolled in the service offered by = the tunnel broker in order to get an IPv6 > > prefix delegation. Is that any different than what current tunnel broke= r services require? >=20 > No difference at all. OK. > Both SixXS and HE do static prefix delegation. In a sense, it is essentially static prefix delegation with the AERO DHCPv6= service model as well since the service needs to maintain a table of Client ID-to-p= refix mappings. > But there is absolutely no reason to do DHCPv6. Mobility and multihoming. The Client can register itself with the Server us= ing whatever access network IP address(e) it happens to have at the moment. So, for exam= ple, if the Client gets a different access network IP address every time it boots up th= e Server learns the new address during the DHCPv6 Request/Reply exchange. Afterwards, if th= e Client gets a new access network IP address (e.g., when moving from 4G to WiFi) it= issues a DHCPv6 Rebind and the Server updates its address. Or, if the Client has mul= tiple active access network IP addresses, it can register them all with the Server using= DHCPv6 Rebind and again use Rebind if the addresses ever change.=20 > Per default there is a _routed_ /64, and otherwise you request a large on= e. Prefix lengths other than /64 should be supported, yes. And, they must be routable as well - no difference there. > As the user gets a _static_ prefix, if somebody wants to bother with > DHCPv6, let them do that on their end. A Client that receives a prefix via DHCPv6 PD from a Server can certainly t= urn around and act as a DHCPv6 server to sub-delegate portions of that prefix to its d= ownstream attached end user networks, yes. That is the same as for any DHCPv6 PD scen= ario. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Sun Nov 2 10:21:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625871ACD68 for ; Sun, 2 Nov 2014 10:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yws38HNqlHif for ; Sun, 2 Nov 2014 10:21:47 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FEA1ACD65 for ; Sun, 2 Nov 2014 10:21:46 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 9D577100A111B; Sun, 2 Nov 2014 18:21:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414952504; bh=nNoWFf4Fb3vOGV30swnCZnqTxRWIAqm+AgaMlm5xZp4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pMuS3c2QhOVYsleKBzCLxLbUim1qT1lCaaAuSpqWSUCsDt/78+2uxqJibTkksPzNA ivZfnWVJkN6LI/HJpfE13tCOxHfJiioLbNVqu2JgWd9ianDcxKUX2Hb8L+ow3MfzYP 4W/3I26hwuJGb5BtfBXrKzugesDiDJzAo+Tb7IoGNV83p4MtEkj4xucN8ClG7xoI1n EqawIuB9cIFVqfUzC8NMmQ5toaOl07T1NOkDdAPN0MItE/F6p3PCLJs98Mfnh0eVW0 WqwMDHnsY0nXoUB5KAIKKI2IxMA5NKX15rHM/0edxPlnVxbQLC/PpiawutfTeOOXfg wXU3ZiR1XxpcA== Message-ID: <54567634.3020403@massar.ch> Date: Sun, 02 Nov 2014 19:21:40 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" , Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YKGyR2p4G2lmENU2cUoCmB37fxU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 18:21:49 -0000 On 2014-11-02 18:26, Templin, Fred L wrote: [..] >>> The tunnel broker address is automatically derived from the DNS. >> >> Or you just get those details from a protocol like TIC or TSP and let >> the actual Tunnel Broker decide on these details. > > Well, looking up a FQDN to get A or AAAA records gives you some assurance that > the tunnel broker you are talking to has properly registered itself in the DNS. As the TIC server is identified with a DNS label, you do that. (And you do not want a AAAA record when you do not have IPv6 connectivity yet) >> Both SixXS and HE do static prefix delegation. > > In a sense, it is essentially static prefix delegation with the AERO DHCPv6 service > model as well since the service needs to maintain a table of Client ID-to-prefix > mappings. A tunnel broker really can't care less about DHCP, it is all static. Actually, except for the current IPv4 endpoint, an identity and a passphrase, there is very little state in a proper tunnel broker. >> But there is absolutely no reason to do DHCPv6. > > Mobility and multihoming. You do not need DHCPv6 for either of that. Note that heartbeat and AYIYA "solve" (for varying degrees of "solve") Mobility aka "my IPv4 endpoint changes" or better "my current IPv4 endpoint and optionally UDP port are X and Y). > The Client can register itself with the Server using whatever > access network IP address(e) it happens to have at the moment. So, for example, if the > Client gets a different access network IP address every time it boots up the Server learns > the new address during the DHCPv6 Request/Reply exchange. Why bother with DHCP? You only need to signal the current IPv4 endpoint: heartbeat or AYIYA (which does a per-packet heartbeat). > Afterwards, if the Client > gets a new access network IP address (e.g., when moving from 4G to WiFi) it issues a > DHCPv6 Rebind and the Server updates its address. Or, if the Client has multiple active > access network IP addresses, it can register them all with the Server using DHCPv6 > Rebind and again use Rebind if the addresses ever change. No need to do "Rebinds" or other stuff like that. Every heartbeat causes the endpoint to be updated. You are trying to make it all to Enterprisey and solving problems that are not there. People who have multiple IPv4 endpoints will use the protocols that are suited for that. 6in4/heartbeat/AYIYA/TSP are all *transition technologies* they do not solve multihoming and other such things. AYIYA could solve those, but I chose not to bother with it. Very few people have multiple upstreams, and if you do, you can chose your 'current' one by sourcing the packets from there. >> Per default there is a _routed_ /64, and otherwise you request a large one. > > Prefix lengths other than /64 should be supported, yes. And, they must be > routable as well - no difference there. Per default it is a /64 so that the enduser can announce that per radvd on their local LAN. If they want to request "a large one" which typically is a /48. As it is just a line in TIC, it does not matter what happens to it or how many bits it has. As it is static, they do not even have to look it up in TIC actually. Though Fritz!Box and Motorola do that as then the user does not have to type anything except user/pass/tunnel_id. >> As the user gets a _static_ prefix, if somebody wants to bother with >> DHCPv6, let them do that on their end. > > A Client that receives a prefix via DHCPv6 PD from a Server can certainly turn around > and act as a DHCPv6 server to sub-delegate portions of that prefix to its downstream > attached end user networks, yes. That is the same as for any DHCPv6 PD scenario. The user can chose themselves to bother with DHCP if they want that state stuff. For the tunnel and prefix delegation it is not needed. I actually have myself never bother with DHCPv6, I just do static radvd, simple and works. I do hear a lot of people have problems with it. If people want to play with it, they can, their network on that side of the tunnel. No need to get Tunnel Brokers to do so. For SixXS we did think of doing DHCPv6-PD but decided that it is too much overhead and state for something that is static anyway. Why have state when one does not need it? And I actually don't recall anybody asking about such a 'feature'; likely as there is no reason for Tunnel Brokers to do so anyway. Greets, Jeroen From nobody Sun Nov 2 11:34:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7A51A00E5 for ; Sun, 2 Nov 2014 11:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MftWdHhY5GTz for ; Sun, 2 Nov 2014 11:34:49 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29EB1A0045 for ; Sun, 2 Nov 2014 11:34:49 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so10770048pab.5 for ; Sun, 02 Nov 2014 11:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m9Wo7GWfskMfcZXBdi7g97uzQkVdXqNPEXmGrUFme6U=; b=E1EKi09u7NY8DC0s5nD6ozJ5PuLLoE+yBJfPSeL6GpYNOahsWdPLGXy2gNqCbfybnu lLosG8lA//ISWpTj/TO0bQp8SV4DyZOZwyPt//dil1EvzGDOWP7JuS3NssFpTAw9ZSi9 8mhMDxE1I0+VMjdRHXnLRlmSVdPtIr/AZkj78IQMFXlA+3R7m0CXCWKg+WVIXoVRHJle VZt7LpPeskBAnZHYciDVnjvNmnrBUiRH1nUuPnv3BkdHicMWeoJRh8fqEashDE+1gqRx F4NbgWvLKDAsH+trlI4jUPhF4VuXi6neyxbUi5SyQ2sxF+FrFoxoe6cUzq8ckLAYBLeA jZTw== X-Received: by 10.66.191.135 with SMTP id gy7mr38511181pac.95.1414956889468; Sun, 02 Nov 2014 11:34:49 -0800 (PST) Received: from [192.168.178.23] (107.199.69.111.dynamic.snap.net.nz. [111.69.199.107]) by mx.google.com with ESMTPSA id d17sm15235846pdj.32.2014.11.02.11.34.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 11:34:48 -0800 (PST) Message-ID: <54568756.5010401@gmail.com> Date: Mon, 03 Nov 2014 08:34:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> In-Reply-To: <54562E86.7000208@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vXeCXlNMMW59mFRggn5CDcTXq_c Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 19:34:51 -0000 On 03/11/2014 02:15, Jeroen Massar wrote: > On 2014-11-02 13:31, Iljitsch van Beijnum wrote: >> If we want to come up with a tunneling mechanism that can replace >> 6to4 as the simple, easy choice to get tunneled IPv6 when native >> isn't available, perhaps it would be helpful to get together and >> discuss some options in Honolulu. > > (Note that not everybody gets to take holiday trips to exotic > destinations for "work"; rather go there for vacation and enjoy the > scenery then sitting in a conference room over there...). > > I don't think that "replacing" 6to4 is going to bring anything useful at > this point in time. This "transition" game has been running for close to > 20 years already... > > And during that time several tools have come into existence and have > gained wide deployment that solve these issues. Yes. When I don't find native v6 I either lie back and enjoy NAT44 or I hook up to SixXs. It's actually hard to beat AYIYA except that the setup is for geeks rather than normal humans. (The lack of an RFC doesn't seem to matter, which rather puts the discussion of deprecation and Historic status for 6to4 in its proper perspective.) I think this topic is OBE. We should focus on the ISPs and content providers who didn't get the message. Brian > > Teredo is the generic thing, no signup required, used heavily by Xbox > One when no native is available. But like 6to4 it has the anycast > problem: unreliable, hard to debug what goes wrong. > > Tunnel Broker related (somebody needs to provide the service and keep > things working): > > - heartbeat > https://www.sixxs.net/tools/heartbeat/ > - sidechannel to proto-41 packets > - solves the problem that people have dynamic IPv4 addresses > - 10+ years old and heavily in use > - as it still uses proto-41, does not work behind NAT[*] > > - RFC 5572 - TSP / Tunnel Setup Protocol > http://tools.ietf.org/html/rfc5572 > - solves setup/configuration + NAT traversal (using UDP packets) > > - AYIYA > https://www.sixxs.net/tools/ayiya/ > https://en.wikipedia.org/wiki/Anything_In_Anything > (never went to RFC as "ipv6 WG does not do tunnels anymore" was the > argument back then, hence also why TSP is a 'experimental' non-wg > document) > - solves dynamic IP + NAT traversal (signed UDP packets) > > - TIC > https://www.sixxs.net/tools/tic/ > - solves configuring a tunnel, the very simple way (linebased, no XML) > > As for implementation. Both TSP and TIC/heartbeat/AYIYA can be found in > a variety of off-the-shelf hardware NAT boxes aka "consumer routers": > AVM Fritz!Box, Motorola, DrayTek etc. > > Or just download the software for your favourite platform: > - tspc (eg https://packages.debian.org/sid/tspc) > - aiccu (https://www.sixxs.net/tools/aiccu/ or > https://packages.debian.org/sid/aiccu) > of course available for a variety of platforms (heartbeat even for Cisco > IOS ;). > > And then, I am not even going to the route of OpenVPN/tinc and thousands > of other tunneling techniques that can carry IPv6 packets inside IPv4 > and can do VPNs. > > What part of '6to4 exactly needs a replacement while all these things > have been available for years already? > > Greets, > Jeroen > > [*] setting your NAT box to DMZ mode so that a specific host gets all > packets and that that host terminates the tunnel is an option. Not all > users get that though and not all boxes handle it properly... > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Sun Nov 2 11:40:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF651ACDBF for ; Sun, 2 Nov 2014 11:40:27 -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 KeanErPimOY9 for ; Sun, 2 Nov 2014 11:40:26 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F261ACDBE for ; Sun, 2 Nov 2014 11:40:26 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id fp1so10371798pdb.9 for ; Sun, 02 Nov 2014 11:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NRIR8WfWU0is9fIePl2srPKKEwTU8pLZmqf0T7OaeU4=; b=dtAF+tuEYds6ZxT8a2EWCo5azT7KcncFPG6fmIXat1CqJbfXTIYW/MvST1eyEsYEIg KrtwNWWv2ohfPEmlt7+icbnPggFvl5NwCg2CMQOpXCdM148P6wo5em3G4N1xelW9OSUK X1SaSrmT02f3QtNaVp8kdMarqPbDCQcM5NLpH36FqDMcKF7hpu9adHdZI/GTc+K7vNGQ 5UyCAUiRg9qyTi8HxfUAhJmoRCHeifzWZ36P0KcpXUbDrAEK77KLl3zEZxRRoVu/Cy2U Bt39pdGGqut//1wzhrjPRJkiGBwdrfQ35EwuSfFoBEolldSFXDrrKI3H5myafL8sjbne b+Cg== X-Received: by 10.68.68.132 with SMTP id w4mr38654779pbt.93.1414957225919; Sun, 02 Nov 2014 11:40:25 -0800 (PST) Received: from [192.168.178.23] (107.199.69.111.dynamic.snap.net.nz. [111.69.199.107]) by mx.google.com with ESMTPSA id gy10sm12347862pbd.67.2014.11.02.11.40.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 11:40:25 -0800 (PST) Message-ID: <545688A5.4090401@gmail.com> Date: Mon, 03 Nov 2014 08:40:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Metzler, Dan J" References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r9Al_THPtwV05RE94aErlPwGRrA Cc: Keith Moore , "v6ops@ietf.org WG" Subject: [v6ops] ISP ratings [I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 19:40:28 -0000 Dan, There was an attempt to define what Internet service means in a broader sense, some years ago: RFC 4084 (aka BCP 104). However, it isn't at all clear that the IETF is the right vehicle for such an effort, except for providing technical definitions. Brian On 03/11/2014 02:37, Metzler, Dan J wrote: > >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Saturday, November 1, 2014 9:02 PM >> To: Metzler, Dan J >> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; v6ops@ietf.org WG >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - >> alternatives to 6to4 >> >>> I don't have any kind of business relationship with AT&T, but if I were a >> customer, I'd be asking them for my native IPv6 access at that point. I don't >> pretend to suggest that there aren't people blocking protocol 41 for no >> reason other than fear, and I generally don't think it's good for a provider to >> block protocol 41 until they've provided some alternative. >> >> Many have tried. Unfortunately, attempts to put pressure on AT&T by >> consumers are roughly equivalant to attempting to use one's thumb to >> compress a marshmallow into submission. Your thumb gets messy, but the >> marshmallow doesn't care. >> >> In this regard, think of AT&T as a giant death-star shaped marshmallow only >> more bitter than sweet. >> > > While I understand that there is a large degree of truth to this, I disagree with regard to the notion that any real attempts have been made to put pressure on AT&T or similar ISPs. To put it in a less confrontational way, I don't think there have been attempts to provide ISPs with the necessary guidance or tools to know what the correct behavior is. For example how about an RFC that defines standards of acceptable ISP behavior and provides a grading system. This is something that customers can use when shopping for ISPs. We could give classifications based on certain standards. > For example from an IPv6 perspective: > "A" - ISP implements Native IPv6 and/or 6rd > "D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does not block any traffic including that which might allow a customer to implement IPv6. > "F" - ISP blocks traffic according to its own policies without customer endorsement. (Not the function of an ISP.) > > Something like this would allow for a meaningful conversation with ISPs like AT&T, and provide context for rating ISPs in terms of brokenness of their implementations, and a basis for publishing that information. Of course these categories would not just be limited to the context of IPv6 adoption, would have to be maintained as technologies come and go, and would provide a more general measure for reliability and basic functionality. > > ISPs that claim grade A according to RFC #### could advertise that, and customers could be assured by sticking with grade A ISPs, they can accomplish anything they need to in terms of standard internet functionality. A simple Wiki could be maintained by communities regarding what the grades or for various ISPs. > > In any case, my point is, while individuals may have complained to somebody working at AT&T, at various times, no real pressure has been put on AT&T or any other ISP, even to adopt IPv6 or to allow for customers to do so. No incentives have been provided either. We've thus far relied only on the notion that they will work toward the goal as they see an impact from lack of IPv4 addresses. The idea that I would, as a customer ask, "where is my native IPv6", was less about applying pressure, and more about starting the conversation about what they could provide me as a customer. > > . > From nobody Sun Nov 2 13:22:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13C1ACE0E for ; Sun, 2 Nov 2014 13:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 3mA5JpFT-eVt for ; Sun, 2 Nov 2014 13:22:03 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FBC1A1A15 for ; Sun, 2 Nov 2014 13:22:03 -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 sA2LM2Dl003710; Sun, 2 Nov 2014 15:22:02 -0600 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA2LM0gx003706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Nov 2014 15:22:01 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.18]) with mapi id 14.03.0210.002; Sun, 2 Nov 2014 13:22:00 -0800 From: "Templin, Fred L" To: Jeroen Massar , Iljitsch van Beijnum Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9rGf608NTgduBkuEflA3chqO+5xN/pmA//98F3CAAJtogP//fIhwgACZygD//6iI8A== Date: Sun, 2 Nov 2014 21:21:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> In-Reply-To: <54567634.3020403@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/GBTzZIRbc7W10ZsXZK0_3nU3GgU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2014 21:22:05 -0000 Hi Jeroen, You seem to be getting wrapped up with the notion that I am wanting DHCPv6 = to maintain lots of unnecessary state. I don't - I am primarily interested in the DHCPv= 6 signaling messages themselves and their implication for the NBMA interface neighbor cache: - DHCPv6 Request/Reply creates a neighbor cache entry with the Client's AER= O address as the network-layer address and the Client's access link address as the = link-layer address. - DHCPv6 Renew/Reply refreshes the neighbor cache entry lifetime - DHCPv6 Rebind/Reply either adds/deletes a new access link (there may be multiple of these) or changes the link-layer address of an existing access link - DHCPv6 Release/Reply is for shutting down the service or moving to a new = Server Try not to think of this as me getting "enterprisey", except that in this c= ase the "enterprise" is the entire public Internet. I know the document currently s= ays "enterprise" in a lot of places, but let's try to keep an open mind about o= ther possibilities. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Sunday, November 02, 2014 10:22 AM > To: Templin, Fred L; Iljitsch van Beijnum > Cc: Owen DeLong; v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendatio= n re: 6to4 >=20 > On 2014-11-02 18:26, Templin, Fred L wrote: > [..] > >>> The tunnel broker address is automatically derived from the DNS. > >> > >> Or you just get those details from a protocol like TIC or TSP and let > >> the actual Tunnel Broker decide on these details. > > > > Well, looking up a FQDN to get A or AAAA records gives you some assuran= ce that > > the tunnel broker you are talking to has properly registered itself in = the DNS. >=20 > As the TIC server is identified with a DNS label, you do that. >=20 > (And you do not want a AAAA record when you do not have IPv6 > connectivity yet) >=20 > >> Both SixXS and HE do static prefix delegation. > > > > In a sense, it is essentially static prefix delegation with the AERO DH= CPv6 service > > model as well since the service needs to maintain a table of Client ID-= to-prefix > > mappings. >=20 > A tunnel broker really can't care less about DHCP, it is all static. >=20 > Actually, except for the current IPv4 endpoint, an identity and a > passphrase, there is very little state in a proper tunnel broker. >=20 > >> But there is absolutely no reason to do DHCPv6. > > > > Mobility and multihoming. >=20 > You do not need DHCPv6 for either of that. >=20 > Note that heartbeat and AYIYA "solve" (for varying degrees of "solve") > Mobility aka "my IPv4 endpoint changes" or better "my current IPv4 > endpoint and optionally UDP port are X and Y). >=20 > > The Client can register itself with the Server using whatever > > access network IP address(e) it happens to have at the moment. So, for = example, if the > > Client gets a different access network IP address every time it boots u= p the Server learns > > the new address during the DHCPv6 Request/Reply exchange. >=20 > Why bother with DHCP? You only need to signal the current IPv4 endpoint: > heartbeat or AYIYA (which does a per-packet heartbeat). >=20 > > Afterwards, if the Client > > gets a new access network IP address (e.g., when moving from 4G to WiFi= ) it issues a > > DHCPv6 Rebind and the Server updates its address. Or, if the Client has= multiple active > > access network IP addresses, it can register them all with the Server u= sing DHCPv6 > > Rebind and again use Rebind if the addresses ever change. >=20 > No need to do "Rebinds" or other stuff like that. Every heartbeat causes > the endpoint to be updated. >=20 > You are trying to make it all to Enterprisey and solving problems that > are not there. >=20 > People who have multiple IPv4 endpoints will use the protocols that are > suited for that. >=20 > 6in4/heartbeat/AYIYA/TSP are all *transition technologies* they do not > solve multihoming and other such things. >=20 > AYIYA could solve those, but I chose not to bother with it. Very few > people have multiple upstreams, and if you do, you can chose your > 'current' one by sourcing the packets from there. >=20 > >> Per default there is a _routed_ /64, and otherwise you request a large= one. > > > > Prefix lengths other than /64 should be supported, yes. And, they must = be > > routable as well - no difference there. >=20 > Per default it is a /64 so that the enduser can announce that per radvd > on their local LAN. >=20 > If they want to request "a large one" which typically is a /48. >=20 > As it is just a line in TIC, it does not matter what happens to it or > how many bits it has. As it is static, they do not even have to look it > up in TIC actually. Though Fritz!Box and Motorola do that as then the > user does not have to type anything except user/pass/tunnel_id. >=20 > >> As the user gets a _static_ prefix, if somebody wants to bother with > >> DHCPv6, let them do that on their end. > > > > A Client that receives a prefix via DHCPv6 PD from a Server can certain= ly turn around > > and act as a DHCPv6 server to sub-delegate portions of that prefix to i= ts downstream > > attached end user networks, yes. That is the same as for any DHCPv6 PD = scenario. >=20 > The user can chose themselves to bother with DHCP if they want that > state stuff. For the tunnel and prefix delegation it is not needed. >=20 > I actually have myself never bother with DHCPv6, I just do static radvd, > simple and works. I do hear a lot of people have problems with it. If > people want to play with it, they can, their network on that side of the > tunnel. No need to get Tunnel Brokers to do so. >=20 > For SixXS we did think of doing DHCPv6-PD but decided that it is too > much overhead and state for something that is static anyway. Why have > state when one does not need it? >=20 > And I actually don't recall anybody asking about such a 'feature'; > likely as there is no reason for Tunnel Brokers to do so anyway. >=20 > Greets, > Jeroen From nobody Sun Nov 2 21:10:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9A1A0162 for ; Sun, 2 Nov 2014 21:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcyad3e2zYuk for ; Sun, 2 Nov 2014 21:10:12 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81DC1A028A for ; Sun, 2 Nov 2014 21:10:12 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B0A5E20697 for ; Mon, 3 Nov 2014 00:10:10 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 03 Nov 2014 00:10:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=4phFs4sQ7cz4tIAeeU44IjPSbwA=; b=VcZUmqi7zKVSy+Z/Z j+0cg2MMA5GlVSGqTLAzqL+UtpjX1Xj/vyX2TRlBV78WGe/6FjwDlZsNW0V1D4kS uontr/Xb8/0/GavHJEMR6HW4LslRXCAk97b28XbJQd/KKvyo2pCjCBTlMOpN5GCa k2cAKBcSGtrpbin6rBkUvVoxOA= X-Sasl-enc: qo745vRZTCfYN+DZAvYWOcvgzrqYgnESZulGpxeaIZpa 1414991410 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A61868024E; Mon, 3 Nov 2014 00:10:10 -0500 (EST) Message-ID: <54570E27.60504@network-heretics.com> Date: Mon, 03 Nov 2014 00:09:59 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Lorenzo Colitti References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> Content-Type: multipart/alternative; boundary="------------030702000903090906010603" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8YzOHD1NR9mnqKWJxtkUeKUexw4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 05:10:19 -0000 This is a multi-part message in MIME format. --------------030702000903090906010603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/02/2014 11:35 AM, Metzler, Dan J wrote: > That said, back to the original discussion, involving protocol 41, if > AT&T is truly blocking protocol 41 because they provide IPv6 native > support across the board already, that seems a lot less unreasonable. protocol 41 isn't just IPv6 over IPv4. Keith --------------030702000903090906010603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.
protocol 41 isn't just IPv6 over IPv4.

Keith

--------------030702000903090906010603-- From nobody Sun Nov 2 22:34:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0AC1A1A42 for ; Sun, 2 Nov 2014 22:34:49 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU6PaIOZy_y2 for ; Sun, 2 Nov 2014 22:34:47 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8922D1A1A39 for ; Sun, 2 Nov 2014 22:34:47 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 93C23100A0398; Mon, 3 Nov 2014 06:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414996483; bh=GD75EbZs4qpTUiH3K+nP0GiRTwH4VP3+PKBvmEa10V0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jRVOT27fMhj9PZhzIq3a8QRcc53cIV498U57RoLWaybb2ejcIVXFu2qnQen1mA3YA yu2qtO/p+RfU8cZRVDQ6aPvZNdjYuyCEbSP7mouSPErnTleRbgG6PMfxuZ4Kh1fTLo JMFWpaOiD1wNjF6ntavmvwyQ2DeVSB+10f1VIfrnUmAVK6SbTJQsFQ7EzMVkM+oE25 hqpfd1QHpO+MBE3tlxblRUF+bmo7wzJ3N8nSNjAHgN15qf9ZI+IQA6EyzxbZVGJVzT 2VfYLC8YU30IUhJLnabW/3Qe8FA/okhtSRPxi1vTMT1VYq/sk2JH/9R3uMrMa8mjmR EwASdbEJ4MJmQ== Message-ID: <54572201.5040201@massar.ch> Date: Mon, 03 Nov 2014 07:34:41 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> In-Reply-To: <54570E27.60504@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W3xCEAjoMEPFybvxCZwJTBj26ZE Cc: "v6ops@ietf.org WG" Subject: [v6ops] "protocol 41 isn't just IPv6 over IPv4." (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 06:34:49 -0000 On 2014-11-03 06:09, Keith Moore wrote: > On 11/02/2014 11:35 AM, Metzler, Dan J wrote: >> That said, back to the original discussion, involving protocol 41, if >> AT&T is truly blocking protocol 41 because they provide IPv6 native >> support across the board already, that seems a lot less unreasonable. > protocol 41 isn't just IPv6 over IPv4. What "else" is it then? :) Yes, 6in4 (as in tunnelbrokers), 6rd, 6to4 and some others use it. But blocking proto-41 blocks in essence anything that is transmitting proto-41 packets and thus "IPv6 over IPv4". The problem here is a ISP policy decision though; AT&T should not be blocking things in the first place. Contact AT&T to resolve that matter, nothing the IETF can do about (except suggesting alternative protocols to circumvent such a block). Greets, Jeroen From nobody Sun Nov 2 22:43:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA11A1A42 for ; Sun, 2 Nov 2014 22:43:04 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vqcu-vQ_v2Y for ; Sun, 2 Nov 2014 22:43:02 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA8E1A1A70 for ; Sun, 2 Nov 2014 22:43:02 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id A7E4C100A111F; Mon, 3 Nov 2014 06:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414996979; bh=JaPm5AwKiInWKpnqH0GphuhhRLZGqM7suWvJazQal8s=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=WzcyrthiMViHdKXIT+Cb/rnx5Uuo/7xZTkWytBY8R+0jFvjInhV0ATgdj51hONy7q WOtgwsmbKoItuIOupYvZqvDBDsCCdfGXHxTWew2Pt51d1KZpnecH3QQUFa0aq8/ntC EmCWvmb9ISwj3tYatklObJoPOho5l0GWnvBR2n01HFvB7UY2BUDSdlVNCdiQpTJNig v1wp2pV89FvDFMCpGK1qyCEokSX7LENBSrZBBNkXC1CoJa1u0yTBtTEma/AoeTsyjb iuOCTTamNucpL2e3faXOpJdHSONMtoqI7Dav4lDkvOlV/FMA4e9F5Ae51+2rYpRPM6 5t+4t470yLaKQ== Message-ID: <545723F1.9000207@massar.ch> Date: Mon, 03 Nov 2014 07:42:57 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Og2GvBFXpGZs-2zc62GIwfq1VCc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 06:43:04 -0000 On 2014-11-02 22:21, Templin, Fred L wrote: > Hi Jeroen, > > You seem to be getting wrapped up with the notion that I am wanting DHCPv6 to maintain > lots of unnecessary state. I don't - I am primarily interested in the DHCPv6 signaling messages > themselves and their implication for the NBMA interface neighbor cache: For the subject at hand: "getting IPv6 to endsites that do not have it yet" You do not need anything DHCP-ish. DHCP is for directly-on-the-same-link endpoints. Tunnels are not on-link, they are 'somewhere-on-the-internet'. And you need a tunnel before being able to do anything DHCP-ish. Unless you propose people start dropping those DHCP firewall rules around the Internet (yes, people block DHCP there for obvious reasons). TSP or TIC (pick your poison) already solve the "signaling" for figuring out the tunnel parameters. Then use 6in4(-heartbeat)/TSP/AYIYA to actually get the tunnel going. No need to come up with new protocols that make things more complex than that. TSP (the signaling/configuration part) is already XML based for 'extensibility'. Note that TIC was developed in parallel and chose a simple SMTP-alike protocol; though if I would have to do it now I would simply use HTTP as that has a lot less issues with firewalls. Greets, Jeroen From nobody Sun Nov 2 23:13:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0031A1A79 for ; Sun, 2 Nov 2014 23:13:31 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM_2CEeQY6o4 for ; Sun, 2 Nov 2014 23:13:28 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B391E1A1A74 for ; Sun, 2 Nov 2014 23:13:22 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D53AC1008E4E3; Mon, 3 Nov 2014 07:13:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414998800; bh=tk2xkd6Crqb8H/HSiZpVhkBS7nbjNJ3w9r3D+cn1HKw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=YHiCO7Gqy5G84YEDThH678lkU6Pg+JBdjVfixFVu4o7DlKnRhqaqhzLFee5sI+4JL 7Btk3wp1BCVhpzAH9/UoxPfE6vo/U1rRIRJoRpkCc6+95OkI7EpMRzxuJHOEK3TMDR xMWPBp7k6aduWJroZ3GWTxwR7FFr3wv60H0v1unYgePNtfMETx5+8ZjAR4SJLFZqCq UgTpQ+Xn1wW50hNWg09W8PYdg+kBYwJzMhrVSBlyegaESkLd4etAquJzOI2WJf9h7y SKy4RftoHsHGQZP49WTC9igK0ARClRXk6Kphrv3PeCm7clChPoh4dE2d6wbWu9P9Zm nVf2EIFCDN4CA== Message-ID: <54572B0C.1000601@massar.ch> Date: Mon, 03 Nov 2014 08:13:16 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Erik Kline References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <54572201.5040201@massar.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OB4GEUtBOrHhuMQZau68U871Os4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] "protocol 41 isn't just IPv6 over IPv4." (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 07:13:32 -0000 On 2014-11-03 07:56, Erik Kline wrote: > Yes, clearly we're going need IPv4(TCP(TLS(HTTP(IPv6))))). Already exists in a variety of ways ;) One extreme method of circumvention: OpenVPN in TCP mode using SOCKS over StegoTorus[1] with the help of JumpBox[2] to make sure it really looks like a normal web browser. Though AYIYA "circumvents" AT&T and even the real Great Big Firewall quite well actually... as they do not know that they can block it. Greets, Jeroen [1] https://github.com/SRI-CSL/stegotorus http://freehaven.net/anonbib/cache/ccs2012-stegotorus.pdf [2] https://github.com/SRI-CSL/jumpbox http://jeroen.massar.ch/publications/files/SECURECOMM2014-JumpBox.pdf http://jeroen.massar.ch/presentations/files/SECURECOMM2014-JumpBox-pres.pdf From nobody Sun Nov 2 23:27:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB441A6F13 for ; Sun, 2 Nov 2014 23:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xvz5Y27pOVP for ; Sun, 2 Nov 2014 23:27:55 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9081A1A81 for ; Sun, 2 Nov 2014 23:27:54 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 2C87D1008E4E7; Mon, 3 Nov 2014 07:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414999672; bh=cUvpNFX1nkeG5WS3CO/Epz2ov78yDC4EY8TQa81iiIA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=vkca8z3nA0wOa+pumdNHInb8xW6sCYP2ps54UzpG8qMXTfFVhNvKS/TGxbR44di3d VZe050JWV2SsBGgQ5TBTpaT6WcEOonmSLVhr9ylKKVtx5qY8aYMKTFUSOOnrh5B89Y 93yPR8dQQjy0hHerQDBP9w867AdoqvvWkp6aXeuyC+u76AhE7wnAGcbcDCziqP7PXw Nem6W+fNkqLqXhxquLrixFJlQ6l1oZaGnwv406nictYA1W+G7XtAKiFybDw94vMW00 9ALxtwXSGjGM8GeHmzxl0cCs+k/X3gsrx9jiBStf1+Cnfj7mqrR9YYPw08BB+9Sh1v 8iCcDcROQjcuQ== Message-ID: <54572E76.6050104@massar.ch> Date: Mon, 03 Nov 2014 08:27:50 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <54568756.5010401@gmail.com> In-Reply-To: <54568756.5010401@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3KFzvFJk2_dg1ejBYUIwm62xSvY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 07:27:56 -0000 On 2014-11-02 20:34, Brian E Carpenter wrote: > On 03/11/2014 02:15, Jeroen Massar wrote: >> On 2014-11-02 13:31, Iljitsch van Beijnum wrote: >>> If we want to come up with a tunneling mechanism that can replace >>> 6to4 as the simple, easy choice to get tunneled IPv6 when native >>> isn't available, perhaps it would be helpful to get together and >>> discuss some options in Honolulu. >> >> (Note that not everybody gets to take holiday trips to exotic >> destinations for "work"; rather go there for vacation and enjoy the >> scenery then sitting in a conference room over there...). >> >> I don't think that "replacing" 6to4 is going to bring anything useful at >> this point in time. This "transition" game has been running for close to >> 20 years already... >> >> And during that time several tools have come into existence and have >> gained wide deployment that solve these issues. > > Yes. When I don't find native v6 I either lie back and enjoy NAT44 > or I hook up to SixXs. It's actually hard to beat AYIYA except that > the setup is for geeks rather than normal humans. Yep, an AICCU installer would be something quite useful. Something with time and other things to do unfortunately. On Debian it is just 'apt-get install aiccu', on OSX it is a 'brew install aiccu' and one is done though. Windows changes also a lot needing new tun/tap drivers quite often which makes it a bit more time-required to maintain. > (The lack of an > RFC doesn't seem to matter, which rather puts the discussion of > deprecation and Historic status for 6to4 in its proper perspective.) > > I think this topic is OBE. We should focus on the ISPs and content > providers who didn't get the message. They typically have business cases clashing with IPv6 (not wanting to give out IP addresses due to 'servers' that clashes with their hosting business), or lazy folks who didn't pay attention and thus did not calculate this whole 'upgrade hardware to a device that supports IPv6' in the last 15 years... and thus are waiting for the next replacement round and just sitting it out. There is: - native, for when the hardware supports it - 6rd, for when the last-leg hardware does not Anything else is for the end-user to do, eg tunnel broker. I really cannot see how the IETF can do more (in the way of protocols) that could further help this situation. Note that I have heard ISPs who are deploying DSLite (thus providing native IPv6 and CGN IPv4) pointing their customers at SixXS so that the end-user can regain access to their home network from their $otherlocation. That is one of the fun counters of DSLite. Then again, users from that same ISP have been doing AYIYA over the CGN so that they get a static IPv6 prefix and apparently AYIYA is faster over the CGN than the native IPv6 that ISP provides, which is a ehmm funny... Greets, Jeroen From nobody Mon Nov 3 03:44:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4A1A00C0 for ; Mon, 3 Nov 2014 03:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hW-Z1HSYnkg for ; Mon, 3 Nov 2014 03:44:24 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013F41A00B9 for ; Mon, 3 Nov 2014 03:44:23 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 05:44:22 -0600 From: "Metzler, Dan J" To: Keith Moore , Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEIAAb7GA///B4hCAAoRIgIAAUB2AgACIU4D//7SI4AAnPoqAAAB/O3A= Date: Mon, 3 Nov 2014 11:44:22 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFF@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> In-Reply-To: <54570E27.60504@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: multipart/alternative; boundary="_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFFITSNT440iowauio_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sq0UtfJ3-0x6hDp6_4OEOpPkpj8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 11:44:25 -0000 --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFFITSNT440iowauio_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCccHJvdG9jb2wgNDEgaXNuJ3QganVzdCBJUHY2IG92ZXIgSVB2NOKAnQ0KSW4gSVB2NCwgaXNu 4oCZdCBpdD8gIEl04oCZcyBwcmV0dHkgbXVjaCBkZXNpZ25hdGVkIGZvciBJUHY2IGVuY2Fwc3Vs YXRpb24uICBUaGVyZSBhcmUgYSB2YXJpZXR5IG9mIHByb3RvY29scyB0aGF0IGFjY29tcGxpc2gg dGhlIHNhbWUgZ29hbCwgSVB2NiBlbmNhcHN1bGF0aW9uLCB1c2luZyB0aGF0IHBvcnQsIGJ1dCBh bGwgdG8gY2FycnkgSVB2NiBvdmVyIElQdjQgaW4gc29tZSBtYW5uZXIuDQpJIHN0aWxsIGRvbuKA mXQgdGhpbmsgaXQgaXMgYW4gSVNQ4oCZcyBqb2IgdG8gYmxvY2sgYW55IG9uZSBwcm90b2NvbCwg aW5jbHVkaW5nIDQxLCBidXQgaWYgdGhleSBwcm92aWRlIG5hdGl2ZSBJUHY2LCBpdCBpcyBsZXNz IHVucmVhc29uYWJsZSBiZWNhdXNlIGF0IGxlYXN0IHRoZXkgYWxyZWFkeSBwcm92aWRlIG5hdGl2 ZSBJUHY2IGNvbm5lY3Rpdml0eS4gIE9uY2UgeW91ciBwcm92aWRlcnMgcHJvdmlkZSBuYXRpdmUg SVB2Niwgd2h5IHdvdWxkIHdlIGV2ZW4gbmVlZCBJUHY0IHByb3RvY29sIDQxPyAgQXQgdGhhdCBw b2ludCBpdOKAmXMgc2lsbHkgdG8gdHVubmVsIHY2IGluIHY0IHdoZW4geW91IGNhbiBqdXN0IGJl IG1vcmUgZWZmaWNpZW50IHdpdGggZHVhbCBzdGFjaywgcmlnaHQ/DQooVGhlIHJlYXNvbiBpdCBp cyBqdXN0IOKAnGxlc3MgdW5yZWFzb25hYmxl4oCdIGlzIGJlY2F1c2UgdGhlIGJsb2NraW5nIElT UCA8QVQmVCBpbiB0aGlzIGNhc2U+IG1heSBiZSBzZXJ2aW5nIG90aGVyIHByb3ZpZGVycyB3aG8g aGF2ZW7igJl0IHByb3ZpZGVkIG5hdGl2ZSBJUHY2LCBhbmQgdGhvc2UgcHJvdmlkZXJzIG1heSBu ZWVkIGFjY2VzcyB0byB0dW5uZWwgdG8gdGhlaXIgdHVubmVsIGVuZHBvaW50cyBvciBicm9rZXJz LikNCg0KDQpGcm9tOiBLZWl0aCBNb29yZSBbbWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3Mu Y29tXQ0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyLCAyMDE0IDExOjEwIFBNDQpUbzogTWV0emxl ciwgRGFuIEo7IExvcmVuem8gQ29saXR0aQ0KQ2M6IE93ZW4gRGVMb25nOyB2Nm9wc0BpZXRmLm9y ZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02 dG80LXRvLWhpc3RvcmljLTA2LnR4dCAtIGFsdGVybmF0aXZlcyB0byA2dG80DQoNCk9uIDExLzAy LzIwMTQgMTE6MzUgQU0sIE1ldHpsZXIsIERhbiBKIHdyb3RlOg0KVGhhdCBzYWlkLCBiYWNrIHRv IHRoZSBvcmlnaW5hbCBkaXNjdXNzaW9uLCBpbnZvbHZpbmcgcHJvdG9jb2wgNDEsIGlmIEFUJlQg aXMgdHJ1bHkgYmxvY2tpbmcgcHJvdG9jb2wgNDEgYmVjYXVzZSB0aGV5IHByb3ZpZGUgSVB2NiBu YXRpdmUgc3VwcG9ydCBhY3Jvc3MgdGhlIGJvYXJkIGFscmVhZHksIHRoYXQgc2VlbXMgYSBsb3Qg bGVzcyB1bnJlYXNvbmFibGUuDQpwcm90b2NvbCA0MSBpc24ndCBqdXN0IElQdjYgb3ZlciBJUHY0 Lg0KDQpLZWl0aA0K --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFFITSNT440iowauio_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCc PC9zcGFuPnByb3RvY29sIDQxIGlzbid0IGp1c3QgSVB2NiBvdmVyIElQdjQ8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIElQdjQsIGlzbuKAmXQg aXQ/Jm5ic3A7IEl04oCZcyBwcmV0dHkgbXVjaCBkZXNpZ25hdGVkIGZvciBJUHY2IGVuY2Fwc3Vs YXRpb24uJm5ic3A7IFRoZXJlIGFyZSBhIHZhcmlldHkgb2YgcHJvdG9jb2xzIHRoYXQgYWNjb21w bGlzaCB0aGUgc2FtZSBnb2FsLCBJUHY2IGVuY2Fwc3VsYXRpb24sIHVzaW5nDQogdGhhdCBwb3J0 LCBidXQgYWxsIHRvIGNhcnJ5IElQdjYgb3ZlciBJUHY0IGluIHNvbWUgbWFubmVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIHN0aWxsIGRvbuKAmXQgdGhpbmsgaXQgaXMgYW4gSVNQ4oCZcyBqb2IgdG8g YmxvY2sgYW55IG9uZSBwcm90b2NvbCwgaW5jbHVkaW5nIDQxLCBidXQgaWYgdGhleSBwcm92aWRl IG5hdGl2ZSBJUHY2LCBpdCBpcyBsZXNzIHVucmVhc29uYWJsZSBiZWNhdXNlIGF0IGxlYXN0IHRo ZXkNCiBhbHJlYWR5IHByb3ZpZGUgbmF0aXZlIElQdjYgY29ubmVjdGl2aXR5LiZuYnNwOyBPbmNl IHlvdXIgcHJvdmlkZXJzIHByb3ZpZGUgbmF0aXZlIElQdjYsIHdoeSB3b3VsZCB3ZSBldmVuIG5l ZWQgSVB2NCBwcm90b2NvbCA0MT8mbmJzcDsgQXQgdGhhdCBwb2ludCBpdOKAmXMgc2lsbHkgdG8g dHVubmVsIHY2IGluIHY0IHdoZW4geW91IGNhbiBqdXN0IGJlIG1vcmUgZWZmaWNpZW50IHdpdGgg ZHVhbCBzdGFjaywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihUaGUgcmVhc29uIGl0IGlzIGp1 c3Qg4oCcbGVzcyB1bnJlYXNvbmFibGXigJ0gaXMgYmVjYXVzZSB0aGUgYmxvY2tpbmcgSVNQICZs dDtBVCZhbXA7VCBpbiB0aGlzIGNhc2UmZ3Q7IG1heSBiZSBzZXJ2aW5nIG90aGVyIHByb3ZpZGVy cyB3aG8gaGF2ZW7igJl0IHByb3ZpZGVkIG5hdGl2ZSBJUHY2LCBhbmQNCiB0aG9zZSBwcm92aWRl cnMgbWF5IG5lZWQgYWNjZXNzIHRvIHR1bm5lbCB0byB0aGVpciB0dW5uZWwgZW5kcG9pbnRzIG9y IGJyb2tlcnMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gS2Vp dGggTW9vcmUgW21haWx0bzptb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBTdW5kYXksIE5vdmVtYmVyIDIsIDIwMTQgMTE6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1ldHpsZXIsIERhbiBKOyBMb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5DYzo8L2I+IE93ZW4gRGVM b25nOyB2Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDYudHh0IC0gYWx0 ZXJuYXRpdmVzIHRvIDZ0bzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMTEvMDIvMjAxNCAxMTozNSBBTSwgTWV0emxlciwgRGFuIEogd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYXQgc2FpZCwgYmFjayB0byB0aGUgb3JpZ2luYWwg ZGlzY3Vzc2lvbiwgaW52b2x2aW5nIHByb3RvY29sIDQxLCBpZiBBVCZhbXA7VCBpcyB0cnVseSBi bG9ja2luZyBwcm90b2NvbCA0MSBiZWNhdXNlIHRoZXkgcHJvdmlkZSBJUHY2IG5hdGl2ZSBzdXBw b3J0IGFjcm9zcyB0aGUgYm9hcmQNCiBhbHJlYWR5LCB0aGF0IHNlZW1zIGEgbG90IGxlc3MgdW5y ZWFzb25hYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cHJvdG9jb2wgNDEgaXNu J3QganVzdCBJUHY2IG92ZXIgSVB2NC48YnI+DQo8YnI+DQpLZWl0aDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFFITSNT440iowauio_-- From nobody Mon Nov 3 08:21:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAB41A19F4 for ; Mon, 3 Nov 2014 08:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Ld3IBwttuaRj for ; Mon, 3 Nov 2014 08:21:16 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33501A0469 for ; Mon, 3 Nov 2014 08:21:12 -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 sA3GLCQR026036; Mon, 3 Nov 2014 08:21:12 -0800 Received: from XCH-BLV-203.nw.nos.boeing.com (xch-blv-203.nw.nos.boeing.com [10.57.37.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA3GL2CE025896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Nov 2014 08:21:02 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.150]) with mapi id 14.03.0210.002; Mon, 3 Nov 2014 08:21:02 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP9rGf608NTgduBkuEflA3chqO+5xN/pmA//98F3CAAJtogP//fIhwgACZygD//6iI8AAk0p6AAALD0iA= Date: Mon, 3 Nov 2014 16:21:01 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> <545723F1.9000207@massar.ch> In-Reply-To: <545723F1.9000207@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/6USOBrO2tY3Cp0niAgI-CUuIiKE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 16:21:18 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Sunday, November 02, 2014 10:43 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendatio= n re: 6to4 >=20 > On 2014-11-02 22:21, Templin, Fred L wrote: > > Hi Jeroen, > > > > You seem to be getting wrapped up with the notion that I am wanting DHC= Pv6 to maintain > > lots of unnecessary state. I don't - I am primarily interested in the D= HCPv6 signaling messages > > themselves and their implication for the NBMA interface neighbor cache: >=20 > For the subject at hand: > "getting IPv6 to endsites that do not have it yet" >=20 > You do not need anything DHCP-ish. DHCP is for directly-on-the-same-link > endpoints. For the NBMA tunnel virtual interface I am describing, all endpoints are directly-on-the-same-link, and DHCPv6 clients and servers are always single-hop neighbors. > Tunnels are not on-link, they are 'somewhere-on-the-internet'. Again, all endpoints on the NBMA tunnel virtual link are on-link. DHCPv6 an= d IPv6 ND works over the link the same as for any IPv6 link. > And you need a tunnel before being able to do anything DHCP-ish. The NBMA tunnel interface is always available, and can be used to send an encapsulated packet to any prospective neighbor at any time and with no explicit configuration. Brian Carpenter knows this. He invented it. > Unless you propose people start dropping those > DHCP firewall rules around the Internet (yes, people block DHCP there > for obvious reasons). It would not look like DHCP on the physical links that carry the tunneled p= ackets; it would all just look like UDP port 8060. > TSP or TIC (pick your poison) already solve the "signaling" for figuring > out the tunnel parameters. Then use 6in4(-heartbeat)/TSP/AYIYA to > actually get the tunnel going. There is no need to get an NBMA tunnel going; it is always going, and alway= s available to send tunneled packets to any prospective neighbor. > No need to come up with new protocols that make things more complex than > that. You are inferring complexity where there is none. Any Client can send a Server an encapsulated DHCPv6 or IPv6 ND packet at any time and with no explicit tunnel configuration. And, it is really not a new protocol; it is based on long-standing Internet standards. > TSP (the signaling/configuration part) is already XML based for > 'extensibility'. >=20 > Note that TIC was developed in parallel and chose a simple SMTP-alike > protocol; though if I would have to do it now I would simply use HTTP as > that has a lot less issues with firewalls. AERO uses IPv6 ND and DHCPv6 the same as for any link. This takes care of neighbor discovery, mobility management, multihoming, link-local address autoconfiguration, prefix delegation and anything you might want to do on an ordinary IPv6 link with one exception - the AERO link is link-local-only= . Thanks - Fred fred.l.templin@boeing.com=20 > Greets, > Jeroen From nobody Mon Nov 3 09:22:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731C1A1B0B for ; Mon, 3 Nov 2014 09:22:16 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I2GwMkshMkY for ; Mon, 3 Nov 2014 09:22:08 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80891A1AE0 for ; Mon, 3 Nov 2014 09:22:06 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 4CF73100A3671; Mon, 3 Nov 2014 17:22:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415035323; bh=DgnjQpO9ZozIjNGeWQqp79PH5tm5wMPpjVK92+uQpFI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=WRTtuuzh5rVZiDc0C2cY9wQPhx79eX9LMLBMU9QZ0tiBdsBhZ7LnZSBzuzZoO41+O O94xRWBibXX/Vptia3Z8lKU9RCK8IhoqZuFKB+Dl+lRd561HV9Xhe3FQgQE4sxGbdI GAnewLCQ9UbGsvOmwLW9Xno9bRP/8DJ3uTHzCfCbPilT5nD9FF15pBhW61k36pUg7t 1X6fuh31fYj/KuINURXQWDf1b1IeQc7vZzx84XlbiLoWHplBbf5FhzAxFcNxDMbtXO l+l/Vdhu2GTxAzwtxi6dPwdIphltJwWc12a9QWFwEgWb5/2m+gqDy0vuLvS7ETrrtf ZyMt5n+vRcJrA== Message-ID: <5457B9B8.5010809@massar.ch> Date: Mon, 03 Nov 2014 18:22:00 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> <545723F1.9000207@massar.ch> <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HicIepfJV4Y1RUQQH1VGR19JLmA Cc: "v6ops@ietf.org WG" Subject: [v6ops] Seems AERO / RFC6706 is the subject (Was: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 17:22:16 -0000 On 2014-11-03 17:21, Templin, Fred L wrote: > Hi Jeroen, So it seems we strayed somewhere off the '6to4 replacement' subject and got into a discussion about AERO / RFC6706. Apologies that I did not notice that context switch. Updated the Subject: to match this. >> -----Original Message----- >> From: Jeroen Massar [mailto:jeroen@massar.ch] >> Sent: Sunday, November 02, 2014 10:43 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org WG >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 >> >> On 2014-11-02 22:21, Templin, Fred L wrote: >>> Hi Jeroen, >>> >>> You seem to be getting wrapped up with the notion that I am wanting DHCPv6 to maintain >>> lots of unnecessary state. I don't - I am primarily interested in the DHCPv6 signaling messages >>> themselves and their implication for the NBMA interface neighbor cache: >> >> For the subject at hand: >> "getting IPv6 to endsites that do not have it yet" >> >> You do not need anything DHCP-ish. DHCP is for directly-on-the-same-link >> endpoints. > > For the NBMA tunnel virtual interface I am describing, all endpoints are > directly-on-the-same-link, and DHCPv6 clients and servers are always > single-hop neighbors. If you indeed have a such a virtual network already setup, then as it is multi-access doing DHCP makes sense. The problem is that you first need to set up such an (overlay) network and inform all involved who are involved. [..] >> And you need a tunnel before being able to do anything DHCP-ish. > > The NBMA tunnel interface is always available, and can be used to send an > encapsulated packet to any prospective neighbor at any time and with no > explicit configuration. Brian Carpenter knows this. He invented it. As Brian has a very large curriculum, which one do you mean? Encapsulating things does not mean that those packets make it to the other side. proto-41 for instance does not go through NATs. Something has to set it up, something has to configure it. >> Unless you propose people start dropping those >> DHCP firewall rules around the Internet (yes, people block DHCP there >> for obvious reasons). > > It would not look like DHCP on the physical links that carry the tunneled packets; > it would all just look like UDP port 8060. Aha, it seems you are talking about experimental RFC6706. The only reference in that document to using the port is the "AERO Redirection Message Format", thus I can only assume that something else has to carry the actual packets and those packets are not likely going to go over the 8060/udp port you mention. Something has to tell the involved hosts where and how to send those packets though, there is no magic specified in that RFC that will tell otherwise. Those parameters are part of your tunnel setup. And even if those special "AERO" packets are inside UDP, where are the real packets going to be encapsulated in? >> TSP or TIC (pick your poison) already solve the "signaling" for figuring >> out the tunnel parameters. Then use 6in4(-heartbeat)/TSP/AYIYA to >> actually get the tunnel going. > > There is no need to get an NBMA tunnel going; it is always going, and always > available to send tunneled packets to any prospective neighbor. Something has to configure it; after that, yes, likely that it will keep on working. Though NATs have these nasty timers that this magic NBMA tunnel has to account for and keep alive (simply keeping on sending packets typically does the trick though, but one has to account for the source port on the NAT side changing over time and that typically this only works for UDP). >> No need to come up with new protocols that make things more complex than >> that. > > You are inferring complexity where there is none. Any Client can send a > Server an encapsulated DHCPv6 or IPv6 ND packet at any time and with > no explicit tunnel configuration. And, it is really not a new protocol; it > is based on long-standing Internet standards. That can only work when you have that virtual overlay that can do multicast style setups. It will be grossly inefficient to that on a scale of 10.000 clients where only 2 (the server and that specific client) need to see that packet. As such not appropriate for a system the scale that should 'replace' 6to4. >> TSP (the signaling/configuration part) is already XML based for >> 'extensibility'. >> >> Note that TIC was developed in parallel and chose a simple SMTP-alike >> protocol; though if I would have to do it now I would simply use HTTP as >> that has a lot less issues with firewalls. > > AERO uses IPv6 ND and DHCPv6 the same as for any link. > This takes care of neighbor discovery Why does a tunnel need Neighbor Discovery? Unless you are stuffing every client in the world on the same /64. The endpoints likely already know what the other end is anyway. > mobility management Mobility of what kind? There is all kinds of mobility. Some people still think that IPv6 Mobility is an actual thing that exists and gets used. I have actually never seen anybody use it... KAME MIP6 etc are there but rarely actually get used except for playing/testing. http://www.mobileip.jp/ is even missing in action... > multihoming, Single homing right? There is no "Send packets here first" or "send 50% of the packets here" or "I am also at" messages in AERO from what I can see. Hence, even if we just look at the redirect, the packet will go to one place. Maybe you mean that the underlying carrier handles this? Proper multihoming has a lot of factors, amongst which available bandwidth per endpoint, latency properties etc. None of which are easily figured out and most of which are easily misguessed/configured. Hence why most multihoming setups typically monitor the availability of a link and then just hot-potato packets over each link, stopping to send when that link is 'full' or does not respond in an expected way. Or by selecting based on QOS or specific destinations. BGP/OSPF etc come into play a lot there. > link-local address autoconfiguration, The link-protocol (Ethernet or other tunnel mechanism) should take care of that. Thus all link types that require it will do that. How is this a special feature? > prefix delegation and anything you might want to do on > an ordinary IPv6 link with one exception - the AERO link is link-local-only. Why would it only be link local? Anyway, my apologies for not reading into your messages that you where talking about RFC6706. More apologies for not knowing that it was a draft and was going for RFC otherwise I could have read and reviewed it and asked various questions about it. For me RFC6706 is a long piece of text with a lot of claims and complexity, but it does not actually state what is actually happening. >From reading it my summary is: - AERO defines a 'redirect' message to 'repoint a tunnel endpoint' (section 6.4.5) - some tunneling protocol is used to carry actual packets. - not defined how these tunnels are configured As such, for me that whole RFC is unclear what the target is, or more importantly what problem it is supposed to solve in the first place. (yes, there are requirements, but these seem to be written around what the protocol does, not what actual problems there are in the world) And thus I also wonder how that got into this thread about a 6to4 replacement: problem = get IPv6 to endhosts that do not have it. But then again, I might just be missing something completely obvious... Greets, Jeroen From nobody Mon Nov 3 09:40:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645981A1BFA for ; Mon, 3 Nov 2014 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 wYuw_PP26q5B for ; Mon, 3 Nov 2014 09:40:40 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4320A1A1BEA for ; Mon, 3 Nov 2014 09:40:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA3HedND032607; Mon, 3 Nov 2014 09:40:39 -0800 Received: from XCH-BLV-403.nw.nos.boeing.com (xch-blv-403.nw.nos.boeing.com [130.247.25.62]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA3HeWb1032075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Nov 2014 09:40:33 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.128]) with mapi id 14.03.0210.002; Mon, 3 Nov 2014 09:40:31 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: Seems AERO / RFC6706 is the subject (Was: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4) Thread-Index: AQHP941DUDN5YXnQikGpRK6RE/Ltig== Date: Mon, 3 Nov 2014 17:40:30 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D77B39@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> <545723F1.9000207@massar.ch> <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> <5457B9B8.5010809@massar.ch> In-Reply-To: <5457B9B8.5010809@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/alAGC5IP-PSEwE3bTITlfG33uSw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Seems AERO / RFC6706 is the subject (Was: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 17:40:44 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Monday, November 03, 2014 9:22 AM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Seems AERO / RFC6706 is the subject (Was: [v6ops] Bar BoF on a 6= to4 replacement? Was: my recommendation re: 6to4) >=20 > On 2014-11-03 17:21, Templin, Fred L wrote: > > Hi Jeroen, >=20 > So it seems we strayed somewhere off the '6to4 replacement' subject and > got into a discussion about AERO / RFC6706. Apologies that I did not > notice that context switch. Updated the Subject: to match this. The correct reference for this discussion is 'draft-templin-aerolink', whic= h will obsolete RFC6706 when it is published. RFC6706 can even now be considered as histori= c even though it has not been officially designated as such. However, 'draft-templin-aerolink' is also a candidate replacement for 6to4.= AERO works everywhere AFAICT, and does more than just a transition mechanism wou= ld. It is in fact intended as a long-term solution which has IPv6/IPv4 coexiste= nce as just one aspect. Mobility, multi-homing, route optimization, security, etc. are = just a few of the other aspects. =20 > >> -----Original Message----- > >> From: Jeroen Massar [mailto:jeroen@massar.ch] > >> Sent: Sunday, November 02, 2014 10:43 PM > >> To: Templin, Fred L > >> Cc: v6ops@ietf.org WG > >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommenda= tion re: 6to4 > >> > >> On 2014-11-02 22:21, Templin, Fred L wrote: > >>> Hi Jeroen, > >>> > >>> You seem to be getting wrapped up with the notion that I am wanting D= HCPv6 to maintain > >>> lots of unnecessary state. I don't - I am primarily interested in the= DHCPv6 signaling messages > >>> themselves and their implication for the NBMA interface neighbor cach= e: > >> > >> For the subject at hand: > >> "getting IPv6 to endsites that do not have it yet" > >> > >> You do not need anything DHCP-ish. DHCP is for directly-on-the-same-li= nk > >> endpoints. > > > > For the NBMA tunnel virtual interface I am describing, all endpoints ar= e > > directly-on-the-same-link, and DHCPv6 clients and servers are always > > single-hop neighbors. >=20 > If you indeed have a such a virtual network already setup, then as it is > multi-access doing DHCP makes sense. >=20 > The problem is that you first need to set up such an (overlay) network > and inform all involved who are involved. There is no setup needed. It is tunneling without explicit tunnels. > [..] > >> And you need a tunnel before being able to do anything DHCP-ish. > > > > The NBMA tunnel interface is always available, and can be used to send = an > > encapsulated packet to any prospective neighbor at any time and with no > > explicit configuration. Brian Carpenter knows this. He invented it. >=20 > As Brian has a very large curriculum, which one do you mean? RFC2529 (circa 1999). > Encapsulating things does not mean that those packets make it to the > other side. proto-41 for instance does not go through NATs. AERO can work over proto-41, but the normal case is to use UDP port 8060. > Something has to set it up, something has to configure it. It is a tunnel without explicit tunnel configuration. > >> Unless you propose people start dropping those > >> DHCP firewall rules around the Internet (yes, people block DHCP there > >> for obvious reasons). > > > > It would not look like DHCP on the physical links that carry the tunnel= ed packets; > > it would all just look like UDP port 8060. >=20 > Aha, it seems you are talking about experimental RFC6706. No; I am talking about 'draft-templin-aerolink'. UDP port 8060 is shared be= tween RFC6706 and 'draft-templin-aerolink'. > The only reference in that document to using the port is the "AERO > Redirection Message Format", thus I can only assume that something else > has to carry the actual packets and those packets are not likely going > to go over the 8060/udp port you mention. We are out of context; the correct reference for this discussion is 'draft-templin-aerolink'. Although they are much appreciated, I don't think it would be helpful to try to respond to your other points for now until we get into the correct context. Thanks - Fred fred.l.templin@boeing.com > Something has to tell the involved hosts where and how to send those > packets though, there is no magic specified in that RFC that will tell > otherwise. Those parameters are part of your tunnel setup. >=20 > And even if those special "AERO" packets are inside UDP, where are the > real packets going to be encapsulated in? >=20 > >> TSP or TIC (pick your poison) already solve the "signaling" for figuri= ng > >> out the tunnel parameters. Then use 6in4(-heartbeat)/TSP/AYIYA to > >> actually get the tunnel going. > > > > There is no need to get an NBMA tunnel going; it is always going, and a= lways > > available to send tunneled packets to any prospective neighbor. >=20 > Something has to configure it; after that, yes, likely that it will keep > on working. Though NATs have these nasty timers that this magic NBMA > tunnel has to account for and keep alive (simply keeping on sending > packets typically does the trick though, but one has to account for the > source port on the NAT side changing over time and that typically this > only works for UDP). >=20 > >> No need to come up with new protocols that make things more complex th= an > >> that. > > > > You are inferring complexity where there is none. Any Client can send a > > Server an encapsulated DHCPv6 or IPv6 ND packet at any time and with > > no explicit tunnel configuration. And, it is really not a new protocol;= it > > is based on long-standing Internet standards. >=20 > That can only work when you have that virtual overlay that can do > multicast style setups. >=20 > It will be grossly inefficient to that on a scale of 10.000 clients > where only 2 (the server and that specific client) need to see that packe= t. >=20 > As such not appropriate for a system the scale that should 'replace' 6to4= . >=20 > >> TSP (the signaling/configuration part) is already XML based for > >> 'extensibility'. > >> > >> Note that TIC was developed in parallel and chose a simple SMTP-alike > >> protocol; though if I would have to do it now I would simply use HTTP = as > >> that has a lot less issues with firewalls. > > > > AERO uses IPv6 ND and DHCPv6 the same as for any link. > > This takes care of neighbor discovery >=20 > Why does a tunnel need Neighbor Discovery? Unless you are stuffing every > client in the world on the same /64. The endpoints likely already know > what the other end is anyway. >=20 > > mobility management >=20 > Mobility of what kind? There is all kinds of mobility. >=20 > Some people still think that IPv6 Mobility is an actual thing that > exists and gets used. I have actually never seen anybody use it... KAME > MIP6 etc are there but rarely actually get used except for > playing/testing. http://www.mobileip.jp/ is even missing in action... >=20 > > multihoming, >=20 > Single homing right? There is no "Send packets here first" or "send 50% > of the packets here" or "I am also at" messages in AERO from what I can s= ee. >=20 > Hence, even if we just look at the redirect, the packet will go to one > place. Maybe you mean that the underlying carrier handles this? >=20 > Proper multihoming has a lot of factors, amongst which available > bandwidth per endpoint, latency properties etc. None of which are easily > figured out and most of which are easily misguessed/configured. >=20 > Hence why most multihoming setups typically monitor the availability of > a link and then just hot-potato packets over each link, stopping to send > when that link is 'full' or does not respond in an expected way. > Or by selecting based on QOS or specific destinations. BGP/OSPF etc come > into play a lot there. >=20 > > link-local address autoconfiguration, >=20 > The link-protocol (Ethernet or other tunnel mechanism) should take care > of that. Thus all link types that require it will do that. How is this a > special feature? >=20 >=20 > > prefix delegation and anything you might want to do on > > an ordinary IPv6 link with one exception - the AERO link is link-local-= only. >=20 > Why would it only be link local? >=20 >=20 > Anyway, my apologies for not reading into your messages that you where > talking about RFC6706. More apologies for not knowing that it was a > draft and was going for RFC otherwise I could have read and reviewed it > and asked various questions about it. >=20 > For me RFC6706 is a long piece of text with a lot of claims and > complexity, but it does not actually state what is actually happening. >=20 > From reading it my summary is: > - AERO defines a 'redirect' message to 'repoint a tunnel endpoint' > (section 6.4.5) > - some tunneling protocol is used to carry actual packets. > - not defined how these tunnels are configured >=20 > As such, for me that whole RFC is unclear what the target is, or more > importantly what problem it is supposed to solve in the first place. > (yes, there are requirements, but these seem to be written around what > the protocol does, not what actual problems there are in the world) >=20 > And thus I also wonder how that got into this thread about a 6to4 > replacement: problem =3D get IPv6 to endhosts that do not have it. >=20 > But then again, I might just be missing something completely obvious... >=20 > Greets, > Jeroen From nobody Mon Nov 3 10:37:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0271A1BA4 for ; Mon, 3 Nov 2014 10:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdyA-zBETBn6 for ; Mon, 3 Nov 2014 10:37:24 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116881A6FB6 for ; Mon, 3 Nov 2014 10:37:23 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C7B17100A3669; Mon, 3 Nov 2014 18:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415039840; bh=4x5ZOUlPVhLZp4++xMpA8CPpWzv4HrPWJmkPBvg8Tn8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=taTZXMXKUz63Wq+ZB9pNaNM8E/Qj4DJa6dxa61by/tcuorNYLrYnhsDbryDfbL3C0 jZoXsSq3+zs2I4fpH7sASaMvlopkg63HVlneIGg7G4InTCmIcUoRf47/6vIt6+M/Vw zuGTRd59cNYWGp0hV+KbWs+/EMh/WZ4YugJUSuYW8H6y2WcV+suruSpkiG+Gu1CLQM C1GHK5ZV9s9OWQpapy8TRO+GwDwNKPcbfU8V3+h8Om3h3p0LeyndJPVSUYH5YoNPsJ cL8is3mx3aj3zhSBuNbXWSkxix/qbei2TGhl6yajKZJfWtY7Z2NrbLrxJEdyKtv6u6 aOf3jjdv0oHTQ== Message-ID: <5457CB5D.2040901@massar.ch> Date: Mon, 03 Nov 2014 19:37:17 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> <545723F1.9000207@massar.ch> <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> <5457B9B8.5010809@massar.ch> <2134F8430051B64F815C691A62D9831832D77B39@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D77B39@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EHlzsSJ4D0JpqKjLPlmyGjlDoX8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] AERO / draft-templin-aerolink / RFC6706 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 18:37:31 -0000 On 2014-11-03 18:40, Templin, Fred L wrote: [..] >> So it seems we strayed somewhere off the '6to4 replacement' subject and >> got into a discussion about AERO / RFC6706. Apologies that I did not >> notice that context switch. Updated the Subject: to match this. > > The correct reference for this discussion is 'draft-templin-aerolink', which will obsolete > RFC6706 when it is published. RFC6706 can even now be considered as historic even > though it has not been officially designated as such. > > However, 'draft-templin-aerolink' is also a candidate replacement for 6to4. AERO > works everywhere AFAICT, and does more than just a transition mechanism would. > It is in fact intended as a long-term solution which has IPv6/IPv4 coexistence as just > one aspect. Mobility, multi-homing, route optimization, security, etc. are just a few > of the other aspects. That is one very very big document with a lot of funny technical constructs. But it misses a very important section "Problem Statement": What is the problem it is trying to solve that cannot be solved already with other tools/protocols? [..] > There is no setup needed. It is tunneling without explicit tunnels. What tool tells the AERO components what "AERO Service Prefix (ASP)" to use? What "AERO Server" to talk too etc? Where does that come from? What are the authentication parameters? This Internet thing is quite evil. Accepting packets from random sources will not fly for long. [..] >> As Brian has a very large curriculum, which one do you mean? > > RFC2529 (circa 1999). aka "6over" which is afaik not used anywhere? Something with "there is no multicast" especially not on the Internet. Nope, university networks do not count and typically that is only the core which gets it, if they are 'lucky'. >> Encapsulating things does not mean that those packets make it to the >> other side. proto-41 for instance does not go through NATs. > > AERO can work over proto-41, but the normal case is to use UDP port 8060. Just putting packets in UDP is not enough. You need to make sure that it can handle a switching source UDP port and that there are enough packets being sent to keep the binding open. Also, such a tunnel is per definition a point-to-point link. That the routing protocols above might flood packets to all those links is a separate thing. >> Something has to set it up, something has to configure it. > > It is a tunnel without explicit tunnel configuration. See above, you have parameters, these need to be configured. >>>> Unless you propose people start dropping those >>>> DHCP firewall rules around the Internet (yes, people block DHCP there >>>> for obvious reasons). >>> >>> It would not look like DHCP on the physical links that carry the tunneled packets; >>> it would all just look like UDP port 8060. >> >> Aha, it seems you are talking about experimental RFC6706. > > No; I am talking about 'draft-templin-aerolink'. UDP port 8060 is shared between > RFC6706 and 'draft-templin-aerolink'. I was not aware of the latter; will read more if you can specify the problem statement and how this is supposed to solve those problems. >> The only reference in that document to using the port is the "AERO >> Redirection Message Format", thus I can only assume that something else >> has to carry the actual packets and those packets are not likely going >> to go over the 8060/udp port you mention. > > We are out of context; the correct reference for this discussion is > 'draft-templin-aerolink'. Although they are much appreciated, I don't think > it would be helpful to try to respond to your other points for now until we > get into the correct context. Subject is fixed to solve that problem Greets, Jeroen From nobody Mon Nov 3 10:57:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7271A0006 for ; Mon, 3 Nov 2014 10:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QwV3X3CrMZv for ; Mon, 3 Nov 2014 10:57:40 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED3C1A0099 for ; Mon, 3 Nov 2014 10:57:39 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id la4so3508400vcb.37 for ; Mon, 03 Nov 2014 10:57:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oxUey97dwGGx5asCgUecXYPlvE00HHIf8kQToRgtwnw=; b=Ue1KfFk6mbvbj0ed0eG/QYPdIBbD1Ht3ui+31jCULZEZwZi48ps0rq/uaS240hWYtv FRc9x09Ht323heJTgk0Sz2rfuz3Y0x2mHarhhePOchXd8QYx2M3QBKMp+kR8MUIYLjrp rx76ai2o5Pudz22n7edrRz0lr2dvINLgdUicDhQRrpsc/6n+X+tdpK2j1hQCJbSVOb/v QFAJygyfFh9E/J9lcoeLPc6ThE/krsVL+vrw8yoN82dy6L3ZAVuRZoJmHAaV+6V2+Q7L Fwl7y51o/G9W9P5PSfT4diSL9QSzxLe3X5z9th+NKUb6j27OkCT0BqqcdqGbNw3YEObj G40Q== X-Gm-Message-State: ALoCoQmpPCpjqeFYHjWunD5XmUVs4vC6d9Evrqpmh0clu/lMkeheHXflJlqOmYaFHD+GqUMegsBX MIME-Version: 1.0 X-Received: by 10.220.174.193 with SMTP id u1mr38707081vcz.28.1415041057776; Mon, 03 Nov 2014 10:57:37 -0800 (PST) Received: by 10.31.10.65 with HTTP; Mon, 3 Nov 2014 10:57:37 -0800 (PST) In-Reply-To: <5454244C.6060507@gmail.com> References: <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <5454244C.6060507@gmail.com> Date: Mon, 3 Nov 2014 10:57:37 -0800 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e01538db2977d630506f8ebe1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WPjfEprluc3bW7DF2nJAP7pBKnQ Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.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, 03 Nov 2014 18:57:41 -0000 --089e01538db2977d630506f8ebe1 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 31, 2014 at 5:07 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 01/11/2014 06:15, Templin, Fred L wrote: > > > While I have the floor, I know of at least one enterprise that uses > public IPv4 addresses > > internally. Some devices inside the enterprise see the public addresses > and then assume > > they can use 6to4. They then set up a 6to4 virtual interface with a > 2002:* address assigned, > > i.e., even though the enterprise has not deployed a 6to4 service. > > > > What would deprecation mean to this class of devices? > > Until somebody upgrades the host software in a way that removes 6to4, > nothing, as far as I can see. It's just the same as p2p 6to4 on the > Internet, isn't it? > I think moving RFC 3068 to Historic while keeping RFC 3056 on the Standards Track should be sufficient to keep devices like that from being deprecated. As long as they're not self-assigning an IPv6 default route, and they're only giving themselves a local 2002::/16 route to the 6to4 tunnel, everything should be fine. Moving RFC 3068 to History should be sufficient to communicate to the maintainers of the software for those devices that acquiring an IPv6 default route for traffic originating at their 6to4 sources addresses entails some kind of manual or locally automated configuration. -- james woodyatt Nest Labs, Communications Engineering --089e01538db2977d630506f8ebe1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 5:07 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 01/11/2014 06:15, Templin, Fred L wrote:

> While I have the floor, I know of at least one enterprise that uses pu= blic IPv4 addresses
> internally. Some devices inside the enterprise see the public addresse= s and then assume
> they can use 6to4. They then set up a 6to4 virtual interface with a 20= 02:* address assigned,
> i.e., even though the enterprise has not deployed a 6to4 service.
>
> What would deprecation mean to this class of devices?

Until somebody upgrades the host software in a way that removes 6to4= ,
nothing, as far as I can see. It's just the same as p2p 6to4 on the
Internet, isn't it?
I think moving RFC 3068 to Historic while keeping RFC 3056 on the S= tandards Track should be sufficient to keep devices like that from being de= precated.=C2=A0 As long as they're not self-assigning an IPv6 default r= oute, and they're only giving themselves a local 2002::/16 route to the= 6to4 tunnel, everything should be fine.=C2=A0 Moving RFC 3068 to History s= hould be sufficient to communicate to the maintainers of the software for t= hose devices that acquiring an IPv6 default route for traffic originating a= t their 6to4 sources addresses entails some kind of manual or locally autom= ated configuration.


--
james woodyatt <jhw@nestlabs.com>=
Nest Labs, Communications Engineering
--089e01538db2977d630506f8ebe1-- From nobody Mon Nov 3 11:19:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D01A6F84 for ; Mon, 3 Nov 2014 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 jT8DR26dAvBP for ; Mon, 3 Nov 2014 11:19:54 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FDF1A005D for ; Mon, 3 Nov 2014 11:19:54 -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 sA3JJsWm017805; Mon, 3 Nov 2014 11:19:54 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA3JJilB017285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Nov 2014 11:19:44 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.235]) with mapi id 14.03.0210.002; Mon, 3 Nov 2014 11:19:43 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: AERO / draft-templin-aerolink / RFC6706 Thread-Index: AQHP95sfWLE4cCU2SkGm0SJEAgDLSw== Date: Mon, 3 Nov 2014 19:19:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D77DA4@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> <2134F8430051B64F815C691A62D9831832D76CC2@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D76CFC@XCH-BLV-504.nw.nos.boeing.com> <5456637B.5090302@massar.ch> <2134F8430051B64F815C691A62D9831832D76DC8@XCH-BLV-504.nw.nos.boeing.com> <54567634.3020403@massar.ch> <2134F8430051B64F815C691A62D9831832D76FDE@XCH-BLV-504.nw.nos.boeing.com> <545723F1.9000207@massar.ch> <2134F8430051B64F815C691A62D9831832D7787B@XCH-BLV-504.nw.nos.boeing.com> <5457B9B8.5010809@massar.ch> <2134F8430051B64F815C691A62D9831832D77B39@XCH-BLV-504.nw.nos.boeing.com> <5457CB5D.2040901@massar.ch> In-Reply-To: <5457CB5D.2040901@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/YW55r-6dQIL_KvbQ9-VoruCj2DQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] AERO / draft-templin-aerolink / RFC6706 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 19:19:56 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Monday, November 03, 2014 10:37 AM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: AERO / draft-templin-aerolink / RFC6706 >=20 > On 2014-11-03 18:40, Templin, Fred L wrote: > [..] > >> So it seems we strayed somewhere off the '6to4 replacement' subject an= d > >> got into a discussion about AERO / RFC6706. Apologies that I did not > >> notice that context switch. Updated the Subject: to match this. > > > > The correct reference for this discussion is 'draft-templin-aerolink', = which will obsolete > > RFC6706 when it is published. RFC6706 can even now be considered as his= toric even > > though it has not been officially designated as such. > > > > However, 'draft-templin-aerolink' is also a candidate replacement for 6= to4. AERO > > works everywhere AFAICT, and does more than just a transition mechanism= would. > > It is in fact intended as a long-term solution which has IPv6/IPv4 coex= istence as just > > one aspect. Mobility, multi-homing, route optimization, security, etc. = are just a few > > of the other aspects. >=20 > That is one very very big document with a lot of funny technical construc= ts. >=20 > But it misses a very important section "Problem Statement": > What is the problem it is trying to solve that cannot be solved > already with other tools/protocols? Full routing and addressing support for fixed, mobile and/or multi-homed de= vices in an Internetwork using IPvANY-in-IPvANY encapsulation. Example Internetworks in= clude enterprise networks, cellular operator networks, ISP networks, and the publ= ic Internet itself. As the SixXS POC, you might also consider using AERO to provide IPv= 6 services to Client customers to give them more than just IPv6/IPv4 transition. The way = it would work is that the SixXS tunnel broker(s) would be replaced by AERO Servers - of w= hich there may be many (e.g., 10's, 100's, etc.) topologically distributed throughout the = Internet. Clients get services from a nearby Server, and Clients get the same services no mat= ter which Server they associate with. So, the Client load is spread. If the Client ge= ts a new link-layer address (e.g., if it needs to blast a new hole through an existi= ng NAT, if changes from 4G wireless to WiFi, etc.) it sends DHCPv6 Rebind to its Serve= r which updates its neighbor cache link-layer address. > [..] > > There is no setup needed. It is tunneling without explicit tunnels. >=20 > What tool tells the AERO components what "AERO Service Prefix (ASP)" to > use? DHCPv6. > What "AERO Server" to talk too etc? Where does that come from? DNS lookup for the domain name "linkupnetworks.example.com" returns a list of link-layer addresses of candidate nearby AERO Servers. "example.com= " is a domain name managed by the AERO Service Provider. > What are the authentication parameters? This Internet thing is quite > evil. Accepting packets from random sources will not fly for long. Secure DHCPv6 (Clients sign their messages based on certificates). > [..] > >> As Brian has a very large curriculum, which one do you mean? > > > > RFC2529 (circa 1999). >=20 > aka "6over" which is afaik not used anywhere? I should have been more specific. The aspect of Brian's invention that carr= ies forward into AERO is the point-to-multipoint tunnel virtual interface model= , where there is no explicit configuration needed for a node to send a tunnel= ed *unicast* packet to an on-link neighbor. > Something with "there is no multicast" especially not on the Internet. > Nope, university networks do not count and typically that is only the > core which gets it, if they are 'lucky'. Again, I should have been more specific. Unlike RFC2529, the AERO tunnel virtual interface model is NBMA in its basic manifestation. However, there is support for at least "All_DHCP_Relay_Agents_And_Servers" multicast and there is a section on how to support other multicast, based on whether the underlying network is multicast-capable or non-multicast-capable. So, consi= der NBMA as the basic service model and partial/full multicast-capable as the "augmented" service model. > >> Encapsulating things does not mean that those packets make it to the > >> other side. proto-41 for instance does not go through NATs. > > > > AERO can work over proto-41, but the normal case is to use UDP port 806= 0. >=20 > Just putting packets in UDP is not enough. You need to make sure that it > can handle a switching source UDP port and that there are enough packets > being sent to keep the binding open. AERO sends periodic NS/NA (or RS/RA) to keep middlebox state alive. If the UDP source port changes, the path to the neighbor will appear to be failing and the Client can either try to do DHCPv6 Rebind with the existing Server or ditch the existing Server and associate with a new Server. (The spec doesn't currently talk about Rebind, though; it would probably be worth fixing this because frequent changes between Servers is not a very good idea.) (BTW, the UDP port is considered as part of the Client's link-layer address= . If the UDP port changes, then the Client's link-layer address changes and needs to be updated with any existing neighbors. This is indistinguishable from a mobility event.) > Also, such a tunnel is per definition a point-to-point link. That the Not a point-to-point link, rather there is an NBMA interface neighbor relationship between the two neighbors that may require periodic "bubbles" (teredo terminology) or "heartbeats" (your terminology, I think?) to keep neighbor and middlebox state alive. For AERO, that is typically NS/NA. =20 > routing protocols above might flood packets to all those links is a > separate thing. I don't get the part about routing protocol flooding; that doesn't resonate with any aspects of AERO that I am aware of. Can you be more specific? > >> Something has to set it up, something has to configure it. > > > > It is a tunnel without explicit tunnel configuration. >=20 > See above, you have parameters, these need to be configured. The parameters are just neighbor cache entry network- and link-layer addres= ses. These are autoconfigured during DHCPv6 exchanges. > >>>> Unless you propose people start dropping those > >>>> DHCP firewall rules around the Internet (yes, people block DHCP ther= e > >>>> for obvious reasons). > >>> > >>> It would not look like DHCP on the physical links that carry the tunn= eled packets; > >>> it would all just look like UDP port 8060. > >> > >> Aha, it seems you are talking about experimental RFC6706. > > > > No; I am talking about 'draft-templin-aerolink'. UDP port 8060 is share= d between > > RFC6706 and 'draft-templin-aerolink'. >=20 > I was not aware of the latter; will read more if you can specify the > problem statement and how this is supposed to solve those problems. Let me now if you need more information than I have already given. =20 > >> The only reference in that document to using the port is the "AERO > >> Redirection Message Format", thus I can only assume that something els= e > >> has to carry the actual packets and those packets are not likely going > >> to go over the 8060/udp port you mention. > > > > We are out of context; the correct reference for this discussion is > > 'draft-templin-aerolink'. Although they are much appreciated, I don't t= hink > > it would be helpful to try to respond to your other points for now unti= l we > > get into the correct context. >=20 > Subject is fixed to solve that problem OK. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Mon Nov 3 13:13:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F51A872F for ; Mon, 3 Nov 2014 13:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=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 dbPSPvUXiibu for ; Mon, 3 Nov 2014 13:13:37 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7A01A872E for ; Mon, 3 Nov 2014 13:13:37 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA3LBrcL019829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 13:11:53 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA3LBrcL019829 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1415049114; bh=zoSi9Lt0XJeQh7rluq89QymSI28=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JtI7MDvNaW36CncU2HDVCnGoge0G2gPdKiz+vLybCN9L35aXtOUtgliojwth+5NGz 2uPUMCNCfY43QzBrd0jx8MoMQS71Dt6w2NjHCT1/sTH67/0C/K5c9i1NaFMVlg/5wc ZB4aV3VEnybO5o0XMGRLGi+TH2vyP97YaIK3L8+4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Mon, 3 Nov 2014 13:11:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Nov 2014 13:11:54 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tInPkXtqjzqoeg9bUu8qIORYElU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 21:13:39 -0000 I won=E2=80=99t be in HNL, so I can=E2=80=99t attend the bar BoF. >>> I'll go one step further and say it MUST NOT be protocol 41 based. >=20 >> Why not? >=20 > Because you're limited to one proto 41 user behind an IPv4 address and = thus won't work for CGN users. So what you=E2=80=99re really saying here isn=E2=80=99t =E2=80=9CMUST = NOT be protocol 41=E2=80=9D so much as =E2=80=9CMUST BE use a known = NAT-Friendly Transport Layer Protocol.=E2=80=9D >> What's wrong with explicitly configured 6in4 tunnels? >=20 > I use one every day so there's a lot right with them. The trouble is = that they involve too much configuration and aren't flexible enough. For = instance, when I get a new IPv4 address from my ISP I need to go into = the tunnelbroker.net web interface to update my tunnel endpoint. Sure, but a little bit of software added to your router using the API = that HE publishes for that _COULD_ actually automate that. > But like I mentioned later in my message, I think much of what's = required can already be found in existing tunnel broker systems, perhaps = all that's needed is to bring it all together in a way that allows it to = be almost as easy to use as 6to4, while continuing to benefit from the = much better reliability of explicitly created tunnels. Yep. My point is that HE has actually already built all of the hooks = necessary on their side. All that is needed is for router and/or host = vendors to write the client-side glue. There is a published API for the tunnel broker. Admittedly, that doesn=E2=80=99t work for NAT or CGN users because the = HE tunnelbroker is protocol 41 based, but it does cover the vast = majority of cases. Do you really expect vast numbers of CGN implementations that don=E2=80=99= t provide native IPv6 at this point? Most of the implementations of CGN = that I=E2=80=99m aware of are targeted at supporting IPv6 users that = still need IPv4 access. >>> - work through NAT >>> - work through CGN >=20 >> Meh... There are tunnel mechanisms that achieve this, but they create = unnecessary pain in other areas where these are not a factor. OTOH, I'm = not sure there needs to be "one true tunneling mechanism". Requiring the = additional overhead of UDP in all cases and STUN in general doesn't feel = like a win in the cases where NAT traversal is not required. >=20 > Even in the case where the tunnel is terminated on a home gateway and = the user isn't behind a CGN, it's not uncommon for NAT to be in the = middle because the tunnel endpoint is on a different box than the = ISP-provided NAT box. So I'd say: eat the 8 bytes of UDP for the case of = simplicity, even when it's not necessary. No need for STUN or = Teredo-like complexity if the tunnel is set up from the inside to a = single outside destination, you just need to generate traffic = periodically to keep the NAT state in place. And you want keepalives = anyway to determine when the tunnel has gone down for another reason = (such as an IPv4 address change). That requires some form of reliable way to make sure that all return = traffic is routed back through the same gateway at the other side. This = is obviously achievable, but it reduces reliability or increases = complexity. > Another way to go would be to allow a few different types of existing = tunnel mechanisms, most notably 6rd. This would make the system a little = more complex on the client side, but allows for reusing existing gateway = side implementations. If we go down that route, it would be easy enough = to include the option for the new system to simply retrieve a fixed = proto 41 configuration and be fully compatible with existing tunnel = brokers. I think this is probably the best way to go. >=20 >>> - automatically adapts to changing addresses >=20 >> Harder problem to solve. I could, however, do this today with some = development work on an HE tunnel. >=20 > Tunnel down -> reinitiate it from scratch. Simple enough for the = client. The tunnel broker would need some way to get the new client = address, though. Actually, I think the client should expect to inform the tunnel broker = of its address change=E2=80=A6 1. These are intended to be stateless tunnels, so authentication = isn=E2=80=99t feasible because authenticated vs. unauthenticated _IS_ = state. 2. The client can easily know when its address has changed. OTOH, = other than by address, it=E2=80=99s hard for the tunnel broker to know, and if the address no arriving is unknown, virtually = impossible to know what tunnel to associate it with and update. Currently, using existing APIs, the client, upon detecting a new address = could access and reconfigure the Tunnel Broker and the tunnel would come = back up. I had, at one point, scripted most of this on my site, but it = was fragile because the script depended on polling my router from a = third host and then connecting to the tunnel broker OOB. >>> - doesn't require ISP cooperation >=20 >> Since all packet forwarding requires some level of ISP cooperation, I = think you need to be a little more clear about your meaning here. >=20 > I mean in the sense that it still works if the ISP doesn't do anything = to help. Sure, on this I agree (presuming that simply forwarding packets is = within the bounds of not doing anything to help), but yes, I agree in = the context of =E2=80=9CISP shouldn=E2=80=99t have to host or = participate in configuring or provisioning tunnels or providing tunnel = termination services in order for it to work=E2=80=9D. > It still working if the ISP goes out of its way to filter would be = another step. And I don't think we should attempt that, as it would be = hard to do and also because non-ISP networks such as businesses and = universities have a reasonably legitimate reason to not want to have = arbitrary tunnels on their networks. Agreed. Instead, we should simply attempt to destroy such ISPs through peer = pressure. ;-) > Obviously we'd want those networks to offer native IPv6, but if our = new tunnel mechanism can be terminated on the inside of such networks = and then firewalled the same way as other traffic would also be a good = solution. Ideally, yes, but doing this (firewalling tunneled traffic) in an = IPv6-ignorant network is difficult at best. >>> - traffic flows are reasonably optimized (i.e., if ISP offers = gateway service, by default, that gateway is used) >=20 >> This requires some form of service discovery mechanism that can = somehow be aware of what ISP you are using or otherwise has some = mechanism for automatically interfacing with said ISPs provisioning. >=20 > Yes. >=20 >> In the tradition of rough consensus and running code, it would be = great if you put forward your vision for how this would work. >=20 > What I have in mind is that there is a list of gateways and users are = connected to the gateway that serves them best, which would typically be = their ISP's gateway if they run one. How would this list be maintained? What would be the bar for getting on = the list? What would be the mechanism for maintaining the list? How = would a device locate the list at bootstrap? This is a nice hand wave and I understand the general desired outcome, = but there are many devils in the details. That=E2=80=99s what I was trying to convey with the =E2=80=9Crunning = code=E2=80=9D part of my comment. >> I definitely think that deprecation of configured 6in4 tunnels would = be very premature and somewhat harmful in general. >=20 > I agree; existing tunnel brokers should definitely keep doing for some = time to come. >=20 > But do you agree that the current tunnel broker system is too complex = to serve the role that 6to4 was intended to serve? I=E2=80=99ve never really been completely clear on the intended role for = 6to4 since it so clearly missed whatever mark that was, so it=E2=80=99s = hard to comment authoritatively. I will say that in my experience, no, most of the tunnel broker systems = are not that hard to use. What they lack is sufficient automation to = achieve the self-configuring aspects of 6to4. IMHO, said automation = could be built onto the existing services without too much effort. What = I don=E2=80=99t get is why none of the router vendors that set out to do = this have followed through. >>> The router or host, when it notices that there is no native IPv6, = connects to _tunserv._tcp. or something like that and = authenticates. The setup server then does a lookup of the source IPv4 = address and redirects to a gateway... >=20 >> This assumes a tremendous amount of cooperation and coordination not = in evidence. Who runs this central "setup server" service? Why? How is = it paid for? >=20 > What I imagine is that existing cloud services would incorporate that, = most notably Apple, Google and Microsoft, who all have shown various = levels of interest in getting IPv6 working well. But also any other = interested party, such as the existing tunnel brokers. The technical = part is basically running a web server and a user database, which = doesn't cost a meaningful amount of money. That depends on the level of support you want to provide to the users = when something goes horribly wrong. That can cost anywhere from virtually nothing to very much. > The harder part is the coordination, but the benefit is huge: you get = a tunnel that's terminated as close to the user as possible without = requiring any action from the user to accomplish this. I don=E2=80=99t think that tunnels that don=E2=80=99t require ANY action = from the user are a good thing, actually. The user _SHOULD_ have to approve any tunnel being created at least = once, IMHO. >>> I guess it would be possible for devices to log in using their MAC = address by default. >=20 >> There's also the issue that MAC addresses are only guaranteed to be = segment unique. There are many cases where they are _NOT_ globally = unique. >=20 >=20 > If the u/l bit is set to "unique" then they really are supposed to be = globally unique... Obviously there's ample evidence of failures in this = area, but how many affected devices are we talking about here? A = fraction of a fraction of a percent? =E2=80=9CSupposed to be=E2=80=9D and $10 will get you coffee at = Starbucks. In terms of the number of devices afflicted when you get down to = consumer grade routers, I=E2=80=99d bet it might well be a few percent. > There is no reason why one account couldn't set up multiple tunnels, = so this shouldn't be an issue. The reason to have accounts at all is to = be able to block them if people do bad things. Then you are blocked if = you use the default account and the user of a clone of your MAC address = does bad things. So set up a real account and your tunnel is back. So why not just require a real account in all cases to begin with. It = could easily be part of the router=E2=80=99s initial configuration = wizard. I simply don=E2=80=99t see the advantage to using a MAC address as an = authentication mechanism when we can avoid all of those issues so = easily. >> Also, ip-proto-41 does have path MTU challenges. We all know that = PMTUD is >> unreliable, which means the tunnel ingress has to set a "safe" MTU - = usually to >> something on the order of 1480 or smaller. >=20 > This is hard to avoid. Hopefully, with IPv6 there is enough tunneling = that people will clean up their PMTUD breakage rather than let those = with path MTUs below 1500 suffer, like what happens with IPv4. I=E2=80=99ve had <1500 MTU on both IPv4 and IPv6 for most of a decade. I = ran into fairly regular problems in IPv4 until about 3 years ago. I=E2=80=99= ve never seen significant problems in IPv6. I realize this isn=E2=80=99t everyone=E2=80=99s experience, but I think = for the most part unless you go specifically looking for brokenness or = live in Japan, IPv6 PMTU discovery mostly works. > A solution could be for home gateways that terminate a tunnel to = advertise the tunnel MTU in their RAs so hosts use the tunnel MTU and = also put that MTU in their TCP MSS. I think if you just do the MSS thing, it=E2=80=99s usually adequate in = my experience. Owen From nobody Mon Nov 3 13:23:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE351A8753 for ; Mon, 3 Nov 2014 13:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=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 FU4ai6YaNQTN for ; Mon, 3 Nov 2014 13:23:43 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C9CD41A0395 for ; Mon, 3 Nov 2014 13:23:43 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA3LJkPx020747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 13:19:57 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA3LJkPx020747 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1415049598; bh=cHH57vQ9ZgtoT18IKrtcniCsZBY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K0nrnGbkyB524UgezfRIzQx7Op1hzThz8Kst/q8WBhi2iPkz+FylfI7o1Sc9U0708 KT1uErlPbf7csW9ZM4G1SWIC+5ujP3o0UYEY1IJuByhARHNaPWE+9FOml0i6dc5mMk AoBvsQDOHptexZJr098ZKDJoZGW5YEFxn2cEXWOw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> Date: Mon, 3 Nov 2014 13:19:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> To: "Metzler, Dan J" X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Nov 2014 13:19:58 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VEYa2pKR6RKiroyO9w4fD-tc54U Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 21:23:45 -0000 I would argue that 6rd, CGN, or NAT64 should move you into a =E2=80=9CB=E2= =80=9D at best for starters. Further, I don=E2=80=99t think that making market judgments of = particular carriers is within the charter of the IETF. This moves out of = the realm of technical standards into product comparison and I would = expect substantial backlash against the IETF attempting to take on that = role. It might be something NANOG or IOL or ISOC or some other group could = take on, but I can=E2=80=99t see this fitting in the IETF charter. Owen > On Nov 2, 2014, at 5:37 AM, Metzler, Dan J = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Saturday, November 1, 2014 9:02 PM >> To: Metzler, Dan J >> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; = v6ops@ietf.org WG >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6to4-to-historic-06.txt - >> alternatives to 6to4 >>=20 >>>=20 >>> I don't have any kind of business relationship with AT&T, but if I = were a >> customer, I'd be asking them for my native IPv6 access at that point. = I don't >> pretend to suggest that there aren't people blocking protocol 41 for = no >> reason other than fear, and I generally don't think it's good for a = provider to >> block protocol 41 until they've provided some alternative. >>=20 >> Many have tried. Unfortunately, attempts to put pressure on AT&T by >> consumers are roughly equivalant to attempting to use one's thumb to >> compress a marshmallow into submission. Your thumb gets messy, but = the >> marshmallow doesn't care. >>=20 >> In this regard, think of AT&T as a giant death-star shaped = marshmallow only >> more bitter than sweet. >>=20 >=20 > While I understand that there is a large degree of truth to this, I = disagree with regard to the notion that any real attempts have been made = to put pressure on AT&T or similar ISPs. To put it in a less = confrontational way, I don't think there have been attempts to provide = ISPs with the necessary guidance or tools to know what the correct = behavior is. For example how about an RFC that defines standards of = acceptable ISP behavior and provides a grading system. This is = something that customers can use when shopping for ISPs. We could give = classifications based on certain standards. > For example from an IPv6 perspective: > "A" - ISP implements Native IPv6 and/or 6rd > "D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does = not block any traffic including that which might allow a customer to = implement IPv6. > "F" - ISP blocks traffic according to its own policies without = customer endorsement. (Not the function of an ISP.) >=20 > Something like this would allow for a meaningful conversation with = ISPs like AT&T, and provide context for rating ISPs in terms of = brokenness of their implementations, and a basis for publishing that = information. Of course these categories would not just be limited to = the context of IPv6 adoption, would have to be maintained as = technologies come and go, and would provide a more general measure for = reliability and basic functionality. >=20 > ISPs that claim grade A according to RFC #### could advertise that, = and customers could be assured by sticking with grade A ISPs, they can = accomplish anything they need to in terms of standard internet = functionality. A simple Wiki could be maintained by communities = regarding what the grades or for various ISPs. =20 >=20 > In any case, my point is, while individuals may have complained to = somebody working at AT&T, at various times, no real pressure has been = put on AT&T or any other ISP, even to adopt IPv6 or to allow for = customers to do so. No incentives have been provided either. We've = thus far relied only on the notion that they will work toward the goal = as they see an impact from lack of IPv4 addresses. The idea that I = would, as a customer ask, "where is my native IPv6", was less about = applying pressure, and more about starting the conversation about what = they could provide me as a customer. From nobody Mon Nov 3 14:52:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79081A1AAE for ; Mon, 3 Nov 2014 14:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 FL_yv-F8Zds0 for ; Mon, 3 Nov 2014 14:52: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 954561A1A2E for ; Mon, 3 Nov 2014 14:52:24 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 34FFA1FCAB3; Mon, 3 Nov 2014 22:52:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 20CC4160060; Mon, 3 Nov 2014 22:55:36 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E47EE16005A; Mon, 3 Nov 2014 22:55:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 484DB230A3D9; Tue, 4 Nov 2014 09:52:18 +1100 (EST) To: "Metzler, Dan J" From: Mark Andrews References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFF@ITSNT440.iowa.uiowa.edu> In-reply-to: Your message of "Mon, 03 Nov 2014 11:44:22 -0000." <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFF@ITSNT440.iowa.uiowa.edu> Date: Tue, 04 Nov 2014 09:52:18 +1100 Message-Id: <20141103225218.484DB230A3D9@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DoIF-IjQkV3KQ--fFn0blveA7SM Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 22:52:30 -0000 In message <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC9FFF@ITSNT440.iowa.uiowa.edu>, "Metzler, Dan J" writes: > protocol 41 isn't just IPv6 over IPv4 > In IPv4, isnt it? Its pretty much designated for IPv6 encapsulation. > There are a variety of protocols that accomplish the same goal, IPv6 > encapsulation, using that port, but all to carry IPv6 over IPv4 in some > manner. > I still dont think it is an ISPs job to block any one protocol, including > 41, but if they provide native IPv6, it is less unreasonable because at > least they already provide native IPv6 connectivity. Once your providers > provide native IPv6, why would we even need IPv4 protocol 41? Why do you need vpn's? Why do you need IPv4 in IPv4 tunnels. Why do you need GRE tunnels. Why do you need IPv6 in IPv6 tunnels? It is not the ISP's job to filter traffic. As long as it is being source with a legitimate address the ISP should just pass the packet along. If the ISP's routers can't pass the packet they should be replaced. This include routers that can't pass fragmented packets. You pay the ISP to deliver packets. > At that > point its silly to tunnel v6 in v4 when you can just be more efficient > with dual stack, right? > (The reason it is just less unreasonable is because the blocking ISP > may be serving other providers who havent provided > native IPv6, and those providers may need access to tunnel to their > tunnel endpoints or brokers.) > > > From: Keith Moore mailto:moore@network-heretics.com > Sent: Sunday, November 2, 2014 11:10 PM > To: Metzler, Dan J; Lorenzo Colitti > Cc: Owen DeLong; v6ops@ietf.org WG > Subject: Re: v6ops I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - > alternatives to 6to4 > > On 11/02/2014 11:35 AM, Metzler, Dan J wrote: > That said, back to the original discussion, involving protocol 41, if > AT&T is truly blocking protocol 41 because they provide IPv6 native > support across the board already, that seems a lot less unreasonable. > protocol 41 isn't just IPv6 over IPv4. > > Keith -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 3 15:11:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9BC1A8849 for ; Mon, 3 Nov 2014 15:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 pFsYY5PqGhK4 for ; Mon, 3 Nov 2014 15:11:47 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5241A8845 for ; Mon, 3 Nov 2014 15:11:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sA3NBk2C012130; Mon, 3 Nov 2014 15:11:46 -0800 Received: from XCH-BLV-407.nw.nos.boeing.com (xch-blv-407.nw.nos.boeing.com [130.247.25.165]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA3NBf0S012108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Nov 2014 15:11:42 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.29]) with mapi id 14.03.0210.002; Mon, 3 Nov 2014 15:11:41 -0800 From: "Templin, Fred L" To: Owen DeLong , Iljitsch van Beijnum Thread-Topic: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP97uGIlzPl+XDaUCYR32EWgqcuQ== Date: Mon, 3 Nov 2014 23:11:41 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D78297@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> In-Reply-To: <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.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: http://mailarchive.ietf.org/arch/msg/v6ops/OVvXwgp4Y1Sq8SMYcx_AZrk7b9w Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 23:11:49 -0000 SGksIGp1c3QgYSBmZXcgd29yZHMgb24gdGhpczoNCg0KPiA+PiBBbHNvLCBpcC1wcm90by00MSBk b2VzIGhhdmUgcGF0aCBNVFUgY2hhbGxlbmdlcy4gV2UgYWxsIGtub3cgdGhhdCBQTVRVRCBpcw0K PiA+PiB1bnJlbGlhYmxlLCB3aGljaCBtZWFucyB0aGUgdHVubmVsIGluZ3Jlc3MgaGFzIHRvIHNl dCBhICJzYWZlIiBNVFUgLSB1c3VhbGx5IHRvDQo+ID4+IHNvbWV0aGluZyBvbiB0aGUgb3JkZXIg b2YgMTQ4MCBvciBzbWFsbGVyLg0KPiA+DQo+ID4gVGhpcyBpcyBoYXJkIHRvIGF2b2lkLiBIb3Bl ZnVsbHksIHdpdGggSVB2NiB0aGVyZSBpcyBlbm91Z2ggdHVubmVsaW5nIHRoYXQgcGVvcGxlIHdp bGwgY2xlYW4gdXAgdGhlaXIgUE1UVUQgYnJlYWthZ2UgcmF0aGVyIHRoYW4gbGV0DQo+IHRob3Nl IHdpdGggcGF0aCBNVFVzIGJlbG93IDE1MDAgc3VmZmVyLCBsaWtlIHdoYXQgaGFwcGVucyB3aXRo IElQdjQuDQo+IA0KPiBJ4oCZdmUgaGFkIDwxNTAwIE1UVSBvbiBib3RoIElQdjQgYW5kIElQdjYg Zm9yIG1vc3Qgb2YgYSBkZWNhZGUuIEkgcmFuIGludG8gZmFpcmx5IHJlZ3VsYXIgcHJvYmxlbXMg aW4gSVB2NCB1bnRpbCBhYm91dCAzIHllYXJzIGFnby4gSeKAmXZlDQo+IG5ldmVyIHNlZW4gc2ln bmlmaWNhbnQgcHJvYmxlbXMgaW4gSVB2Ni4NCg0KTWF5YmUsIGJ1dCB3aHkgc2V0dGxlIGZvciA8 MTUwMCB3aGVuIHlvdSBjYW4gaGF2ZSAxNTAwKz8NCg0KPiBJIHJlYWxpemUgdGhpcyBpc27igJl0 IGV2ZXJ5b25l4oCZcyBleHBlcmllbmNlLCBidXQgSSB0aGluayBmb3IgdGhlIG1vc3QgcGFydCB1 bmxlc3MgeW91IGdvIHNwZWNpZmljYWxseSBsb29raW5nIGZvciBicm9rZW5uZXNzIG9yIGxpdmUg aW4gSmFwYW4sDQo+IElQdjYgUE1UVSBkaXNjb3ZlcnkgbW9zdGx5IHdvcmtzLg0KPiANCj4gPiBB IHNvbHV0aW9uIGNvdWxkIGJlIGZvciBob21lIGdhdGV3YXlzIHRoYXQgdGVybWluYXRlIGEgdHVu bmVsIHRvIGFkdmVydGlzZSB0aGUgdHVubmVsIE1UVSBpbiB0aGVpciBSQXMgc28gaG9zdHMgdXNl IHRoZSB0dW5uZWwNCj4gTVRVIGFuZCBhbHNvIHB1dCB0aGF0IE1UVSBpbiB0aGVpciBUQ1AgTVNT Lg0KPiANCj4gSSB0aGluayBpZiB5b3UganVzdCBkbyB0aGUgTVNTIHRoaW5nLCBpdOKAmXMgdXN1 YWxseSBhZGVxdWF0ZSBpbiBteSBleHBlcmllbmNlLg0KDQpOb3QgYWxsIHByb3RvY29scyBpbmNs dWRlIGFuIE1TUy4gQ29uc2lkZXIgZm9yIGV4YW1wbGUgYSB0dW5uZWwgdGhhdCBvcmlnaW5hdGVz DQpmcm9tIGJlaGluZCB0aGUgaG9tZSBnYXRld2F5LiBSZWN1cnNpdmVseSBuZXN0ZWQgdHVubmVs cyB3aXRoaW4gdHVubmVscw0Kd2lsbCBiZSBhIGZhY3Qgb2YgbGlmZSwgZS5nLiwgZm9yIGFueW9u ZSB3aG8gc2V0cyB1cCBhIFZQTiBmcm9tIGEgZGV2aWNlIG9uIHRoZWlyDQpob21lIG5ldHdvcmsg dG8gdGhlaXIgY29ycG9yYXRlIG9mZmljZSBzZWN1cml0eSBnYXRld2F5LiBBbmQsIGxpbmtzIHRo YXQNCnN1cHBvcnQgIGEgZGVnZW5lcmF0ZSBNVFUgKGkuZS4sIGFueXRoaW5nIGxlc3MgdGhhbiAx NTAwKSBhbHdheXMgcHJlc2VudA0KYSBsaW1pdGluZyBmYWN0b3IgZm9yIHJlY3Vyc2lvbi4NCg0K VGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSANCg0KPiBPd2VuDQoNCg== From nobody Mon Nov 3 15:54:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32181A1AAC for ; Mon, 3 Nov 2014 15:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=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 B-SX8QsriD3V for ; Mon, 3 Nov 2014 15:54:05 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 65D021A1A9B for ; Mon, 3 Nov 2014 15:54:03 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA3NrGWW005866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 15:53:19 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA3NrGWW005866 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1415058801; bh=2L0TXuKQ8JOkCpG6K8wKDVKik5Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=03VQxFB6Uru8ykmcF7wonFZTHZyG2G+Bm+tsh3eNc5OTgyx6ZtXmkMq0xLjD8R9WL 3FpTsuLB9oOxKEdfkeNcv5GD5GGkJ0XzEOw4ai/YWrsSMw7RiY2adO4TQj4ARje1uo lh2L4HLT8mazftM6qmZ1yid3n79OOdI98y56DYTg= Content-Type: multipart/alternative; boundary="Apple-Mail=_3B1B58DD-E816-460A-9DCB-10881F37FEE9" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <54570E27.60504@network-heretics.com> Date: Mon, 3 Nov 2014 15:53:10 -0800 Message-Id: <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Nov 2014 15:53:21 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W1DpMAq7fMjkK_tTp_rtO4e_irw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 23:54:06 -0000 --Apple-Mail=_3B1B58DD-E816-460A-9DCB-10881F37FEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 2, 2014, at 9:09 PM, Keith Moore = wrote: >=20 > On 11/02/2014 11:35 AM, Metzler, Dan J wrote: >> That said, back to the original discussion, involving protocol 41, if = AT&T is truly blocking protocol 41 because they provide IPv6 native = support across the board already, that seems a lot less unreasonable. > protocol 41 isn't just IPv6 over IPv4. >=20 > Keith >=20 What else is it? GRE is Protocol 47. To the best of my knowledge, 41 is only used for 6in4 and 6to4. However, AT&T isn=E2=80=99t just blocking 41 for users that they provide = 6rd for. They are also blocking it for virtually all of their users that = don=E2=80=99t have IPv6 access. Owen --Apple-Mail=_3B1B58DD-E816-460A-9DCB-10881F37FEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 2, 2014, at 9:09 PM, Keith Moore <moore@network-heretics.com> wrote:

=20 =20
On 11/02/2014 11:35 AM, Metzler, Dan = J wrote:
That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.
protocol 41 isn't just IPv6 over IPv4.

Keith


What else is it? = GRE is Protocol 47.

To the best of my knowledge, 41 is only used for 6in4 and = 6to4.

However, = AT&T isn=E2=80=99t just blocking 41 for users that they provide 6rd = for. They are also blocking it for virtually all of their users that = don=E2=80=99t have IPv6 access.

Owen

= --Apple-Mail=_3B1B58DD-E816-460A-9DCB-10881F37FEE9-- From nobody Mon Nov 3 16:03:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF131A1AAB for ; Mon, 3 Nov 2014 16:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ek8ksMFo04r7 for ; Mon, 3 Nov 2014 16:03:23 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F761A1AB7 for ; Mon, 3 Nov 2014 16:03:23 -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 sA403M9Y014867; Mon, 3 Nov 2014 16:03:22 -0800 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA403LsJ014863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Nov 2014 16:03:21 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.26]) with mapi id 14.03.0210.002; Mon, 3 Nov 2014 16:03:20 -0800 From: "Templin, Fred L" To: Owen DeLong , Keith Moore Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP98F9x+FL/6xw7UWa0RC60gxaKpxPlWJg Date: Tue, 4 Nov 2014 00:03:21 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D783A3@XCH-BLV-504.nw.nos.boeing.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.com> In-Reply-To: <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.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_2134F8430051B64F815C691A62D9831832D783A3XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RLZu9Gpfwn2zDN4HsWDcjETeyvY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 00:03:32 -0000 --_000_2134F8430051B64F815C691A62D9831832D783A3XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aXAtcHJvdG8tNDEgaXMgYWxzbyBmb3IgNmluNiAoUkZDMjQ3MykuDQoNClRoYW5rcyDigJMgRnJl ZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPd2VuIERlTG9uZw0KU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAwMywgMjAxNCAzOjUzIFBNDQpUbzogS2VpdGggTW9vcmUNCkNjOiB2Nm9wc0Bp ZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12 Nm9wcy02dG80LXRvLWhpc3RvcmljLTA2LnR4dCAtIGFsdGVybmF0aXZlcyB0byA2dG80DQoNCg0K T24gTm92IDIsIDIwMTQsIGF0IDk6MDkgUE0sIEtlaXRoIE1vb3JlIDxtb29yZUBuZXR3b3JrLWhl cmV0aWNzLmNvbTxtYWlsdG86bW9vcmVAbmV0d29yay1oZXJldGljcy5jb20+PiB3cm90ZToNCg0K T24gMTEvMDIvMjAxNCAxMTozNSBBTSwgTWV0emxlciwgRGFuIEogd3JvdGU6DQpUaGF0IHNhaWQs IGJhY2sgdG8gdGhlIG9yaWdpbmFsIGRpc2N1c3Npb24sIGludm9sdmluZyBwcm90b2NvbCA0MSwg aWYgQVQmVCBpcyB0cnVseSBibG9ja2luZyBwcm90b2NvbCA0MSBiZWNhdXNlIHRoZXkgcHJvdmlk ZSBJUHY2IG5hdGl2ZSBzdXBwb3J0IGFjcm9zcyB0aGUgYm9hcmQgYWxyZWFkeSwgdGhhdCBzZWVt cyBhIGxvdCBsZXNzIHVucmVhc29uYWJsZS4NCnByb3RvY29sIDQxIGlzbid0IGp1c3QgSVB2NiBv dmVyIElQdjQuDQoNCktlaXRoDQoNCldoYXQgZWxzZSBpcyBpdD8gR1JFIGlzIFByb3RvY29sIDQ3 Lg0KDQpUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIDQxIGlzIG9ubHkgdXNlZCBmb3IgNmlu NCBhbmQgNnRvNC4NCg0KSG93ZXZlciwgQVQmVCBpc27igJl0IGp1c3QgYmxvY2tpbmcgNDEgZm9y IHVzZXJzIHRoYXQgdGhleSBwcm92aWRlIDZyZCBmb3IuIFRoZXkgYXJlIGFsc28gYmxvY2tpbmcg aXQgZm9yIHZpcnR1YWxseSBhbGwgb2YgdGhlaXIgdXNlcnMgdGhhdCBkb27igJl0IGhhdmUgSVB2 NiBhY2Nlc3MuDQoNCk93ZW4NCg0K --_000_2134F8430051B64F815C691A62D9831832D783A3XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlwLXByb3RvLTQxIGlzIGFsc28gZm9yIDZp bjYgKFJGQzI0NzMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIOKAkyBGcmVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk93ZW4gRGVMb25nPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgTm92ZW1iZXIgMDMsIDIwMTQgMzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gS2Vp dGggTW9vcmU8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNnRvNC10by1o aXN0b3JpYy0wNi50eHQgLSBhbHRlcm5hdGl2ZXMgdG8gNnRvNDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAyLCAyMDE0LCBhdCA5OjA5IFBN LCBLZWl0aCBNb29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3Mu Y29tIj5tb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExLzAyLzIwMTQg MTE6MzUgQU0sIE1ldHpsZXIsIERhbiBKIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGF0IHNhaWQsIGJhY2sgdG8gdGhlIG9yaWdpbmFsIGRpc2N1c3Npb24sIGludm9s dmluZyBwcm90b2NvbCA0MSwgaWYgQVQmYW1wO1QgaXMgdHJ1bHkgYmxvY2tpbmcgcHJvdG9jb2wg NDEgYmVjYXVzZSB0aGV5IHByb3ZpZGUgSVB2NiBuYXRpdmUgc3VwcG9ydCBhY3Jvc3MgdGhlDQog Ym9hcmQgYWxyZWFkeSwgdGhhdCBzZWVtcyBhIGxvdCBsZXNzIHVucmVhc29uYWJsZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnByb3RvY29sIDQxIGlzbid0IGp1c3QgSVB2NiBvdmVy IElQdjQuPGJyPg0KPGJyPg0KS2VpdGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZWxzZSBpcyBpdD8gR1JF IGlzIFByb3RvY29sIDQ3LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIDQxIGlzIG9ubHkgdXNl ZCBmb3IgNmluNCBhbmQgNnRvNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgQVQmYW1wO1QgaXNu4oCZdCBqdXN0IGJsb2NraW5n IDQxIGZvciB1c2VycyB0aGF0IHRoZXkgcHJvdmlkZSA2cmQgZm9yLiBUaGV5IGFyZSBhbHNvIGJs b2NraW5nIGl0IGZvciB2aXJ0dWFsbHkgYWxsIG9mIHRoZWlyIHVzZXJzIHRoYXQgZG9u4oCZdCBo YXZlIElQdjYgYWNjZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Pd2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D9831832D783A3XCHBLV504nwnosb_-- From nobody Mon Nov 3 16:12:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583D41A1AEF for ; Mon, 3 Nov 2014 16:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck5X0Fvcm7zU for ; Mon, 3 Nov 2014 16:12:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6941A1AA1 for ; Mon, 3 Nov 2014 16:12:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0B7FF207E0 for ; Mon, 3 Nov 2014 19:12:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 03 Nov 2014 19:12:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=pg9HspcX6avhUMqbMwIznsczmJk=; b=TcxiQK82GR5P2Kliw Muv6nCG5uO7R3pTME9ob9HkKGfpM9yhzySEEaXLJYoIpyckfssFST2yGXc1C3csD bgnSx7NTTinOjloAYbLM+OZG8+bv/85yHjOiHel4LetoMcNi/U24Rqw7xZFpzZxe 2PNTpAeo+sGn0MW/JkjO7I91L4= X-Sasl-enc: Zljax93B4fpvqd5s5JmTD021fr17BgimuI1tIaXowjaw 1415059955 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E29D06800C4; Mon, 3 Nov 2014 19:12:34 -0500 (EST) Message-ID: <545819E7.2060003@network-heretics.com> Date: Mon, 03 Nov 2014 19:12:23 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.com> In-Reply-To: <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.com> Content-Type: multipart/alternative; boundary="------------080104020301090803000602" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N7XjQX6grakjAc_3O6tBkDsS_n4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 00:12:38 -0000 This is a multi-part message in MIME format. --------------080104020301090803000602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/2014 06:53 PM, Owen DeLong wrote: > >> On Nov 2, 2014, at 9:09 PM, Keith Moore > > wrote: >> >> On 11/02/2014 11:35 AM, Metzler, Dan J wrote: >>> That said, back to the original discussion, involving protocol 41, >>> if AT&T is truly blocking protocol 41 because they provide IPv6 >>> native support across the board already, that seems a lot less >>> unreasonable. >> protocol 41 isn't just IPv6 over IPv4. >> >> Keith >> > > What else is it? GRE is Protocol 47. I thought protocol 41 was generally used for IP (of whatever version) encapsulated in IP (of whatever version). IANA's protocol number registry seems to cite RFC 2473, which is about encapsulating various kinds of things in IPv6 (though admittedly the distinction between the different registries isn't very clear). Of course 6to4, 6over4, 6in4 all use protocol 41 and all encapsulate things over IPv4. What I haven't found is a use of protocol number 41 to encapsulate IPv4 in something else, so I might have been mistaken about that. Keith --------------080104020301090803000602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/03/2014 06:53 PM, Owen DeLong wrote:

On Nov 2, 2014, at 9:09 PM, Keith Moore <moore@network-heretics.com> wrote:

On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.
protocol 41 isn't just IPv6 over IPv4.

Keith


What else is it? GRE is Protocol 47.

I thought protocol 41 was generally used for IP (of whatever version) encapsulated in IP (of whatever version).  IANA's protocol number registry seems to cite RFC 2473, which is about encapsulating various kinds of things in IPv6  (though admittedly the distinction between the different registries isn't very clear).  Of course 6to4, 6over4, 6in4 all use protocol 41 and all encapsulate things over IPv4.   What I haven't found is a use of protocol number 41 to encapsulate IPv4 in something else, so I might have been mistaken about that.

Keith

--------------080104020301090803000602-- From nobody Mon Nov 3 16:27:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BB51A1ADD for ; Mon, 3 Nov 2014 16:27: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h707FOFYtZ5q for ; Mon, 3 Nov 2014 16:27:03 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470681A1B03 for ; Mon, 3 Nov 2014 16:27:03 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 6EF8F100A3694; Tue, 4 Nov 2014 00:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415060820; bh=pX2UOIdjS/E2TpwZBEFXeRzW0U2PktnizUHAeNNL3MM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=lqWrm9iRP9INDsKnlEna3nWOBoFdxBPD14x1OpgUDbwbQ75I3+Sl1tG3k65icrmHY CT8rJoXNenF7hyx0kU0xNKfviih/qOWG2lcrn2HPQk3EV5ubU89i5+DYlUJU3ipFom JVNDFu7vQSHhBxGCgBVqv09328vQ6B0VgYdXGSFP3R2IQxRr6ogNGGll4Du0hc02gP Had8SaQA4bjtuImKSA/jTo99M9HTm1ePsEJG/WcYXxaA+B5xh+hhQEb3ceewNx5E+J SfaXX38pXZCE9wDYQRdsYPGDnYYaL1PgAfY/iRcCQgiipRczuTswB5f4fAz+CBuSR6 4/0NRtt/5BvgQ== Message-ID: <54581D51.90105@massar.ch> Date: Tue, 04 Nov 2014 01:26:57 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <72DA86C4-3EF5-4EEA-BC2D-9A121452AB0C@delong.com> <545819E7.2060003@network-heretics.com> In-Reply-To: <545819E7.2060003@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pLCZGineDqRr5eOxr9dbpSugSk8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 00:27:06 -0000 On 2014-11-04 01:12, Keith Moore wrote: > On 11/03/2014 06:53 PM, Owen DeLong wrote: >> >>> On Nov 2, 2014, at 9:09 PM, Keith Moore >> > wrote: >>> >>> On 11/02/2014 11:35 AM, Metzler, Dan J wrote: >>>> That said, back to the original discussion, involving protocol 41, >>>> if AT&T is truly blocking protocol 41 because they provide IPv6 >>>> native support across the board already, that seems a lot less >>>> unreasonable. >>> protocol 41 isn't just IPv6 over IPv4. >>> >>> Keith >>> >> >> What else is it? GRE is Protocol 47. > > I thought protocol 41 was generally used for IP (of whatever version) > encapsulated in IP (of whatever version). No. If you see a value of '41' in a "protocol" or "next header" field then it means the next header/protocol is IPv6. For IPv4 in IPv6(or something else) you would use a next header of 4. eg 4in4 would be [IPv4, protocol = 4][IPv4, protocol = TCP/UDP/etc] eg 6in4 would be [IPv4, protocol = 41][IPv6, next header = TCP/...] eg 6in6 would be [IPv6, next header = 41][IPv6, next header = TCP/...] eg 4in6 would be [IPv6, next header = 4]][IPv4, protocol = TCP/...] etc > IANA's protocol number > registry seems to cite RFC 2473, which is about encapsulating various > kinds of things in IPv6 (though admittedly the distinction between the > different registries isn't very clear). Nack. 2743 is effectively about 6in6. If you peek at: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml You'll see it points at the similar number 2473. Note that the middle two digits are swapped with the previous one, which is likely where you got that honest mistake from. And as most people call 6in4/tsp/ayiya/etc "IPv6 tunnels" 2743 does not make this terminology much easier either ;) > Of course 6to4, 6over4, 6in4 > all use protocol 41 and all encapsulate things over IPv4. Don't forget about 6rd and all other protocols, eg AYIYA who indicate a 'next header' field of 41 to indicate IPv6 packets following there. > What I > haven't found is a use of protocol number 41 to encapsulate IPv4 in > something else, so I might have been mistaken about that. Because 41 is not meant for that. You need '4' for that (RFC2003). Fun point there is that there is also 94 aka "ipip" but that is a completely different beast again that is afaik nwhere to be found how it is actually used. Oh, yes all of this is fun and confusing ;) (Not even going to GRE which uses the 802.11 'next header' numbers...) Greets, Jeroen From nobody Mon Nov 3 16:43:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6001A1B2E for ; Mon, 3 Nov 2014 16:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=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 jQhMV3rt0ZgO for ; Mon, 3 Nov 2014 16:43:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6EB1A1B2C for ; Mon, 3 Nov 2014 16:43:39 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA40dGTb009635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 16:39:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA40dGTb009635 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1415061557; bh=DoZZhkTUctYKhBg/gJwLmMNknPg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GkdmktHqgTdISqwEww9OICHaYtCG011kNMtVE9h+2J6i2vxhhSX4fNWvNH/i/01DU D1hL9J04jYcTk1B4aV/rBtlH7Rr0KM3Fly0gEF+9FuGJYXlqqKj5TNT1pPD5/Grs51 yC0XeIYZ00BVkQBGugZjWiJD+ZmUWtFiuYGDLj3Y= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <2134F8430051B64F815C691A62D9831832D78297@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 3 Nov 2014 16:39:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B414326-0ACE-4130-AEDB-8631B07FB4C1@delong.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <2134F8430051B64F815C691A62D9831832D78297@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Nov 2014 16:39:17 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FaCaqDgyWo8DPfoZK9XA6E7k5Eg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 00:43:40 -0000 > On Nov 3, 2014, at 3:11 PM, Templin, Fred L = wrote: >=20 > Hi, just a few words on this: >=20 >>>> Also, ip-proto-41 does have path MTU challenges. We all know that = PMTUD is >>>> unreliable, which means the tunnel ingress has to set a "safe" MTU = - usually to >>>> something on the order of 1480 or smaller. >>>=20 >>> This is hard to avoid. Hopefully, with IPv6 there is enough = tunneling that people will clean up their PMTUD breakage rather than let >> those with path MTUs below 1500 suffer, like what happens with IPv4. >>=20 >> I=E2=80=99ve had <1500 MTU on both IPv4 and IPv6 for most of a = decade. I ran into fairly regular problems in IPv4 until about 3 years = ago. I=E2=80=99ve >> never seen significant problems in IPv6. >=20 > Maybe, but why settle for <1500 when you can have 1500+? I don=E2=80=99t see how you plan to achieve that with a tunnel. What I = have is running code in production working on a variety of router = platforms and my ISPs are willing to support it. I know you=E2=80=99d like to see AERO replace all tunnels and more power = to you, but as a datapoint for the discussion at hand, I don=E2=80=99t = find that PMTU-D in the real world is as broken as some reports on here = would have one believe. >=20 >> I realize this isn=E2=80=99t everyone=E2=80=99s experience, but I = think for the most part unless you go specifically looking for = brokenness or live in Japan, >> IPv6 PMTU discovery mostly works. >>=20 >>> A solution could be for home gateways that terminate a tunnel to = advertise the tunnel MTU in their RAs so hosts use the tunnel >> MTU and also put that MTU in their TCP MSS. >>=20 >> I think if you just do the MSS thing, it=E2=80=99s usually adequate = in my experience. >=20 > Not all protocols include an MSS. Consider for example a tunnel that = originates > from behind the home gateway. Recursively nested tunnels within = tunnels > will be a fact of life, e.g., for anyone who sets up a VPN from a = device on their > home network to their corporate office security gateway. And, links = that > support a degenerate MTU (i.e., anything less than 1500) always = present > a limiting factor for recursion. Yes, but they seem to mostly work with the ICMP PTB messages that come = from the router in my experience. If you fail to set the MSS on the router, you get packets that seem to = fit within the MTU, but break TCP in interesting ways. Owen From nobody Mon Nov 3 17:18:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA01A1AF4 for ; Mon, 3 Nov 2014 17:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 leQk6wOZQaiJ for ; Mon, 3 Nov 2014 17:18:12 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A8A1A1B3A for ; Mon, 3 Nov 2014 17:18:11 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 7F26A100A3694; Tue, 4 Nov 2014 01:18:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415063887; bh=Zv0d8GhQo7NCplYbPN0QALjaPba3ZUZknHGw8hriGmY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Sp8R48I6uJFXVZLUAtnsoxEzB9C5Ki+PL00YONidSvQGsKXmRPxWoF5Yj3OQ/upN6 4qJceQksyqy+yIRmNXSRZa+i1kRa1lV/rwUburBLd9sCjqWz+3VjnpV/F+MYSw3CvI X3f7FW+ABQt+tyd+bhPivwHoDW63sg8gEcjacSSdqtlm97/VWN24T8PEMmt7RhpGLW QPHC9ry5kYe7IP0tBO4xJ3CVo2fz681PRWoA+FmZDoyqKqo6H9XG99hEzrG8YeADOv OAISb+XvyCcKgSIvQwjkXbt6QbJ0YzmQ6EnLXh/pK2oAYokKlF6YovlJ9F5jWQGu24 UnwI+9bbjteTw== Message-ID: <5458294D.9000502@massar.ch> Date: Tue, 04 Nov 2014 02:18:05 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Owen DeLong , Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> In-Reply-To: <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_laessmiqzZx0ZSzPhULUp91F04 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 01:18:16 -0000 [ TL;DR: Please look at TSP and the TIC + (heartbeat or AYIYA) combo ] On 2014-11-03 22:11, Owen DeLong wrote: > I won’t be in HNL, so I can’t attend the bar BoF. > >>>> I'll go one step further and say it MUST NOT be protocol 41 >>>> based. >> >>> Why not? >> >> Because you're limited to one proto 41 user behind an IPv4 address >> and thus won't work for CGN users. > > So what you’re really saying here isn’t “MUST NOT be protocol 41†so > much as “MUST BE use a known NAT-Friendly Transport Layer Protocol.†I would not make that a "MUST". I would make that 'requirement' a "should support NAT traversal". The ability to 'upgrade' to proto-41 where possible is a good thing. MTU-wise it is handy, as you can get to MTU = 1480 if lucky, but also lots of systems do hardware-accelerated proto-41 processing, while that won't happy quickly for a native protocol. Then again.... as tests with sixxsd have shown, with a relative 'current' CPU, eg my iMac with a 3.4Ghz i7 (quad-core), one can easily stuff a few gigabits of proto-41 and even AYIYA through it even though all is userspace processed in that case. The heavy part there is not the UDP actually, but the fact that AYIYA does signature checking. >>> What's wrong with explicitly configured 6in4 tunnels? >> >> I use one every day so there's a lot right with them. The trouble >> is that they involve too much configuration and aren't flexible >> enough. For instance, when I get a new IPv4 address from my ISP I >> need to go into the tunnelbroker.net web interface to update my >> tunnel endpoint. > > Sure, but a little bit of software added to your router using the API > that HE publishes for that _COULD_ actually automate that. You mean the 'standard' DynDNS API that is 'abused' for indicating a new IP endpoint? Nice trick, and an easy way to get it supported in quite a few devices. The problem with that is that most of those tools do not have a notion of what the 'current' IP is. And especially behind NATs, even 1:1 NATs they won't notice an address change. The problem with that again being that some random user that gets that IP next will be getting proto-41 packets and will go "hey, you are hacking" (we had the Dutch police on the phone because of such a complaint in 2002 ;) But more importantly that it breaks connectivity for a while. Hence why a regular heartbeat is a good idea. Interface-notifications is a separate step, but won't matter in the above 1:1 NAT example (thus where proto-41 packets will pass). AYIYA solves that by signing every packet, then even wifi/mobile roaming just works as folks have been playing with their Android phones and doing SIP calls for quite a while already. >> But like I mentioned later in my message, I think much of what's >> required can already be found in existing tunnel broker systems, >> perhaps all that's needed is to bring it all together in a way that >> allows it to be almost as easy to use as 6to4, while continuing to >> benefit from the much better reliability of explicitly created >> tunnels. You cannot make it 'as easy to use as 6to4'. Simply because to thwart abuse cases you need at minimum registration with some kind of unique token that avoids re-signups. The setups that have tried to play with anonymous connectivity tend to end up firewalling everything left and right, typically long after services have just blocked their networks for the amount of damage done by the users of such service. And as the latter is the case, the use of such a service by most people just becomes useless as they won't be able to get anywhere. Sort of the Tor effect: you anonimize, abuse gets made, you get blocked. 6to4 at least has the property that the IPv4 address of the real users is embedded and thus can be blocked individually. For tunnel broker systems, you just have to hope the provider enters stuff in WHOIS properly and/or has a proper and working abuse@ address. > Yep. > > My point is that HE has actually already built all of the hooks > necessary on their side. All that is needed is for router and/or host > vendors to write the client-side glue. Routers and vendors already implement TSP and TIC. Thus all the components are in place. Just requires HE to step up and finally implement these protocols that have been out there for a long time. I can help you with TIC if you want to :) > There is a published API for the tunnel broker. > > Admittedly, that doesn’t work for NAT or CGN users because the HE > tunnelbroker is protocol 41 based, but it does cover the vast > majority of cases. TIC can also just work for sole proto-41 if you want. For dynamic addresses just add a simple heartbeat server and you are done. Note that heartbeat signals the PoP directly, hence no need to communicate these changes all the time from a central system that can just fail, all PoPs are independent. > Do you really expect vast numbers of CGN implementations that don’t > provide native IPv6 at this point? There are various ISPs who are doing the consumer-grade NAT thing for years already. The main motivation for the existence of AYIYA was Fastweb in Italy who have been doing NAT for their users for well over 10 years now. > Most of the implementations of CGN > that I’m aware of are targeted at supporting IPv6 users that still > need IPv4 access. That is correct. They realize quite quickly that turning of or doing something funny with IPv4 like translators causes lots of helpdesk calls and thus ends up in big costs for them. Hence, doing CGN is the best way to avoid most of it. (Though lots of services completely break behind them... especially p2p stuff, and that is just in the best 'interest' for most of those ISPS...) [..context completely removed..] > That requires some form of reliable way to make sure that all return > traffic is routed back through the same gateway at the other side. Lets not go down the 'anycast' rabbit hole again. Teredo is still left doing that and the reliability/debugging problems of that and 6to4 have been demonstrated well enough. Hence, just let 1 IPv4 address talk to another 1 IPv4 address. Exactly how currently Tunnel Brokers already work: nice and simple. >> Another way to go would be to allow a few different types of >> existing tunnel mechanisms, most notably 6rd. 6rd is for ISPs. If an ISP choses to deploy 6rd they will get it to work. No changes needed anywhere. >> This would make the >> system a little more complex on the client side, but allows for >> reusing existing gateway side implementations. As 6rd uses proto-41, indeed there are no changes needed, just some deriving of tunnel endpoints based on the IP address. >> If we go down that >> route, it would be easy enough to include the option for the new >> system to simply retrieve a fixed proto 41 configuration and be >> fully compatible with existing tunnel brokers. You mean, like TSP and TIC already do and how it is already implemented in those client boxes? :) >>>> - automatically adapts to changing addresses >> >>> Harder problem to solve. I could, however, do this today with >>> some development work on an HE tunnel. Yes, please do implement TSP or TIC. You can chose between XML or simple SMTP-style line-based commands. I can help you with the latter if you want. >> Tunnel down -> reinitiate it from scratch. Why 'reinitiate'? This is what TSP does, why bother with losing those packets? >> Simple enough for the >> client. The tunnel broker would need some way to get the new client >> address, though. heartbeat + AYIYA (which has per-packet heartbeats) solve this just fine. > Actually, I think the client should expect to inform the tunnel > broker of its address change… > > 1. These are intended to be stateless tunnels, so authentication > isn’t feasible because authenticated vs. unauthenticated _IS_ state. Indeed, you need at least the 'state' of the 'user IPv4 endpoint', next to the 'configuration parameters' of 'IPv6 prefix', 'MTU' and 'password', nothing much else is needed though. > 2. The client can easily know when its address has changed. As per the above, not in all scenarios. But yes, it can try to figure it out with interface-change events and similar setups. > OTOH, > other than by address, it’s hard for the tunnel broker to know, and > if the address no arriving is unknown, virtually impossible to know > what tunnel to associate it with and update. Exactly. Hence why those packets get a proto-41 unreachable. > Currently, using existing APIs, the client, upon detecting a new > address could access and reconfigure the Tunnel Broker and the tunnel > would come back up. Or it could just send a simple heartbeat directly to the PoP and voila you got something people have been using for 10+ years already :) > I had, at one point, scripted most of this on my > site, but it was fragile because the script depended on polling my > router from a third host and then connecting to the tunnel broker > OOB. Why do that? Just put an identity in a packet, add a current timestamp (against replay attacks :) and hash that with a password. Very simply, very quick and lean, implementable on basically everything. And run that next to your proto-41 tunnel: it is called heartbeat! If you need to cross NATs: use AYIYA ;) >>>> - doesn't require ISP cooperation >> >>> Since all packet forwarding requires some level of ISP >>> cooperation, I think you need to be a little more clear about >>> your meaning here. >> >> I mean in the sense that it still works if the ISP doesn't do >> anything to help. > > Sure, on this I agree (presuming that simply forwarding packets is > within the bounds of not doing anything to help), but yes, I agree in > the context of “ISP shouldn’t have to host or participate in > configuring or provisioning tunnels or providing tunnel termination > services in order for it to workâ€. Like every Tunnel Broker in the world has been doing for years already; except that some think that proto-41 passes to every box in the world... >> It still working if the ISP goes out of its way to filter would be >> another step. And I don't think we should attempt that, as it would >> be hard to do and also because non-ISP networks such as businesses >> and universities have a reasonably legitimate reason to not want to >> have arbitrary tunnels on their networks. > > Agreed. > > Instead, we should simply attempt to destroy such ISPs through peer > pressure. ;-) That is called 'vote with your money'. People will vote, especially when they notice how thing the pipes and hardware really are that their packets are flowing through... >> Obviously we'd want those networks to offer native IPv6, but if our >> new tunnel mechanism can be terminated on the inside of such >> networks and then firewalled the same way as other traffic would >> also be a good solution. > > Ideally, yes, but doing this (firewalling tunneled traffic) in an > IPv6-ignorant network is difficult at best. Depends on who wants to do the firewalling, if it is the ISP, take the AT&T example, they filter proto-41 but forget all the other VPN protocols out there. If it is the user, they know how iptables/WindowFirewall/etc works right? >>>> - traffic flows are reasonably optimized (i.e., if ISP offers >>>> gateway service, by default, that gateway is used) >> >>> This requires some form of service discovery mechanism that can >>> somehow be aware of what ISP you are using or otherwise has some >>> mechanism for automatically interfacing with said ISPs >>> provisioning. >> >> Yes. >> >>> In the tradition of rough consensus and running code, it would be >>> great if you put forward your vision for how this would work. >> >> What I have in mind is that there is a list of gateways and users >> are connected to the gateway that serves them best, which would >> typically be their ISP's gateway if they run one. > > How would this list be maintained? What would be the bar for getting > on the list? What would be the mechanism for maintaining the list? > How would a device locate the list at bootstrap? Such a list does not work indeed, not an automatically parseable one as Tunnel Brokers have different methods anyway. AICCU still has a feature where we stuck TXT records with details of various brokers in DNS under _aiccu.sixxs.net. But most of those TBs went away and we thus emptied the list. Screenshot of the Debian edition of that still available here: http://podpora.nic.cz/files/podpora/ipv6/aiccu_installation.png Nope, Hurricane Electric was never in that list as they still do not do either TSP or TIC and without an automatic way to fetch the config, little sense to put them in there... Google is very quick to reveal the following though: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers People can go from there. Also, people who cannot find a Tunnel Broker, well, IMHO they do not need IPv6 yet. > This is a nice hand wave and I understand the general desired > outcome, but there are many devils in the details. > > That’s what I was trying to convey with the “running code†part of my > comment. Lots of the code discussed in this thread has been running for 10+ years and is actively deployed on a lot of platforms. Join the fun I would say ;) >>> I definitely think that deprecation of configured 6in4 tunnels >>> would be very premature and somewhat harmful in general. >> >> I agree; existing tunnel brokers should definitely keep doing for >> some time to come. >> >> But do you agree that the current tunnel broker system is too >> complex to serve the role that 6to4 was intended to serve? > > I’ve never really been completely clear on the intended role for 6to4 > since it so clearly missed whatever mark that was, so it’s hard to > comment authoritatively. The intended role of 6to4 was to automatically give every IPv4 endpoint (at least publicly routed ones) a IPv6 address + /48. It worked like a charm for quite a while when one was selecting the relay by hand as then you effectively had a tunnel broker setup. Then the anycast node got added and some ISPs setup an instance which was great. But then people started shoving lots of crap over it and especially those instances where some German ISP found it 'okay' for their customer to send a gigabit of spoofed 6to4 packets caused several anycast nodes to shutdown due to traffic overload which caused a domino effect and suddenly there where not many of those nodes left. > I will say that in my experience, no, most of the tunnel broker > systems are not that hard to use. What they lack is sufficient > automation to achieve the self-configuring aspects of 6to4. IMHO, > said automation could be built onto the existing services without too > much effort. What I don’t get is why none of the router vendors that > set out to do this have followed through. I think you should read the rest of this thread, lots of vendors support TSP and TIC out of the box... The problem with Tunnel Brokers then becomes getting an account and not lying at the signup or providing broken data though. >>>> The router or host, when it notices that there is no native >>>> IPv6, connects to _tunserv._tcp. or something like that >>>> and authenticates. The setup server then does a lookup of the >>>> source IPv4 address and redirects to a gateway... Which 'domain' would be used for such a setup? I've suggested this a long time ago: http://jeroen.massar.ch/archive/drafts/draft-massar-v6ops-tunneldiscovery-00.html But the discussion then concluded that it was not going anywhere as there is no way to discover them. ISPs that are not cooperating for getting IPv6 deployed won't have the record, thus leaves systems like Tunnel Brokers where the label will be easy for the user: for TIC: tic.sixxs.net (or tic.) or for TSP whatever the host of the Gateway6 box is. >>> This assumes a tremendous amount of cooperation and coordination >>> not in evidence. Who runs this central "setup server" service? >>> Why? How is it paid for? SixXS is just done for the fun of it. But yes, that costs a lot of time, and the biggest problem of that: can't help every user in the world, a day only got 24 hours... >> What I imagine is that existing cloud services would incorporate >> that, most notably Apple, Google and Microsoft, who all have shown >> various levels of interest in getting IPv6 working well. Google didn't want to go for it the last time we discussed it with them. Their biggest problem is "state". Even though there are few state variables scaling it up to Google sizes where the world can actually use it will not scale as then you need to distribute that state and do that near-instant as we are talking about packets. >> But also >> any other interested party, such as the existing tunnel brokers. >From my SixXS POV, there is nothing to be done, as we already have provided the solutions to the problems that have been listed in this thread: TIC, heartbeat & AYIYA. >> The technical part is basically running a web server and a user >> database, which doesn't cost a meaningful amount of money. And where are you going to move your packets through? :) > That depends on the level of support you want to provide to the users > when something goes horribly wrong. > > That can cost anywhere from virtually nothing to very much. Exactly. Except for a LOT of sparetime, SixXS has not cost too much for that matter; everything costing actual money has been donated. (nope, I won't calculate based on an hourly rate how much the time involved cost) Though, that is why keeping the 'fun' in it important, the moment that is gone, and there is nothing to learn anymore it will become painful. >> The harder part is the coordination, but the benefit is huge: you >> get a tunnel that's terminated as close to the user as possible >> without requiring any action from the user to accomplish this. > > I don’t think that tunnels that don’t require ANY action from the > user are a good thing, actually. I fully agree. > The user _SHOULD_ have to approve any tunnel being created at least > once, IMHO. Yep. Especially as then the user is aware that this new IPv6 thing punctures a hole in all the IPv4 firewall policies that they previously meticulously closed up. [..] >> There is no reason why one account couldn't set up multiple >> tunnels, so this shouldn't be an issue. The reason to have accounts >> at all is to be able to block them if people do bad things. Then >> you are blocked if you use the default account and the user of a >> clone of your MAC address does bad things. So set up a real account >> and your tunnel is back. > > So why not just require a real account in all cases to begin with. It > could easily be part of the router’s initial configuration wizard. > > I simply don’t see the advantage to using a MAC address as an > authentication mechanism when we can avoid all of those issues so > easily. I agree. Just let people sign up. This also makes the Tunnel Broker the point where they need to get their service and agree to their terms. No change here thus. >>> Also, ip-proto-41 does have path MTU challenges. We all know that >>> PMTUD is unreliable, which means the tunnel ingress has to set a >>> "safe" MTU - usually to something on the order of 1480 or >>> smaller. >> >> This is hard to avoid. Hopefully, with IPv6 there is enough >> tunneling that people will clean up their PMTUD breakage rather >> than let those with path MTUs below 1500 suffer, like what happens >> with IPv4. > > I’ve had <1500 MTU on both IPv4 and IPv6 for most of a decade. I ran > into fairly regular problems in IPv4 until about 3 years ago. I’ve > never seen significant problems in IPv6. Unless your name is Akamai and have random nodes b0rking: https://www.sixxs.net/forum/?msg=general-12378937 > I realize this isn’t everyone’s experience, but I think for the most > part unless you go specifically looking for brokenness or live in > Japan, IPv6 PMTU discovery mostly works. IPv6 PMTU works fine. It is broken networks that do not work fine. In the Akamai case it likely is some kind of software bug, as they know about these issues for a few years already and they have good folks. Typically though you find IPv6 PMTU issues in Enterprisy Networks where some consultant went and said "I am an IPv6 Guru, you do not need that ICMP stuff, just like IPv4". >> A solution could be for home gateways that terminate a tunnel to >> advertise the tunnel MTU in their RAs so hosts use the tunnel MTU >> and also put that MTU in their TCP MSS. > > I think if you just do the MSS thing, it’s usually adequate in my > experience. Clamping MSS is *avoiding* the issue. If you are clamping MSS then you are indicating that you have MTU issues. And you will only notice that when you start using UDP based services again... Greets, Jeroen From nobody Mon Nov 3 17:32:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D314D1A1B55 for ; Mon, 3 Nov 2014 17:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 O8OCp4RWcP9H for ; Mon, 3 Nov 2014 17:32:26 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C331A1B4E for ; Mon, 3 Nov 2014 17:32:26 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id tr6so6587147ieb.14 for ; Mon, 03 Nov 2014 17:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8UN0cDmIVNlCz/ELDHH6RFmC2wsMH+1aK0UUBXzV9tU=; b=ip6EFp85hyj7f4Ha0fhRBRLN03rqyXsKt4XfRbIZeTQtHGNWr2xTeo/7T5VTwZIPgx O3lJbgEnsgUnq1YTG4Bc30WbWC2kHoZDyGSkutj8oiFvlmTJD6llyRXNOUYgG7xC43JS xdX+WUVFt2hJjyPiNjiTLmGHVRsydZ+R0Yq1trw4cZH1MK5T+AFMHZCeLhPlaCOsoSNt hQRHIy571V75QoaWdvS0gPgRaOYUBXOZ7IhHb0kimkY2YEGsZqktzZJ3VaIobkVT72Yy yD9JUIEP31+AdgDOPl/ruHZw32FGg+YRT9Bi3HJpKPZW/YKW0ZzQqxW2F3KpZimmgnMo zVng== 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=8UN0cDmIVNlCz/ELDHH6RFmC2wsMH+1aK0UUBXzV9tU=; b=dBIAH5Nucr8wXVNgUNwnHN1nnbYQzNmJXdUzpqj2uqjKbfIZ2rQKnuTQnBAlMoha8f vU5UpdQ5IDsoEXblr/+mTFvaNCl4UqE3n0yr8r4niRNGtQZSlwd6KVL5Ghq42E0npI/V +r2TmDlsU+VAYlMTqDaA5ilUquQsieVyuM+pMLmaBtQ448GU/rg22Cb/4nzq6LtNSHh9 uQGO11LxOUtJYYryzM/bBOWL33awn+2q6moQbiWZ4cM2N+AWInMuALtsNCKicp7MaP0+ ENPOKw6mKTX//3Ac1V8K5ZdJL973Fbtwh35kwlIxw8W5hmM40M3Xa6keDUYbEE3yHBrM K27A== X-Gm-Message-State: ALoCoQmUrD4QK628tthfYc1Fa3MtniYfdhEEOUUJ4LUU1071lop1jaSTljdVP7IC9Y/GoTUP1/l4 MIME-Version: 1.0 X-Received: by 10.50.4.35 with SMTP id h3mr20370891igh.37.1415064745435; Mon, 03 Nov 2014 17:32:25 -0800 (PST) Received: by 10.64.176.203 with HTTP; Mon, 3 Nov 2014 17:32:24 -0800 (PST) Received: by 10.64.176.203 with HTTP; Mon, 3 Nov 2014 17:32:24 -0800 (PST) In-Reply-To: <54553330.9070800@gmail.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54553330.9070800@gmail.com> Date: Tue, 4 Nov 2014 10:32:24 +0900 Message-ID: From: Lorenzo Colitti To: "Brian E. Carpenter" Content-Type: multipart/alternative; boundary=001a11c3e6307c8b1b0506fe6f16 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/law_ceIpW4JHZpNQIlcmWVslI9w Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.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, 04 Nov 2014 01:32:28 -0000 --001a11c3e6307c8b1b0506fe6f16 Content-Type: text/plain; charset=UTF-8 On 1 Nov 2014 12:23 pm, "Brian E Carpenter" wrote: > > 2. Pointing a default route at a relay router is NOT RECOMMENDED. > > Hang on, which default route do you mean? There's only one default route. > Sure. But again, I think that is a restatement of what the draft > already says. The key point is that what I'm suggesting says LESS than the draft currently says, which will hopefully help escape the dozens of messages of arguments we're currently mired in. --001a11c3e6307c8b1b0506fe6f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 1 Nov 2014 12:23 pm, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> >=C2=A0 =C2=A0 2. Pointing a default route at a relay router is NOT= RECOMMENDED.
>
> Hang on, which default route do you mean?

There's only one default route.

> Sure. But again, I think that is a restatement of what = the draft
> already says.

The key point is that what I'm suggesting says LESS than= the draft currently says, which will hopefully help escape the dozens of m= essages of arguments we're currently mired in.

--001a11c3e6307c8b1b0506fe6f16-- From nobody Mon Nov 3 18:46:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB201A8732 for ; Mon, 3 Nov 2014 18:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyCAf-JRCnCt for ; Mon, 3 Nov 2014 18:46:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2FE1A1C02 for ; Mon, 3 Nov 2014 18:46:37 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 76EE420936 for ; Mon, 3 Nov 2014 21:46:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 03 Nov 2014 21:46:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type; s= smtpout; bh=log748AqwIQDy3UAcQa8XbwTmeI=; b=H/91Um0+vLC5/KIMOvLN lG3QWb+GjZ2DDJ0kIqjY9tXK5LmZaQRThzgDWCMuQw+7XwCuzHj4AaUOLtBpqv1O yx2fztwUCFOjulf8Q4KF2+D6MRsg6ARTLaRB57tqaooteDgAAzjVKOGXhcnk/RNG Y6DThsMI1XxYGRfSzSTHmeg= X-Sasl-enc: 1FS8IfZRib1xLOl1hNmllLmPmautPN6d/NFAjWX4pAzb 1415069196 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 007E56800E9; Mon, 3 Nov 2014 21:46:35 -0500 (EST) Message-ID: <54583E00.5080003@network-heretics.com> Date: Mon, 03 Nov 2014 21:46:24 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> Content-Type: multipart/alternative; boundary="------------040403060400060802080505" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6eaTboPKKoLARoukNQYAhaKm9Oc Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 02:46:38 -0000 This is a multi-part message in MIME format. --------------040403060400060802080505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/02/2014 11:35 AM, Metzler, Dan J wrote: > That said, back to the original discussion, involving protocol 41, if > AT&T is truly blocking protocol 41 because they provide IPv6 native > support across the board already, that seems a lot less unreasonable. Disagree. There are valid reasons for customers to be using protocol 41 even if they also have native IPv6 access. They might need to reliably reach 6to4 sites (i.e. without relying on someone else's relay routers), or they might need private 6in4 tunnels to other sites that don't yet have native v6 access. Carriers should forward packets, not decide what protocols their customers are supposed to use or second-guess what their customers need. Keith --------------040403060400060802080505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.
Disagree.   There are valid reasons for customers to be using protocol 41 even if they also have native IPv6 access.   They might need to reliably reach 6to4 sites (i.e. without relying on someone else's relay routers), or they might need private 6in4 tunnels to other sites that don't yet have native v6 access.

Carriers should forward packets, not decide what protocols their customers are supposed to use or second-guess what their customers need.

Keith

--------------040403060400060802080505-- From nobody Mon Nov 3 18:56:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334901A802C for ; Mon, 3 Nov 2014 18:55:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3UzEMan0Y3e7 for ; Mon, 3 Nov 2014 18:55:57 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D730B1A876E for ; Mon, 3 Nov 2014 18:55:56 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 51DA2206CB for ; Mon, 3 Nov 2014 21:55:56 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 03 Nov 2014 21:55:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Gd6bdU9ttK5FxNv5PdUYSZ raZx8=; b=S5JE64ew6/PDThKjOCmv+qGVWOIv9yj5YoO+1SagS7Nnucq7BPneXN DNiI53/IAksC+d1YNgo8pbp1aVGQYV7O+z0dXsINsbFQ9kbvMxx1IV+SWmlwg+ON cbOoFSHpxqHgJAvQUUxKwNwHmXs1dgnRTRiNmjygvovF3asrPrZlI= X-Sasl-enc: DqxAkMc5j7VPhuoJxIjCFPFaFRpb3xIXEBXHGUR+jrHN 1415069756 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id D73706800E9; Mon, 3 Nov 2014 21:55:55 -0500 (EST) Message-ID: <5458402F.7020704@network-heretics.com> Date: Mon, 03 Nov 2014 21:55:43 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <54562E86.7000208@massar.ch> <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> In-Reply-To: <6049A1FD-7514-46F4-8B50-DB0F71ACE64E@muada.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_inrR_t68W5Ac_onbBNCIrK7PUg Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 02:55:59 -0000 On 11/02/2014 10:17 AM, Iljitsch van Beijnum wrote: >> >I don't think that "replacing" 6to4 is going to bring anything useful at >> >this point in time. This "transition" game has been running for close to >> >20 years already... > I agree somewhat. But the real question is how much longer it's going to take rather than how long it's been under way already... Native IPv6 deployment is picking up speed, but on the other hand even under the most optimistic assumptions it's going to take at least another half a decade to reach ubiquity. Even if deployment gets to say 60-70% within a couple of years, I see a good chance of there being a fairly long "tail" of IPv6 deployment. Keith From nobody Mon Nov 3 19:16:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90E21A8894 for ; Mon, 3 Nov 2014 19:16:19 -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 HWUsiZkV9kfh for ; Mon, 3 Nov 2014 19:16:16 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07571A888E for ; Mon, 3 Nov 2014 19:16:16 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fa1so13517638pad.39 for ; Mon, 03 Nov 2014 19:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UuCVLjj84UQwu0IiL7XpEsRagGJW/v5eqWXtZJfTe8w=; b=msAUQ6y86lbrsp47t2ySs5WeFd6vRv0WMJr5HXhwFkUkw2Zi/PfPu5be+iwZWT7Fpl xAldMq94hG7mafHw2IuNEye+qPaV8wXHNBATsX4rxFg1OrEihkbsUdBXm2VRH4qGLYAZ rEldLBbjz32N/7eQLTk0L26WhoBZEKU4sqvVw4yci1uXjIQwwqV7HMmqBLdQlk2KQwnc 78c8cmIdqnD1cN40xZ5NC2ArbsTed4USVjjmp+svC9rW22aEiS8JkAa3LFdmqtXAeT7F 4xEfOpR7OdAUi69AwR8eBjYCGtk0yVYg6aiCO7IHHw5GGh/bRL7K3y/TKtfJpd2lSA2G fBJg== X-Received: by 10.66.124.228 with SMTP id ml4mr8061429pab.42.1415070973429; Mon, 03 Nov 2014 19:16:13 -0800 (PST) Received: from [192.168.178.23] (190.199.69.111.dynamic.snap.net.nz. [111.69.199.190]) by mx.google.com with ESMTPSA id ty8sm18592402pab.26.2014.11.03.19.16.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 19:16:12 -0800 (PST) Message-ID: <545844FA.6010206@gmail.com> Date: Tue, 04 Nov 2014 16:16:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54553330.9070800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XXGj5F384XEVG3XGMxKGVqKLOCo Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.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, 04 Nov 2014 03:16:20 -0000 On 04/11/2014 14:32, Lorenzo Colitti wrote: > On 1 Nov 2014 12:23 pm, "Brian E Carpenter" > wrote: >>> 2. Pointing a default route at a relay router is NOT RECOMMENDED. >> Hang on, which default route do you mean? > > There's only one default route. Well yes, but I can't think of a scenario where your advice makes sense. If you have an IPv4-only provider and your IPv6 connectivity is 6to4, all IPv6 packets are encapsulated in IPv4 anyway, so you aren't running any v6 routing at all. If you have an IPv6 provider, you may or may not see a route to 2002::/16; if you don't, traffic to 6to4 nodes will be sent on the IPv6 default route, and somebody downstream may or may not deliver your packets to a reverse relay. >> Sure. But again, I think that is a restatement of what the draft >> already says. > > The key point is that what I'm suggesting says LESS than the draft > currently says, which will hopefully help escape the dozens of messages of > arguments we're currently mired in. If you're repeating your view that we should only deprecate 3068 and not 3056, yes, that is the question on the table, but it's not my call, so I'm waiting to see if we can hum on this next week. Brian From nobody Mon Nov 3 19:18:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1508B1A3BA0 for ; Mon, 3 Nov 2014 19:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.115 X-Spam-Level: * X-Spam-Status: No, score=1.115 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=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 PN6lX6q6PCI6 for ; Mon, 3 Nov 2014 19:18:27 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 58CA61A3B9D for ; Mon, 3 Nov 2014 19:18:27 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sA43EQvH021842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 19:14:27 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sA43EQvH021842 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1415070867; bh=cIDdfayT/b1byNi7iy9CaZuPdeI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XK77BY/JS0fRpIy+zBBgOmwXdv52iXW8pSmxuLfSUvTSkGxV9+iV1AA4xd7bu09Pw y72tiweL4atEU2vKMPzDIdqPfE4dFiFl2L5ulSy/0HzkBY5jFPVrOgZGvcnuGjoSz/ Jr2WizxwinbJNkFZSpVfC9knyrsvSsDpuf3uaoko= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <5458294D.9000502@massar.ch> Date: Mon, 3 Nov 2014 19:14:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Nov 2014 19:14:27 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I1ec33TH2NahBjjuRtRGKwDfxjs Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 03:18:31 -0000 >>>> What's wrong with explicitly configured 6in4 tunnels? >>>=20 >>> I use one every day so there's a lot right with them. The trouble >>> is that they involve too much configuration and aren't flexible >>> enough. For instance, when I get a new IPv4 address from my ISP I >>> need to go into the tunnelbroker.net web interface to update my >>> tunnel endpoint. >>=20 >> Sure, but a little bit of software added to your router using the API >> that HE publishes for that _COULD_ actually automate that. >=20 > You mean the 'standard' DynDNS API that is 'abused' for indicating a = new > IP endpoint? Nice trick, and an easy way to get it supported in quite = a > few devices. No, I meant the HE HTTP based API for manipulating tunnel broker = directly. I admit it=E2=80=99s not well known, but it does exist. > The problem with that is that most of those tools do not have a notion > of what the 'current' IP is. And especially behind NATs, even 1:1 NATs > they won't notice an address change. That=E2=80=99s pretty easy to detect. I admit I haven=E2=80=99t done anything that attempts to do tunnels = dynamically, but I find the concept of a home router that doesn=E2=80=99t = known what its IP address is a bit strange. I can understand the CGN = case where the router doesn=E2=80=99t get a public address on the = outside, but even there, if you know your =E2=80=9Cexternal=E2=80=9D = address isn=E2=80=99t, it=E2=80=99s not hard to have logic like: if (packet_not_received_thru_tunnel_in_last_30_seconds) { replied =3D ping(remote_tunneled_interface_address) if(!replied) { reconfigure_tunnel(find_current_address()) } } If you don=E2=80=99t like 30 seconds, pick a value you=E2=80=99re = comfortable with. > The problem with that again being that some random user that gets that > IP next will be getting proto-41 packets and will go "hey, you are > hacking" (we had the Dutch police on the phone because of such a > complaint in 2002 ;) But more importantly that it breaks connectivity > for a while. That=E2=80=99s funny, but I=E2=80=99m thinking it didn=E2=80=99t take = too long to teach the reality to the police. See above, I don=E2=80=99t think it has to break connectivity for long = enough to matter all that much. > Hence why a regular heartbeat is a good idea. Interface-notifications = is > a separate step, but won't matter in the above 1:1 NAT example (thus > where proto-41 packets will pass). Regular heartbeat doesn=E2=80=99t have to be built into the protocol. = There=E2=80=99s no regular heartbeat in PPP, but thousands (if not = millions) of BGP sessions successfully fall over every day due to TCP = timeouts when PPP stops working on those links. > AYIYA solves that by signing every packet, then even wifi/mobile = roaming > just works as folks have been playing with their Android phones and > doing SIP calls for quite a while already. Tradeoff is more overhead in your packets. I=E2=80=99m not opposed to = AYIYA or whatever works, but I still don=E2=80=99t think we need a new = protocol or any real IETF work to achieve your goals. >>> But like I mentioned later in my message, I think much of what's >>> required can already be found in existing tunnel broker systems, >>> perhaps all that's needed is to bring it all together in a way that >>> allows it to be almost as easy to use as 6to4, while continuing to >>> benefit from the much better reliability of explicitly created >>> tunnels. >=20 > You cannot make it 'as easy to use as 6to4=E2=80=99. Why not? > Simply because to thwart abuse cases you need at minimum registration > with some kind of unique token that avoids re-signups. 6to4 does nothing to thwart abuse cases, so you=E2=80=99ve added a = requirement not present in the 6to4 system to begin with. In order to do that, I think the best thing is user registration with = appropriate PII. Make sure that you have a place to send the LEOs if = they abuse the system. > The setups that have tried to play with anonymous connectivity tend to > end up firewalling everything left and right, typically long after > services have just blocked their networks for the amount of damage = done > by the users of such service. I=E2=80=99m well aware of this. (Though interestingly, 6to4 seems not to = suffer from this problem somehow). > And as the latter is the case, the use of such a service by most = people > just becomes useless as they won't be able to get anywhere. Sort of = the > Tor effect: you anonimize, abuse gets made, you get blocked. Which is why a registered account makes more sense to me. However, = that=E2=80=99s just an additional half-page form in the setup wizard on = the box. No, it=E2=80=99s not as easy as 6to4, but neither is anything = else that isn=E2=80=99t anonymous on some level. > 6to4 at least has the property that the IPv4 address of the real users > is embedded and thus can be blocked individually. Well, you could create a mapping and open up lookups along the same = lines=E2=80=A6 Each unique IP that has a registered tunnel is mapped to a = 16-bit number. The same 16 bits serves as the network number (allocate a /32 to = the tunnel broker) If you need to support more than 65,536 tunnelbroker users, get = another /32. Then, provide a map where people can query a /48 prefix number = and get back the real IPv4 address. Now you have effectively the same capabilities as 6to4 in terms = of abuse prevention > For tunnel broker systems, you just have to hope the provider enters > stuff in WHOIS properly and/or has a proper and working abuse@ = address. More accurately, if you=E2=80=99re providing tunnel broker services, = it=E2=80=99s important that you be responsive to abuse complaints and have some way to track abuse back = to the original user. HE does that all the time. I presume the other reputable tunnel brokers (SIXXS, GOGO) do as well. >> Yep. >>=20 >> My point is that HE has actually already built all of the hooks >> necessary on their side. All that is needed is for router and/or host >> vendors to write the client-side glue. >=20 > Routers and vendors already implement TSP and TIC. Thus all the > components are in place. >=20 > Just requires HE to step up and finally implement these protocols that > have been out there for a long time. I don=E2=80=99t think that=E2=80=99s likely. > I can help you with TIC if you want to :) Apparently you haven=E2=80=99t heard=E2=80=A6 I=E2=80=99m no longer with = HE. I still use an HE tunnel for some of my IPv6 upstream connectivity, but I=E2=80=99m an ordinary = user like anyone else. >> There is a published API for the tunnel broker. >>=20 >> Admittedly, that doesn=E2=80=99t work for NAT or CGN users because = the HE >> tunnelbroker is protocol 41 based, but it does cover the vast >> majority of cases. >=20 > TIC can also just work for sole proto-41 if you want. >=20 > For dynamic addresses just add a simple heartbeat server and you are > done. Note that heartbeat signals the PoP directly, hence no need to > communicate these changes all the time from a central system that can > just fail, all PoPs are independent. There are a number of reasons I don=E2=80=99t think that=E2=80=99s = always desirable from the perspective of the tunnel broker provider. >> Do you really expect vast numbers of CGN implementations that don=E2=80= =99t >> provide native IPv6 at this point? >=20 > There are various ISPs who are doing the consumer-grade NAT thing for > years already. >=20 > The main motivation for the existence of AYIYA was Fastweb in Italy = who > have been doing NAT for their users for well over 10 years now. That=E2=80=99s just sad. They aren=E2=80=99t doing IPv6? >> Most of the implementations of CGN >> that I=E2=80=99m aware of are targeted at supporting IPv6 users that = still >> need IPv4 access. >=20 > That is correct. They realize quite quickly that turning of or doing > something funny with IPv4 like translators causes lots of helpdesk = calls > and thus ends up in big costs for them. >=20 > Hence, doing CGN is the best way to avoid most of it. My point is that if they are doing native IPv6 + CGN/v4, then their = users don=E2=80=99t really need a 6over4 mechanism or tunnel broker. What am I missing? > (Though lots of services completely break behind them... especially = p2p > stuff, and that is just in the best 'interest' for most of those = ISPS=E2=80=A6) Don=E2=80=99t get me started, but it=E2=80=99s not really the topic of = this thread. > [..context completely removed..] >> That requires some form of reliable way to make sure that all return >> traffic is routed back through the same gateway at the other side. >=20 > Lets not go down the 'anycast' rabbit hole again. I=E2=80=99m not talking about any cast, I=E2=80=99m talking about truly = stateless routers and the potential of more than one tunnel serving the = same end user. > Teredo is still left doing that and the reliability/debugging problems > of that and 6to4 have been demonstrated well enough. Yep=E2=80=A6 I wasn=E2=80=99t disagreeing with this. > Hence, just let 1 IPv4 address talk to another 1 IPv4 address. Agreed, but what you=E2=80=99re talking about would require the ingress = traffic to always traverse the same tunnel as the egress traffic. I=E2=80=99= m calling that broken. > Exactly how currently Tunnel Brokers already work: nice and simple. I can send a packet out through my HE tunnel and get the answer back = through my tunnels to Layer 42 and everything is just fine. In your = model, I believe that would have broken. >> Actually, I think the client should expect to inform the tunnel >> broker of its address change=E2=80=A6 >>=20 >> 1. These are intended to be stateless tunnels, so authentication >> isn=E2=80=99t feasible because authenticated vs. unauthenticated _IS_ = state.=20 >=20 > Indeed, you need at least the 'state' of the 'user IPv4 endpoint', = next > to the 'configuration parameters' of 'IPv6 prefix', 'MTU' and > 'password', nothing much else is needed though. Those are configuration parameters, not state. If you are not = maintaining some form of state for authenticated vs. unauthenticated (persistent TCP session, for example), then you have to carry an authentication token in every packet. Since one of the complaints here is MTU reduction, it = seems to me that adding overhead to the packet is contrary to the desired = result. Hence, eliminating the authenticated vs. unauthenticated state seems desirable. Instead, provide a stateful authenticated way to configure =E2=80=9Cend-point address=E2=80=9D out of band from the tunnel and let = the tunnel be stateless thereafter. >> 2. The client can easily know when its address has changed. >=20 > As per the above, not in all scenarios. But yes, it can try to figure = it > out with interface-change events and similar setups. Again, I consider CGN clients without IPv6 connectivity to be more of a corner case than a core solution space. >> OTOH, >> other than by address, it=E2=80=99s hard for the tunnel broker to = know, and >> if the address no arriving is unknown, virtually impossible to know >> what tunnel to associate it with and update. >=20 > Exactly. Hence why those packets get a proto-41 unreachable. Which should tell the client it=E2=80=99s time to renegotiate its = address if it hasn=E2=80=99t figured it out yet. >> Currently, using existing APIs, the client, upon detecting a new >> address could access and reconfigure the Tunnel Broker and the tunnel >> would come back up. >=20 > Or it could just send a simple heartbeat directly to the PoP and voila > you got something people have been using for 10+ years already :) Again, at the price of MTU reduction and a stateful tunnel. >> I had, at one point, scripted most of this on my >> site, but it was fragile because the script depended on polling my >> router from a third host and then connecting to the tunnel broker >> OOB. >=20 > Why do that? Just put an identity in a packet, add a current timestamp > (against replay attacks :) and hash that with a password. Because I don=E2=80=99t control the software at the other end and this = was a solution I could apply on the client side of the tunnel. > Very simply, very quick and lean, implementable on basically = everything. Virtually anything you can think of is =E2=80=9Cimplementable on = basically everything=E2=80=9D if you=E2=80=99re willing to apply enough resources to the problem. I = think someone once ported an IPv4 stack to a Commodore Pet. It took 47 of the 48k of = RAM in the machine, so you couldn=E2=80=99t actually _DO_ anything more = sophisticated than TELNET with it, but it was =E2=80=9Cimplemented=E2=80=9D. However, the solution you propose requires modifying software on the = server side as well as the client in a coordinated manner. OTOH, what I = proposed could be implemented 100% client side which has significant advantages when it comes to adoption in an environment where the client is = motivated and the tunnel broker is providing a free service to the community. > And run that next to your proto-41 tunnel: it is called heartbeat! I have not had the best experiences with OOB heartbeats. YMMV. > Like every Tunnel Broker in the world has been doing for years = already; > except that some think that proto-41 passes to every box in the = world=E2=80=A6 Not every box in the world, just every box on the actual internet. >>> It still working if the ISP goes out of its way to filter would be >>> another step. And I don't think we should attempt that, as it would >>> be hard to do and also because non-ISP networks such as businesses >>> and universities have a reasonably legitimate reason to not want to >>> have arbitrary tunnels on their networks. >>=20 >> Agreed. >>=20 >> Instead, we should simply attempt to destroy such ISPs through peer >> pressure. ;-) >=20 > That is called 'vote with your money'. People will vote, especially = when > they notice how thing the pipes and hardware really are that their > packets are flowing through=E2=80=A6 Problem is there are many areas in the US where you get your residential internet from AT&T or you don=E2=80=99t get residential internet. Oligopolies and monopolies make it very difficult to vote with your = money in a meaningful way. FWIW, I have voted with my feet and do not subscribe to any AT&T = residential services any more. > Depends on who wants to do the firewalling, if it is the ISP, take the > AT&T example, they filter proto-41 but forget all the other VPN > protocols out there. Ah=E2=80=A6 Here=E2=80=99s the worst of the AT&T situation=E2=80=A6 They aren=E2=80=99t doing it for security or for any sort of protocol = inspection or such. They blocked external protocol 41 for ALL of their customers when they = started turning up 6rd for SOME of their customers because they don=E2=80=99t = want to risk certain forms of customers circumventing their 6rd service. > If it is the user, they know how iptables/WindowFirewall/etc works = right? ROFLMAO=E2=80=A6 Generally, no. At least not in my experience. >>>>> - traffic flows are reasonably optimized (i.e., if ISP offers >>>>> gateway service, by default, that gateway is used) >>>=20 >>>> This requires some form of service discovery mechanism that can >>>> somehow be aware of what ISP you are using or otherwise has some >>>> mechanism for automatically interfacing with said ISPs >>>> provisioning. >>>=20 >>> Yes. >>>=20 >>>> In the tradition of rough consensus and running code, it would be >>>> great if you put forward your vision for how this would work. >>>=20 >>> What I have in mind is that there is a list of gateways and users >>> are connected to the gateway that serves them best, which would >>> typically be their ISP's gateway if they run one. >>=20 >> How would this list be maintained? What would be the bar for getting >> on the list? What would be the mechanism for maintaining the list? >> How would a device locate the list at bootstrap? >=20 > Such a list does not work indeed, not an automatically parseable one = as > Tunnel Brokers have different methods anyway. >=20 > AICCU still has a feature where we stuck TXT records with details of > various brokers in DNS under _aiccu.sixxs.net. But most of those TBs > went away and we thus emptied the list. >=20 > Screenshot of the Debian edition of that still available here: > http://podpora.nic.cz/files/podpora/ipv6/aiccu_installation.png >=20 > Nope, Hurricane Electric was never in that list as they still do not = do > either TSP or TIC and without an automatic way to fetch the config, > little sense to put them in there... >=20 > Google is very quick to reveal the following though: >=20 > https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers >=20 > People can go from there. >=20 > Also, people who cannot find a Tunnel Broker, well, IMHO they do not > need IPv6 yet. But you=E2=80=99ve once again left the realm of =E2=80=9Cas easy to use = as 6to4=E2=80=9D. Make up your mind. You are vacillating wildly between =E2=80=9Ceasy to = use=E2=80=9D and =E2=80=9Cyou must be this tall to ride=E2=80=9D and I=E2=80=99m getting = whiplash trying to keep up. >> This is a nice hand wave and I understand the general desired >> outcome, but there are many devils in the details. >>=20 >> That=E2=80=99s what I was trying to convey with the =E2=80=9Crunning = code=E2=80=9D part of my >> comment. >=20 > Lots of the code discussed in this thread has been running for 10+ = years > and is actively deployed on a lot of platforms. >=20 > Join the fun I would say ;) My point all along has been that there=E2=80=99s running code to do what = you want (or at least come very close to it). There=E2=80=99s nothing for the = IETF to do here. There=E2=80=99s some middleware that is needed/missing. > The intended role of 6to4 was to automatically give every IPv4 = endpoint > (at least publicly routed ones) a IPv6 address + /48. >=20 > It worked like a charm for quite a while when one was selecting the > relay by hand as then you effectively had a tunnel broker setup. >=20 > Then the anycast node got added and some ISPs setup an instance which > was great. But then people started shoving lots of crap over it and > especially those instances where some German ISP found it 'okay' for > their customer to send a gigabit of spoofed 6to4 packets caused = several > anycast nodes to shutdown due to traffic overload which caused a = domino > effect and suddenly there where not many of those nodes left. TTBOMK, the HE and Comcast nodes are still up and running. >>>> This assumes a tremendous amount of cooperation and coordination >>>> not in evidence. Who runs this central "setup server" service? >>>> Why? How is it paid for? >=20 > SixXS is just done for the fun of it. But yes, that costs a lot of = time, > and the biggest problem of that: can't help every user in the world, a > day only got 24 hours=E2=80=A6 Right=E2=80=A6 But if you want router vendors to start putting this in = their boxes, you probably need something with more assurance that it will keep going for at least some reasonable amount of time. Don=E2=80=99t get me wrong, I think SIXXS is doing cool stuff and doing = it well. I think they will be around for quite a while. But I wouldn=E2=80=99t be = able to tell a product marketing manager to depend on it with a straight face. >> That depends on the level of support you want to provide to the users >> when something goes horribly wrong. >>=20 >> That can cost anywhere from virtually nothing to very much. >=20 > Exactly. Except for a LOT of sparetime, SixXS has not cost too much = for > that matter; everything costing actual money has been donated. (nope, = I > won't calculate based on an hourly rate how much the time involved = cost) >=20 > Though, that is why keeping the 'fun' in it important, the moment that > is gone, and there is nothing to learn anymore it will become painful. Yep. Further, the moment it becomes painful, it will implode. >> I realize this isn=E2=80=99t everyone=E2=80=99s experience, but I = think for the most >> part unless you go specifically looking for brokenness or live in >> Japan, IPv6 PMTU discovery mostly works. >=20 > IPv6 PMTU works fine. It is broken networks that do not work fine. Now we=E2=80=99re dividing rabbits unnecessarily. I meant from a real-world user perspective, IPv6 PMTU discovery works in = almost every circumstance and I have encountered few reachability problems as a = result. Other than people who go specifically looking for broken networks (a = worth while endeavor) or people subject to the various intricacies of IPv6 = implementations in Japan, there aren=E2=80=99t that many broken networks out there from an = IPv6 PMTU-D perspective. >>> A solution could be for home gateways that terminate a tunnel to >>> advertise the tunnel MTU in their RAs so hosts use the tunnel MTU >>> and also put that MTU in their TCP MSS. >>=20 >> I think if you just do the MSS thing, it=E2=80=99s usually adequate = in my >> experience. >=20 > Clamping MSS is *avoiding* the issue. >=20 > If you are clamping MSS then you are indicating that you have MTU = issues. On my Juniper, if I didn=E2=80=99t clamp MSS to an appropriate value to = go with the tunnel MTU, then non-TCP packets worked fine, but TCP = sessions would hang. When I clamped the MSS value, it resolved the TCP = problems. I can now reach TCP, UDP, and ICMP services with packets = larger than 1500 in both directions with no issues. For some reason, changing the interface MTU on a Juniper doesn=E2=80=99t = seem to clamp the MSS the way one would expect it to, so that has to be = done manually. (At least in the release of JunOS that I am running). > And you will only notice that when you start using UDP based services > again=E2=80=A6 I use many UDP based services every day. Perhaps, instead of assuming that you know better than everyone else, = read what they write and consider the full context. I don=E2=80=99t change the MTU in my RAs because I have a full 1500 = octet MTU on all my LAN segments and that works just fine. I do have a = smaller MTU on my tunnel interfaces because they have to be encapsulated = and the encapsulated packets then traverse networks with 1500 octet = MTUs. The TCP MSS configuration value is box-wide and there are two places = where it might need to be set. system->internet-options->tcp-mss and security->flow->tcp-mss Owen From nobody Mon Nov 3 19:38:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C061A212A for ; Mon, 3 Nov 2014 19:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 t3uWRPxi1V4g for ; Mon, 3 Nov 2014 19:38:41 -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 A426C1A1A91 for ; Mon, 3 Nov 2014 19:38:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOJ57396; Tue, 04 Nov 2014 03:38:38 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Nov 2014 03:38:37 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 11:38:33 +0800 From: "Liubing (Leo)" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w7ok2AgAHqGMD//+BHgIAHXHqwgAG/4YCAAHaaAIAA5awAgAG3aFD///MqgIAGTjgQ Date: Tue, 4 Nov 2014 03:38:32 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589E402A@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.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.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FXyCXJB4N52I13mcDR6_8YXrQ-k Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem 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, 04 Nov 2014 03:38:43 -0000 SGkgQW5kcmV3LA0KDQo+ID4+IFdvdWxkIGJlIHN0aWxsIGludGVyZXN0aW5nIHRvIGhlYXIgeW91 ciBvcGluaW9uIGFib3V0IHJmYzYxMDYuDQo+ID4gW0JpbmddIFRoaXMgaXMgaW5kZWVkIGFuIGlz c3VlLiBUaGVyZSB3ZXJlIHNvbWUgcGVvcGxlIGFsc28gcmFpc2VkDQo+ID4gdGhpcyBwcm9ibGVt IGJlZm9yZS4gV2UndmUgY2FwdHVyZWQgdGhlIHByb2JsZW0gaW4gdGhlIEd1aWRhbmNlIGRyYWZ0 DQo+ID4gKHNlZQ0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtdjZv cHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNlLTAzI3MNCj4gPiBlY3Rpb24tMi4yLjMsDQo+ID4gdGhl IGxhc3QgYnVsbGV0KS4NCj4gDQo+IG9rLCB0aGFua3MgZm9yIHRoZSBsaW5rISBvbiB0aGF0IG9u ZSwgbWlnaHQgYmUgdXNlZnVsIHRvIGFkZCBhbiBleHBsaWNpdA0KPiByZWZlcmVuY2UgdG8gUkZD NjEwNiBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNCltCaW5nXSBPaywgdGhhbmtzIGZvciBy ZW1pbmRpbmcuDQoNCg0KPiA+IEZvciB0aGUgUFMgZHJhZnQsIGl0IGlzIG1vc3RseSByZWdhcmRp bmcgdG8gdGhlIGludGVyYWN0aW9uIGJldHdlZW4NCj4gPiB0d28gcHJvdG9jb2xzIChESENQdjYv U0xBQUMpLiBBbHRob3VnaCB0aGUgdHdvIHByb3RvY29scyBib3RoIGhhdmUgdGhlDQo+ID4gRE5T IG9wdGlvbiwgdGhleSBhcmUgc2VwYXJhdGUgaW4gcHJvdG9jb2wgbGV2ZWwuIFNvIHdlIG9ubHkg aW5jbHVkZQ0KPiA+IHRoaXMgaXNzdWUgaW4gdGhlIEd1aWRhbmNlIGRyYWZ0Lg0KPiA+IFRoYXQn cyBteSBjb25zaWRlcmF0aW9uLCBidXQgSSdkIGxpa2UgdG8gaGVhciB5b3Vycy4NCj4gDQo+IFRo ZSBkcmFmdCBoaWdobGlnaHRzIHRoZSBsZXNzIGNvbW1vbiBzY2VuYXJpb3Mgd2l0aCB2YXJpb3Vz IHZhbHVlcyBvZiBmbGFncyBpbg0KPiB0aGUgUkEgYW5kIHRoZWlyIHRyYW5zaXRpb25zIC0gYW5k IHRoZSBiZWhhdmlvciBvZiBob3N0cyBkdXJpbmcgdGhlc2UNCj4gc2NlbmFyaW9zLg0KPiANCj4g VG8gbWUsIHRoZSBSRkM2MTA2L0RIQ1B2NiBpbnRlcmFjdGlvbiB3b3VsZCBmYWxsIGludG8gdGhl IHNhbWUgYnVja2V0LA0KPiBmcm9tIHRoZSBwcmFjdGljYWwgYWRtaW5pc3RyYXRpb24gcGVyc3Bl Y3RpdmUuDQo+IA0KPiBUaGUgcXVlc3Rpb25zIHRoYXQgcG9wIHVwIGFyZSBsaWtlOiBXaGF0IGRv IHRoZSBob3N0cyBkbyBpZiBSRE5TUyBpcyB3aXRoaW4NCj4gdGhlIFJBIGJ1dCB0aGUgIk8iIGZs YWcgaXMgc2V0ID8gRG8gdGhlIGhvc3RzIGtlZXAgdGhlaXIgRE5TIGluZm9ybWF0aW9uIGlmIHdl DQo+IHN3aXRjaCB0aGUgc3RhdGVsZXNzIERIQ1B2NiBvZmYsICB1c2Ugb25seSB0aGUgUkROU1Mg PyBJZiBJIHdhbnQgdG8NCj4gbWF4aW1pemUgdGhlIGNoYW5jZXMgb2YgZGV2aWNlcyB3b3JraW5n LCBkbyBJIHVzZSBSRE5TUywgb3Igc3RhdGVsZXNzDQo+IERIQ1B2Niwgb3IgYm90aCA/IFRoZSBt ZW50aW9uIGluIFNMQUFDIGd1aWRhbmNlIGRvY3VtZW50IGp1c3Qgc2F5cyB0aGF0DQo+IHRoZSBo b3N0IHdvdWxkIGdldCBjb25mdXNlZCBpZiBkaWZmZXJlbnQgaW5mb3JtYXRpb24gZ2V0cyBzZW50 LCBpcyB0aGF0IHRoZQ0KPiBvbmx5IHNjZW5hcmlvID8gKEkgZGlkIG5vdCB0ZXN0IGV4dGVuc2l2 ZWx5IG15c2VsZiwgc28gYXNraW5nIGlmIHlvdSBoYXZlIG1vcmUNCj4gaW5mbykuDQo+IA0KPiBU aGVyZSBpcyBkcmFmdC1nb250LTZtYW4tc2xhYWMtZG5zLWNvbmZpZy1pc3N1ZXMgdGhhdCB0YWxr cyBhYm91dCB0aGUgUkROU1MNCj4gc3BlY2lmaWMgaXNzdWVzLCBhbmQgSSBkbyBub3Qga25vdyB3 aGV0aGVyIFJETlNTK0RIQ1B2NiBpbnRlcmFjdGlvbiBoYXMNCj4ganVzdCBub3QgYmVlbiB0ZXN0 ZWQgb3IgZG9lcyBub3QgaGF2ZSBhbnkgaXNzdWVzLg0KPiANCj4gTm93LCBvZiBjb3Vyc2UgaXQg aXMgYSBsb3Qgb2YgYWRkaXRpb25hbCB0ZXN0aW5nIHdvcmssIHNvIGFkZGluZyBhbnl0aGluZyBs aWtlDQo+IHRoYXQgaW50byB0aGUgZG9jdW1lbnQgd291bGQgYmUgY29udGluZ2VudCBvbiBtb3Jl IHBhcnRpY2lwYW50cyBvZiBXRw0KPiBzYXlpbmcgaXQgaXMgYSB1c2VmdWwgaWRlYSB2cy4gc2hp cHBpbmcgdGhlIGRvY3VtZW50IGFzIGlzLg0KDQpbQmluZ10gVGhhbmtzIGZvciBleHBsYWluaW5n IHRoZSBSRE5TUy9ESENQdjYgY2FzZXMuIFRoYXQgbWFrZXMgbWUgcmVhbGl6ZSB0aGVyZSBtaWdo dCBiZSBpbXBsaWNpdCBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSB0d28gcHJvdG9jb2xzIG9uIERO UyBjb25maWd1cmF0aW9uLiBQZXJzb25hbGx5LCBJIHRoaW5rIGl0J3MgaW50ZXJlc3RpbmcgYW5k IHdvcnRoIG1vcmUgdGVzdGluZy4gDQpGb3IgYWRkaW5nIHRoZXNlIHN0dWZmIGludG8gdGhlIGRv Y3VtZW50LCBJIHRoaW5rIGl0IG1pZ2h0IGRlcGVuZCBvbiB3aGF0IHdvdWxkIGJlIGZvdW5kIGlu IHRlc3RpbmcgYW5kIEkgYWxzbyB3b3VsZCBsaWtlIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBmcm9t IHRoZSBXRyBpbiB0aGUgbWVldGluZy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+IC0tYQ0K PiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBCaW5nDQo+ID4NCj4gPj4gLS1hDQo+ID4+ DQo+ID4+ID4NCj4gPj4gPiAgIEJyaWFuDQo+ID4+ID4NCj4gPj4gPg0KPiA+DQo= From nobody Tue Nov 4 04:49:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8D1A00F4 for ; Tue, 4 Nov 2014 04:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5rYm2g8Vujf for ; Tue, 4 Nov 2014 04:49:23 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032111A1B07 for ; Tue, 4 Nov 2014 04:49:20 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 06:49:18 -0600 From: "Metzler, Dan J" To: Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEIAAb7GA///B4hCAAoRIgIAAUB2AgAKFvYD//7DIMA== Date: Tue, 4 Nov 2014 12:49:18 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DECF421@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CR_2PhizMas_Q2UVQj0NBecrf_w Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 12:49:26 -0000 V2VsbCwgSSBkb24ndCB3YW50IHRvIHNwZW5kIHRvbyBtdWNoIHRpbWUgc2lkZXRyYWNrZWQgb24g dGhpcyBpc3N1ZSwgYnV0Li4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogT3dlbiBEZUxvbmcgW21haWx0bzpvd2VuQGRlbG9uZy5jb21dDQo+IFNlbnQ6IE1vbmRheSwg Tm92ZW1iZXIgMywgMjAxNCAzOjIwIFBNDQo+IFRvOiBNZXR6bGVyLCBEYW4gSg0KPiBDYzogS2Vp dGggTW9vcmU7IEFsZXhhbmRydSBQZXRyZXNjdTsgQnJpYW4gRSBDYXJwZW50ZXI7IHY2b3BzQGll dGYub3JnIFdHDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt djZvcHMtNnRvNC10by1oaXN0b3JpYy0wNi50eHQgLQ0KPiBhbHRlcm5hdGl2ZXMgdG8gNnRvNA0K PiANCj4gSSB3b3VsZCBhcmd1ZSB0aGF0IDZyZCwgQ0dOLCBvciBOQVQ2NCBzaG91bGQgbW92ZSB5 b3UgaW50byBhIOKAnELigJ0gYXQgYmVzdA0KPiBmb3Igc3RhcnRlcnMuDQoNCldlbGwsIG1heWJl LCBidXQgb25seSBpZiBzb21lIGtpbmQgb2Ygc3RhbmRhcmQgaXMgZGVmaW5lZCBmb3IgIkxldmVs IEIgSW50ZXJuZXQgQWNjZXNzIiBhbmQgYSAiTGV2ZWwgQSBJbnRlcm5ldCBBY2Nlc3MiLCB3aGlj aCBjb3VsZCBhdCBzb21lIHRpbWUgYmUgb2Jzb2xldGVkIGJ5IGEgbmV3IHNldCBvZiBzdGFuZGFy ZHMgZm9yIGludGVybmV0IGFjY2VzcyBkb3duIHRoZSByb2FkLiAgUmlnaHQgbm93IHRoZSBzdGF0 ZW1lbnQgaXMganVzdCBtZWFuaW5nbGVzcyBiZWNhdXNlIElFVEYgaXNuJ3QgZGVmaW5pbmcgdGhv c2Ugc2VydmljZSBhcmNoaXRlY3R1cmVzLg0KDQo+IA0KPiBGdXJ0aGVyLCBJIGRvbuKAmXQgdGhp bmsgdGhhdCBtYWtpbmcgbWFya2V0IGp1ZGdtZW50cyBvZiBwYXJ0aWN1bGFyIGNhcnJpZXJzIGlz DQo+IHdpdGhpbiB0aGUgY2hhcnRlciBvZiB0aGUgSUVURi4gVGhpcyBtb3ZlcyBvdXQgb2YgdGhl IHJlYWxtIG9mIHRlY2huaWNhbA0KPiBzdGFuZGFyZHMgaW50byBwcm9kdWN0IGNvbXBhcmlzb24g YW5kIEkgd291bGQgZXhwZWN0IHN1YnN0YW50aWFsIGJhY2tsYXNoDQo+IGFnYWluc3QgdGhlIElF VEYgYXR0ZW1wdGluZyB0byB0YWtlIG9uIHRoYXQgcm9sZS4NCg0KSSBhYnNvbHV0ZWx5IDEwMCUg YWdyZWUgdGhhdCBtYWtpbmcgbWFya2V0IGp1ZGdtZW50cyBvZiBwYXJ0aWN1bGFyIGNhcnJpZXJz IGlzIG5vdCBzb21ldGhpbmcgZm9yIElFVEYgdG8gZ2V0IGludG8uICBIb3dldmVyLCB0byBiZSBm YWlyLCBkZWZpbmluZyBzdGFuZGFyZHMgZm9yIGJhc2ljIHNlcnZpY2UgbGV2ZWxzIGlzIG5vdCBh IG1hcmtldCBqdWRnbWVudCwgbm9yIGlzIGl0IGEgcHJvZHVjdCBjb21wYXJpc29uLiAgDQoNCkl0 J3Mgc2ltcGx5IGxheWluZyBvdXQgYSBzZXQgb2Ygc3RhbmRhcmRzIGZvciBjbGFzc2VzIG9mIHNl cnZpY2UuICBObyBtZW50aW9uIG9yIGp1ZGdtZW50IG9mIGFueSBzcGVjaWZpYyBjb21wYW55IHdv dWxkIGJlIGludm9sdmVkLiAgSWYgYSBjb21wYW55IHdhbnRzIHRvIG9mZmVyIGEgY2xhc3Mgb2Yg c2VydmljZSBzdWNoIGFzIEZ1bGwgSW50ZXJuZXQgQWNjZXNzIGF0ICJMZXZlbCBBIiwgb3Igd2hh dGV2ZXIgaXQncyBjYWxsZWQsIGF0IHNvbWUgcG9pbnQsIHRoYXQgaGFzIHRvIGluY2x1ZGUgc29t ZSBmb3JtIG9mIElQdjYgYWNjZXNzOyB3aGV0aGVyIGl0IGJlIDZyZCBvciBuYXRpdmUgSVB2Ni4g IFRvZGF5IHRoYXQgbWF5IGJlIExldmVsIEEuICBUb21vcnJvdyBhIG5ldyBzdGFuZGFyZCBtYXkg bWVhbiB0aGF0IDZyZCBpcyBMZXZlbCBCIEludGVybmV0IEFjY2VzcywgYW5kIExldmVsIEEgcmVx dWlyZXMgbmF0aXZlIElQdjYuICBXaGF0ZXZlciB0aGV5IGNob29zZSB0byBpbXBsZW1lbnQsIHRo ZSBjb21wYW55IGNhbiBhZHZlcnRpc2UgdGhlIHR5cGUgb2Ygc2VydmljZSB0aGV5IG9mZmVyLg0K Tm8gY29tcGFueSBpcyByZXF1aXJlZCB0byBpbXBsZW1lbnQgTGV2ZWwgQSBmdW5jdGlvbmFsaXR5 LCBidXQgYXQgbGVhc3QgdGhleSB3b3VsZCBrbm93IHdoYXQgaXMgcmVxdWlyZWQgdG8gYWNoaWV2 ZSBpdC4NCk5vIGN1c3RvbWVyIGlzIHJlcXVpcmVkIHRvIGJ1eSBMZXZlbCBBIGZ1bmN0aW9uYWxp dHksIGJ1dCBhdCBsZWFzdCB0aGV5IHdvdWxkIGtub3cgd2hhdCB0byBleHBlY3QgZnJvbSBMZXZl bCBDIGlmIHRoZXkgYnV5IHRoYXQgaW5zdGVhZC4NCg0KPiANCj4gSXQgbWlnaHQgYmUgc29tZXRo aW5nIE5BTk9HIG9yIElPTCBvciBJU09DIG9yIHNvbWUgb3RoZXIgZ3JvdXAgY291bGQgdGFrZQ0K PiBvbiwgYnV0IEkgY2Fu4oCZdCBzZWUgdGhpcyBmaXR0aW5nIGluIHRoZSBJRVRGIGNoYXJ0ZXIu DQoNCldlbGwsIEkgaGF2ZSBhIGRpZmZlcmVudCBvcGluaW9uLCBidXQgdGhhdCdzIG9rLiAgSUVU RiBpcyByZXNwb25zaWJsZSBmb3IgSVB2NCBhbmQgSVB2Ni4gIEl0IG1ha2VzIHNlbnNlIHRoYXQg dGhleSBzaG91bGQgYWxzbyBiZSByZXNwb25zaWJsZSBmb3IgZGVzY3JpYmluZyB0aGUgY29udGV4 dHMgdW5kZXIgd2hpY2ggdGhvc2UgYXJlIGRlc2lnbmVkIGJlIHVzZWQsIGFuZCB0aGUgc2FtZSBn b2VzIGZvciB0aGUgdmFyaW91cyB0cmFuc2l0aW9uYWwgbWVjaGFuaXNtcyB0aGF0IGNhbiBoZWxw IG9uZSBnZXQgZnJvbSBJUHY0IHRvIElQdjYuDQoNCkkgcmVhbGl6ZSBtaW5lIGlzIG5vdCB0aGUg cHJldmFpbGluZyBvcGluaW9uLCBvciB3ZSB3b3VsZG4ndCBiZSB3aGVyZSB3ZSBhcmUgdG9kYXku ICBJZiBJRVRGIGRvZXNuJ3QgZG8gdGhpcywgaXQgaXMgbGVmdCB1cCB0byBtYXJrZXRpbmcgdHlw ZXMgYW5kIGluZGl2aWR1YWwgcGVyc29uYWwgZXhwZXJpZW5jZXMgYXMgaXQgaXMgdG9kYXkuICBU aGVyZSBsaWtlbHkgaXNuJ3QgYSBjb21tdW5pdHkgYmV0dGVyIHN1aXRlZCB0byBkZWZpbmluZyBo b3cgYWxsIHRoZSBkaXNwYXJhdGUgdGVjaG5vbG9naWVzIGFuZCBzdGFuZGFyZHMgc2hvdWxkIGZp dCB0b2dldGhlciB0byBmb3JtIGEgc2VydmljZSB0aGFuIElFVEYsIGFuZCBpdCByZWFsbHkgZG9l cyBmaXQgdGhlIG1pc3Npb24gb2YgSUVURi4gIEhvd2V2ZXIsIEknbSBnb2luZyB0byBsZXQgdGhp cyBicmFuY2ggb2YgdGhlIGNvbnZlcnNhdGlvbiBkaWUsIGFuZCBtb3ZlIGJhY2sgdG8gdGhlIGRp c2N1c3Npb24gb2YgdGhlIGlzc3VlIGF0IGhhbmQsIGludm9sdmluZyB0aGUgdHJhZGluZyBvZiBw ZXJzb25hbCBvcGluaW9ucyBvbiB3aGV0aGVyIDZ0bzQgaXMgc3RpbGwgcHJvdmlkZXMgYSBzZXJ2 aWNlLCBvciBpcyBqdXN0IGJyb2tlbi4gOy0pDQoNCi0gRGFuIA0K From nobody Tue Nov 4 05:21:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2441A1B31 for ; Tue, 4 Nov 2014 05:21:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 C9DRbxjO4iDn for ; Tue, 4 Nov 2014 05:21:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277C11A1B2F for ; Tue, 4 Nov 2014 05:21:36 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8C74720C25 for ; Tue, 4 Nov 2014 08:21:35 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 04 Nov 2014 08:21:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=FydISE7QjyupYXhyzXmbzC mxzFE=; b=JRpKf0+pLfPExncyifjBlvsxrxCj3fXCmJ/xOyA5/BJSGel+uf+pI4 QKF0TQFsQMXZf+ZVTRvgV/ePINvu2b8ow43QTzhFs/ioMroiIl6TSXcLn2X9QHDD 8z15VhFzvtVAMnXl8o0fGeciS6z8duKB5bdWMIG+pm4K+3kQAwXdk= X-Sasl-enc: o+JbuDMy8D3auhPjkaWVGZIwkrNNhPnMryaGfVlPHb0C 1415107295 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EB654C00014; Tue, 4 Nov 2014 08:21:34 -0500 (EST) Message-ID: <5458D2D2.80203@network-heretics.com> Date: Tue, 04 Nov 2014 08:21:22 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DECF421@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DECF421@ITSNT440.iowa.uiowa.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T1B94s475TI-izP1cday5c5Rfik Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 13:21:38 -0000 On 11/04/2014 07:49 AM, Metzler, Dan J wrote: > Well, I have a different opinion, but that's ok. IETF is responsible for IPv4 and IPv6. It makes sense that they should also be responsible for describing the contexts under which those are designed be used, and the same goes for the various transitional mechanisms that can help one get from IPv4 to IPv6. +1 From nobody Tue Nov 4 05:29:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1220B1A0105 for ; Tue, 4 Nov 2014 05:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.094 X-Spam-Level: X-Spam-Status: No, score=-115.094 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, RP_MATCHES_RCVD=-0.594, 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 epr4Z6aBuzbt for ; Tue, 4 Nov 2014 05:29:11 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3DE1A1B0D for ; Tue, 4 Nov 2014 05:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3092; q=dns/txt; s=iport; t=1415107751; x=1416317351; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vKFdgZad7yOB0cgUuXaPRCR7wKzsefstxYSJI/S+jdk=; b=dZeooRCWZHUH9THBqJtMT0FgwDJ3Kvu8FDE8HEd/TkX2Wm55qqeaHtut aw5vO1pvSs+GTPqH/przg8R+hlei3oyKaEh1iH5+XLNuV/Zl5ARlJJXwM Y4fPFhaDB5douo5l46Mv0URSo1IVKGjrwWnkz6f1n1RXj2PgFoG2sMtpp k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAC/UWFStJV2P/2dsb2JhbABcgkhGgSwE1igCgR8WAQEBAQF9hAMBAQMBZxIFCwIBCAQBQTIlAgQOBQ6IKgnMUwEBAQEBAQEBAQEBAQEBAQEBAQEBAReREAeDLYEeAQSSIIIVgVKIAJZPgjSBRGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="asc'?scan'208,217";a="93179369" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 04 Nov 2014 13:29:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sA4DT9CT003241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 13:29:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 07:29:09 -0600 From: "Fred Baker (fred)" To: Keith Moore Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP+DNQmuXr9lvB3kC1ruowAdspJQ== Date: Tue, 4 Nov 2014 13:29:09 +0000 Message-ID: <230E5AE4-A784-41DA-BE77-3E4F102A9ED0@cisco.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54583E00.5080003@network-heretics.com> In-Reply-To: <54583E00.5080003@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.68.198] Content-Type: multipart/signed; boundary="Apple-Mail=_72D8BABB-A4A4-4EB5-B9DC-B03288185E45"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BahcufdYFg-HeXLlOfvp-rqy1z4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 13:29:13 -0000 --Apple-Mail=_72D8BABB-A4A4-4EB5-B9DC-B03288185E45 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F6D707F-6A83-48E8-9809-49670520C7E1" --Apple-Mail=_7F6D707F-6A83-48E8-9809-49670520C7E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 4, 2014, at 3:46 AM, Keith Moore = wrote: > Carriers should forward packets, not decide what protocols their = customers are supposed to use or second-guess what their customers need. Should they decide what service models their services will support? The = discussion here isn=92t about what packets they will carry, it=92s about = whether they will implement relays and anycast addresses. --Apple-Mail=_7F6D707F-6A83-48E8-9809-49670520C7E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 4, 2014, at 3:46 AM, Keith = Moore <moore@network-heretics.com&= gt; wrote:

Carriers should forward packets, not decide what protocols = their customers are supposed to use or second-guess what their customers = need.

Should they decide what service models = their services will support? The discussion here isn=92t about what = packets they will carry, it=92s about whether they will implement relays = and anycast addresses.
= --Apple-Mail=_7F6D707F-6A83-48E8-9809-49670520C7E1-- --Apple-Mail=_72D8BABB-A4A4-4EB5-B9DC-B03288185E45 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 iD8DBQFUWNSlbjEdbHIsm0MRAlsIAJ0UQB7zJuBeTf9rnUbW0DvsmPnKrwCfXOJC jnRQh7tsycWLBlzPk1OUggw= =aWtB -----END PGP SIGNATURE----- --Apple-Mail=_72D8BABB-A4A4-4EB5-B9DC-B03288185E45-- From nobody Tue Nov 4 05:38:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF61A0105 for ; Tue, 4 Nov 2014 05:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feb6Xhm5PK00 for ; Tue, 4 Nov 2014 05:38:02 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4621A012D for ; Tue, 4 Nov 2014 05:38:00 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 895F9208DE for ; Tue, 4 Nov 2014 08:37:59 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 04 Nov 2014 08:37:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=TWC7MOYz/4WYl060R50Z2TOmx/E=; b=WgVKdTMhdvkRLxMvD x4Cobh8O7G3f9ZU/dDmRUKDMsNonX4kS3/0Kn1MgC1nzfN8K80pWLIiWWnje8reS 5LsOrdprgHSeFujKaNLw6kQW+kMlOze5he7ugbGuU9Sy4OR2552t1VVvRbaGmiQz f4YaqFNJ5P9p+n0O6PavDGfGsE= X-Sasl-enc: meXMJpLTkmcWp1iJtlNO2gL+r06xmoH11sfA7qoJu5iK 1415108279 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 1736F6800A8; Tue, 4 Nov 2014 08:37:59 -0500 (EST) Message-ID: <5458D6AA.4070607@network-heretics.com> Date: Tue, 04 Nov 2014 08:37:46 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54583E00.5080003@network-heretics.com> <230E5AE4-A784-41DA-BE77-3E4F102A9ED0@cisco.com> In-Reply-To: <230E5AE4-A784-41DA-BE77-3E4F102A9ED0@cisco.com> Content-Type: multipart/alternative; boundary="------------040905050609040705070608" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H2NBFMeigo-g8zZYiaGBf1I0r8E Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 13:38:07 -0000 This is a multi-part message in MIME format. --------------040905050609040705070608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/04/2014 08:29 AM, Fred Baker (fred) wrote: > > On Nov 4, 2014, at 3:46 AM, Keith Moore > wrote: > >> Carriers should forward packets, not decide what protocols their >> customers are supposed to use or second-guess what their customers need. > > Should they decide what service models their services will support? > The discussion here isn’t about what packets they will carry, it’s > about whether they will implement relays and anycast addresses. The original context was about whether carriers should filter protocol 41, to which the answer should be an emphatic "no". I don't think anyone has claimed that they "should" implement relays. As for anycast addresses, that's just not filtering a BGP prefix advertisement, right? So the carrier's default behavior should work, though it's certainly possible that I misunderstand something. There is a wrinkle in that public-facing carriers are often expected (for some reason) to be the first line of support when a customer's app breaks, which provides incentive for them to "fix" problems like 6to4 not working that might not actually be problems with their networks. I actually think that this is indicative of a fundamental and serious flaw in the Internet architecture: when something doesn't work, the Internet doesn't really provide any good indication of what the problem is, and what facility is responsible, to the host, application, or user. Some applications and operating systems have tried to remedy this, but it tends to be done on an ad hoc basis rather than being a general facility. Keith --------------040905050609040705070608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/04/2014 08:29 AM, Fred Baker (fred) wrote:

On Nov 4, 2014, at 3:46 AM, Keith Moore <moore@network-heretics.com> wrote:

Carriers should forward packets, not decide what protocols their customers are supposed to use or second-guess what their customers need.

Should they decide what service models their services will support? The discussion here isn’t about what packets they will carry, it’s about whether they will implement relays and anycast addresses.

The original context was about whether carriers should filter protocol 41, to which the answer should be an emphatic "no".

I don't think anyone has claimed that they "should" implement relays.   As for anycast addresses, that's just not filtering a BGP prefix advertisement, right?   So the carrier's default behavior should work, though it's certainly possible that I misunderstand something.

There is a wrinkle in that public-facing carriers are often expected (for some reason) to be the first line of support when a customer's app breaks, which provides incentive for them to "fix" problems like 6to4 not working that might not actually be problems with their networks.   I actually think that this is indicative of a fundamental and serious flaw in the Internet architecture:  when something doesn't work, the Internet doesn't really provide any good indication of what the problem is, and what facility is responsible, to the host, application, or user.   Some applications and operating systems have tried to remedy this, but it tends to be done on an ad hoc basis rather than being a general facility.

Keith

--------------040905050609040705070608-- From nobody Tue Nov 4 08:09:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BD1A8AEB for ; Tue, 4 Nov 2014 08:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 KDwGKJFABgkL for ; Tue, 4 Nov 2014 08:09:34 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542B71A8952 for ; Tue, 4 Nov 2014 08:09:33 -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 sA4G9XS7014269; Tue, 4 Nov 2014 08:09:33 -0800 Received: from XCH-BLV-308.nw.nos.boeing.com (xch-blv-308.nw.nos.boeing.com [130.247.25.220]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sA4G9U6W013785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 4 Nov 2014 08:09:30 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.171]) with mapi id 14.03.0210.002; Tue, 4 Nov 2014 08:09:29 -0800 From: "Templin, Fred L" To: Owen DeLong Thread-Topic: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 Thread-Index: AQHP97uGIlzPl+XDaUCYR32EWgqcuZxQJiQAgAB67SA= Date: Tue, 4 Nov 2014 16:09:29 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D78B49@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <2134F8430051B64F815C691A62D9831832D78297@XCH-BLV-504.nw.nos.boeing.com> <3B414326-0ACE-4130-AEDB-8631B07FB4C1@delong.com> In-Reply-To: <3B414326-0ACE-4130-AEDB-8631B07FB4C1@delong.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: http://mailarchive.ietf.org/arch/msg/v6ops/hWFVuZxeJet3AFa9Je7rzQeCRjQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2014 16:09:36 -0000 SGkgT3dlbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPd2VuIERl TG9uZyBbbWFpbHRvOm93ZW5AZGVsb25nLmNvbV0NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAw MywgMjAxNCA0OjM5IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4gQ2M6IElsaml0c2NoIHZh biBCZWlqbnVtOyB2Nm9wc0BpZXRmLm9yZyBXRw0KPiBTdWJqZWN0OiBSZTogQmFyIEJvRiBvbiBh IDZ0bzQgcmVwbGFjZW1lbnQ/IFdhczogbXkgcmVjb21tZW5kYXRpb24gcmU6IDZ0bzQNCj4gDQo+ IA0KPiA+IE9uIE5vdiAzLCAyMDE0LCBhdCAzOjExIFBNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGksIGp1c3QgYSBmZXcgd29y ZHMgb24gdGhpczoNCj4gPg0KPiA+Pj4+IEFsc28sIGlwLXByb3RvLTQxIGRvZXMgaGF2ZSBwYXRo IE1UVSBjaGFsbGVuZ2VzLiBXZSBhbGwga25vdyB0aGF0IFBNVFVEIGlzDQo+ID4+Pj4gdW5yZWxp YWJsZSwgd2hpY2ggbWVhbnMgdGhlIHR1bm5lbCBpbmdyZXNzIGhhcyB0byBzZXQgYSAic2FmZSIg TVRVIC0gdXN1YWxseSB0bw0KPiA+Pj4+IHNvbWV0aGluZyBvbiB0aGUgb3JkZXIgb2YgMTQ4MCBv ciBzbWFsbGVyLg0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgaGFyZCB0byBhdm9pZC4gSG9wZWZ1bGx5 LCB3aXRoIElQdjYgdGhlcmUgaXMgZW5vdWdoIHR1bm5lbGluZyB0aGF0IHBlb3BsZSB3aWxsIGNs ZWFuIHVwIHRoZWlyIFBNVFVEIGJyZWFrYWdlIHJhdGhlciB0aGFuDQo+IGxldA0KPiA+PiB0aG9z ZSB3aXRoIHBhdGggTVRVcyBiZWxvdyAxNTAwIHN1ZmZlciwgbGlrZSB3aGF0IGhhcHBlbnMgd2l0 aCBJUHY0Lg0KPiA+Pg0KPiA+PiBJ4oCZdmUgaGFkIDwxNTAwIE1UVSBvbiBib3RoIElQdjQgYW5k IElQdjYgZm9yIG1vc3Qgb2YgYSBkZWNhZGUuIEkgcmFuIGludG8gZmFpcmx5IHJlZ3VsYXIgcHJv YmxlbXMgaW4gSVB2NCB1bnRpbCBhYm91dCAzIHllYXJzIGFnby4NCj4gSeKAmXZlDQo+ID4+IG5l dmVyIHNlZW4gc2lnbmlmaWNhbnQgcHJvYmxlbXMgaW4gSVB2Ni4NCj4gPg0KPiA+IE1heWJlLCBi dXQgd2h5IHNldHRsZSBmb3IgPDE1MDAgd2hlbiB5b3UgY2FuIGhhdmUgMTUwMCs/DQo+IA0KPiBJ IGRvbuKAmXQgc2VlIGhvdyB5b3UgcGxhbiB0byBhY2hpZXZlIHRoYXQgd2l0aCBhIHR1bm5lbC4N Cg0KSXQgaXMgaW4gU2VjdGlvbiAzLjEyIG9mICdkcmFmdC10ZW1wbGluLWFlcm9saW5rJy4NCg0K PiBXaGF0IEkgaGF2ZSBpcyBydW5uaW5nIGNvZGUgaW4gcHJvZHVjdGlvbiB3b3JraW5nIG9uIGEg dmFyaWV0eSBvZiByb3V0ZXINCj4gcGxhdGZvcm1zIGFuZCBteSBJU1BzIGFyZSB3aWxsaW5nIHRv IHN1cHBvcnQgaXQuDQo+IA0KPiBJIGtub3cgeW914oCZZCBsaWtlIHRvIHNlZSBBRVJPIHJlcGxh Y2UgYWxsIHR1bm5lbHMgYW5kIG1vcmUgcG93ZXIgdG8geW91LCBidXQgYXMgYSBkYXRhcG9pbnQg Zm9yIHRoZSBkaXNjdXNzaW9uIGF0IGhhbmQsIEkgZG9u4oCZdCBmaW5kDQo+IHRoYXQgUE1UVS1E IGluIHRoZSByZWFsIHdvcmxkIGlzIGFzIGJyb2tlbiBhcyBzb21lIHJlcG9ydHMgb24gaGVyZSB3 b3VsZCBoYXZlIG9uZSBiZWxpZXZlLg0KDQpXZSBoYXZlIGRlYmF0ZWQgdGhhdCBoZWF2aWx5IG92 ZXIgdGhlIGxhc3QgZGVjYWRlLCBhbmQgdGhlcmUgaXMgYSByYWZ0IG9mDQpSRkNzIHRoYXQgZG9j dW1lbnQgdGhlIHByb2JsZW1zLiBFc3NlbnRpYWxseSwgSVB2NCBmcmFnbWVudGF0aW9uIGlzIGJh ZCwNCmFuZCBJQ01QIFBUQnMgY2FuIGJlIGRyb3BwZWQgYW5kL29yIGZvcmdlZCBieSBhZHZlcnNh cmllcy4gU28sIGFuDQphcHByb2FjaCB0aGF0IGF2b2lkcyB0aGUgcHJvYmxlbXMgd2hpbGUgb2Zm ZXJpbmcgYW4gYXNzdXJlZCAxNTAwIG1pZ2h0DQpiZSB1c2VmdWwuIEFuZCwgaWYgcGFja2V0cyBs YXJnZXIgdGhhbiAxNTAwIGNhbiBtYWtlIGl0IHRocm91Z2ggdGhlIHR1bm5lbA0Kd2UgbGV0IHRo ZW0gdGhyb3VnaCB0b28uDQoNClRoaXMgbGF0dGVyIHBvaW50IGlzIHdvcnRoIGhpZ2hsaWdodGlu Zy4gQnkgc2V0dGluZyBhIGZpeGVkIDwxNTAwIE1UVSBvbiBhDQp0dW5uZWwgaW50ZXJmYWNlIGFz IHBlciB0aGUgY3VycmVudCBwcmFjdGljZXMgeW91IGFyZSBkZXNjcmliaW5nLCB3ZSB3aWxsDQpu ZXZlciBnZXQgdG8gYSBqdW1iby1jYXBhYmxlIEludGVybmV0LiBCeSBhbGxvd2luZyAxNTAwKywg d2UgbWlnaHQNCmp1c3Qgc3RhbmQgYSBjaGFuY2UuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50 ZW1wbGluQGJvZWluZy5jb20NCg0KPiA+PiBJIHJlYWxpemUgdGhpcyBpc27igJl0IGV2ZXJ5b25l 4oCZcyBleHBlcmllbmNlLCBidXQgSSB0aGluayBmb3IgdGhlIG1vc3QgcGFydCB1bmxlc3MgeW91 IGdvIHNwZWNpZmljYWxseSBsb29raW5nIGZvciBicm9rZW5uZXNzIG9yIGxpdmUgaW4NCj4gSmFw YW4sDQo+ID4+IElQdjYgUE1UVSBkaXNjb3ZlcnkgbW9zdGx5IHdvcmtzLg0KPiA+Pg0KPiA+Pj4g QSBzb2x1dGlvbiBjb3VsZCBiZSBmb3IgaG9tZSBnYXRld2F5cyB0aGF0IHRlcm1pbmF0ZSBhIHR1 bm5lbCB0byBhZHZlcnRpc2UgdGhlIHR1bm5lbCBNVFUgaW4gdGhlaXIgUkFzIHNvIGhvc3RzIHVz ZSB0aGUgdHVubmVsDQo+ID4+IE1UVSBhbmQgYWxzbyBwdXQgdGhhdCBNVFUgaW4gdGhlaXIgVENQ IE1TUy4NCj4gPj4NCj4gPj4gSSB0aGluayBpZiB5b3UganVzdCBkbyB0aGUgTVNTIHRoaW5nLCBp dOKAmXMgdXN1YWxseSBhZGVxdWF0ZSBpbiBteSBleHBlcmllbmNlLg0KPiA+DQo+ID4gTm90IGFs bCBwcm90b2NvbHMgaW5jbHVkZSBhbiBNU1MuIENvbnNpZGVyIGZvciBleGFtcGxlIGEgdHVubmVs IHRoYXQgb3JpZ2luYXRlcw0KPiA+IGZyb20gYmVoaW5kIHRoZSBob21lIGdhdGV3YXkuIFJlY3Vy c2l2ZWx5IG5lc3RlZCB0dW5uZWxzIHdpdGhpbiB0dW5uZWxzDQo+ID4gd2lsbCBiZSBhIGZhY3Qg b2YgbGlmZSwgZS5nLiwgZm9yIGFueW9uZSB3aG8gc2V0cyB1cCBhIFZQTiBmcm9tIGEgZGV2aWNl IG9uIHRoZWlyDQo+ID4gaG9tZSBuZXR3b3JrIHRvIHRoZWlyIGNvcnBvcmF0ZSBvZmZpY2Ugc2Vj dXJpdHkgZ2F0ZXdheS4gQW5kLCBsaW5rcyB0aGF0DQo+ID4gc3VwcG9ydCAgYSBkZWdlbmVyYXRl IE1UVSAoaS5lLiwgYW55dGhpbmcgbGVzcyB0aGFuIDE1MDApIGFsd2F5cyBwcmVzZW50DQo+ID4g YSBsaW1pdGluZyBmYWN0b3IgZm9yIHJlY3Vyc2lvbi4NCj4gDQo+IFllcywgYnV0IHRoZXkgc2Vl bSB0byBtb3N0bHkgd29yayB3aXRoIHRoZSBJQ01QIFBUQiBtZXNzYWdlcyB0aGF0IGNvbWUgZnJv bSB0aGUgcm91dGVyIGluIG15IGV4cGVyaWVuY2UuDQo+IA0KPiBJZiB5b3UgZmFpbCB0byBzZXQg dGhlIE1TUyBvbiB0aGUgcm91dGVyLCB5b3UgZ2V0IHBhY2tldHMgdGhhdCBzZWVtIHRvIGZpdCB3 aXRoaW4gdGhlIE1UVSwgYnV0IGJyZWFrIFRDUCBpbiBpbnRlcmVzdGluZyB3YXlzLg0KPiANCj4g DQo+IE93ZW4NCg0K From nobody Mon Nov 10 02:32:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72C1A89B9; Mon, 10 Nov 2014 02:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 oV3UWIzkWdNF; Mon, 10 Nov 2014 02:31:58 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629F61A1A50; Mon, 10 Nov 2014 02:31:58 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 10FA51008E50A; Mon, 10 Nov 2014 10:31:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415615514; bh=iQ3Cx9zrmh6bSMpQhTYO3GZpAIEinnA1CzrHb8/LI8A=; h=Date:From:To:Subject; b=Bu31kxon+8CNt6HVNN2k4KezdLKDu1m17uaxKBDm8EQM8pZ7HhtWpVK2PWiWqGio/ HSNf1FuyzL8Nlqgkzr923PlC0ioP0UQ3Amtrqa9pwflm8Qn3hkrGnxoOjPOiGcIhSQ YDD6Klm59gzgBp/QAXbMQO2Lk+yQuKZZKiPYsE19/399l20dkkLiHAXzR13+EtP2Ih OyKyncfc1GcNsXTQpnLNmR9ygWlg32KmWMSaUawWcB8WKwpbGazoXXQ8mjWusuofGS fA4IE83bwKAPJlXrGw8pwGg92GeumSL3mFUObAGFNz0IHb1P3/7piZckt10GHn5j5c ZzFAnJKH59u7w== Message-ID: <54609418.5030503@massar.ch> Date: Mon, 10 Nov 2014 11:31:52 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: ipv6@ietf.org, v6ops@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bXgoeWSaj2s81N9CJO11UMEoJM4 Subject: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 10 Nov 2014 10:32:01 -0000 Hola folks (and folks in BCC ;), With the recent Google and Akamai outages (latter still ongoing afaik), it came to light that the cause is likely the model and problem described here: https://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem-01 which previously was: https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-01 Or shortly described: terminating an IP address at different hosts and having the balancer box not knowing where to deliver the ICMP PTBs that get send for large packets. One of the suggestions there is to lower the MSS for every connection by forcing it (either on the loadbalancer or on the final host) to a value that "works everywhere": the one for an MTU of 1280. MSS only applies to TCP, and people like Google are coming out with QUIC and other schemes. As we really do not want an Internet at an MTU of 1280, why don't we indicate in the packet what the MTU is when it is diverting from the norm? What if we instead let a router that sources a packet from a link or is going to transmit a packet over a link < 1500 indicate with that packet that that packet came from/is going to is a link with a MTU < 1500. We can't use an additional extension header, as adding anything would mean we might hit the MTU of the packet and we have other issues. As our least-known-used field is the FlowLabel field, we could abuse that and have enough bits there to stuff our data. What if we define that when the first 4 bits are set to 0xF (all one) that the rest (16bits) defines the MTU of the link (MTU 0 - 65k)? (We could even use a 'base of 1280' and thus 0xf0000 = 1280 MTU, but possibly it is better to state "value of < 0xf0500 is invalid") Thus allowing when the first 4 bits are not set to all-1 that the flowlabel field is a "normal flowlabel" field ala RFC6437. We could even state "Only set this MTU option when the FlowLabel field == 0" to avoid incompatibility (though I do not expect any as I rarely see packets with the field non-0...) Thus given a network like: [H1] 2001:db8:1500::1/64 | mtu = 1500 2001:db8:1500::a/64 [RA] 2001:db8:1501::a/64 | mtu = 1500 2001:db8:1501::b/64 [RB] 2001:db8:1480::b/64 | mtu = 1480 2001:db8:1480::c/64 [RC] 2001:db8:1280::c/64 | mtu = 1280 2001:db8:1280::d/64 [RD] 2001:db8:9000::d/64 | mtu = 9000 2001:db8:9000::2/64 [H2] RA receives packet, src+dst interface are MTU=1500, thus does nothing RB receives packet, src = 1500, dst = 1480, thus sets FL = 0xf05c8 RC receives packet, src = 1480, dst = 1280, thus sets FL = 0xf0500 RD receives packet, src = 1280, dst = 9000, thus sets FL = 0xf0500 (again, just set is quicker than checking) Now even if H2 is a loadbalancer, if the flow is just forwarded (without TTL change btw...) the destination receives it correctly. The disadvantage is of course that you lose the ability to balance based on the FlowLabel, but if we go with "only change when not 0 then there was one anyway. Also you got src+dst which is 256bits, which should be pretty good already and optionally next-header + the contents of the header if you want that. Note that as we have no checksum in IPv6, there is little overhead to do this kind of forwarding, HopLimit already needs updating, this is just another field to update. In another model from the above, we could even just let every hop set the known lowest MTU. In that case, H1 would set 0xf05dc in the packet, and then it gets lowered automatically. Which would also mean that a pure 9000 path would nicely work suddenly as everybody knows that 9000 will fit :) Greets, Jeroen From nobody Mon Nov 10 02:58:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C606A1A89F2; Mon, 10 Nov 2014 02:58: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_-CpgQJqaaO; Mon, 10 Nov 2014 02:58:10 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07421A89ED; Mon, 10 Nov 2014 02:58:10 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 63C1F1008CA95; Mon, 10 Nov 2014 10:58:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415617088; bh=/nSmKuq7F7Nj8eSmw+AAIWtRnvL0GxNeADo/kQRqpKk=; h=Date:From:To:Subject:References:In-Reply-To; b=BwubWZqM2joIPh64YrTJQYYvaHOgu+OFgw555Q49mrNii+Z281mtYz7zzKEMEwIET c5qtO22kSqFZJ12wnIQKs+OpzKH71xuG42bIxM8/+W9TwldAk+i3tLzrog1I+zzQhA 283cupe9bQ24p/x1d45YCHeHVuC/SLSukLUUA2yvACEdrwKs4NSbULZDnov5C1kmYS GzWfpXf5YUQT09dKwGVXDR9PUxGLzEfyqWsxPZpnAyYYC4URIU4bMG09pKX1IbuuBa leKV64qNZSNULI+KDuq2iWyrID+EpEqKbSti5LvNx8u/dvjO5Hpm9OsS0k91mZE+Be VHRCfxozbZg9g== Message-ID: <54609A3E.3030106@massar.ch> Date: Mon, 10 Nov 2014 11:58:06 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: ipv6@ietf.org, v6ops@ietf.org References: <54609418.5030503@massar.ch> In-Reply-To: <54609418.5030503@massar.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R8r_A517GeDgZDgYLgYojO_So4w Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 10 Nov 2014 10:58:12 -0000 On 2014-11-10 11:31, Jeroen Massar wrote: [..] > Thus given a network like: [..] Of course, there is one big problem with that example: network paths might be asymmetric. As such, such a change will work fine in a network where the end-links and not the core/transit (that might be asymmetric) is changing MTU. Thus in the case the return path is different and there is a MTU change there, that link will not have the correct MTU from this measurement. But there is no easy way to solve this except for working PMTUD as that does let the source know that that link has a wrong MTU. Hence, this "IPv6 MTU Flow-Label" idea only solves a part of the problem and PMTUD as per ICMP needs to remain working and operable. But IMHO, as most well-connected mass-hosting providers are very close to their users they likely have a non-assymetric path and this trick will just solve their problem a little bit better. Greets, Jeroen From nobody Mon Nov 10 10:57:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A831A1AEF; Mon, 10 Nov 2014 10:57: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 0TURJqSE-td3; Mon, 10 Nov 2014 10:57:47 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD471A1ACF; Mon, 10 Nov 2014 10:57:45 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id h11so11596079wiw.12 for ; Mon, 10 Nov 2014 10:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mMQCSwlOFq+jwa0MMjwW9kQggKihNCz//Ku1DETPkQg=; b=MKNWgjCCe21n6ZGANf5v+yzOC6HqR9bMcZoyb2H4YCW6M0Tq42AIdWqPuwLpDch0bx GvJ5gwwtjrMc1ED9T5C05wR03u7yWunFcgqK6f+IR7JKJ7mDc6pypy8Lj2yocjrhZZHn +MZ1k+LkzkjLrtGoQeA0eWNB7Ey6nrU+1d+2SH9x7KkS5qdgvrkk9d5qzdktlxba7iOO 7K6M3E9P8Ot0S01ydmOaPiKy/keM1do8IPWGped4s4ihnbSmyp5l3owqQt8Gp3/mr3iQ LXULxaE2TjoaySCUm+H7HuwhoMMs0utHUPFd2vlq7rk9zwcTor2h4e4IIgf1X3+qHxRX H2mA== X-Received: by 10.180.14.226 with SMTP id s2mr32611991wic.61.1415645864455; Mon, 10 Nov 2014 10:57:44 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id dr5sm14481127wib.4.2014.11.10.10.57.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 10:57:44 -0800 (PST) Message-ID: <54610AA7.6070100@gmail.com> Date: Tue, 11 Nov 2014 07:57:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> In-Reply-To: <54609A3E.3030106@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xbdPgTeMfkyOJlL24z8lhKjd9bY Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 10 Nov 2014 18:57:50 -0000 Er, no, you really can't use the flow label like that. RFC6437. What you can do is use the flow label as intended, for ECMP or any other kind of load balancing. RFC6438, RFC7098. They don't fix the ICMPv6 problem though. The key sentence in Joel's draft is > Because the PTB message is not identifiable as part of the > original flow by the packet header the results of the ICMPv6 ECMP > hash are unlikely to be hashed to the same nexthop as packets > matching TCP or UDP ECMP hash. To fix that, I suspect that flow label reflection is needed. draft-wang-6man-flow-label-reflection doesn't discuss its use for ensuring that ICMPv6 is treated consistently, but could do so. Regards Brian On 10/11/2014 23:58, Jeroen Massar wrote: > On 2014-11-10 11:31, Jeroen Massar wrote: > [..] >> Thus given a network like: > [..] > > Of course, there is one big problem with that example: > network paths might be asymmetric. > > As such, such a change will work fine in a network where the end-links > and not the core/transit (that might be asymmetric) is changing MTU. > > Thus in the case the return path is different and there is a MTU change > there, that link will not have the correct MTU from this measurement. > > But there is no easy way to solve this except for working PMTUD as that > does let the source know that that link has a wrong MTU. > > Hence, this "IPv6 MTU Flow-Label" idea only solves a part of the problem > and PMTUD as per ICMP needs to remain working and operable. > > But IMHO, as most well-connected mass-hosting providers are very close > to their users they likely have a non-assymetric path and this trick > will just solve their problem a little bit better. > > Greets, > Jeroen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Nov 10 11:03:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D021A9166; Mon, 10 Nov 2014 11:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h48HGewNQgK; Mon, 10 Nov 2014 11:02:55 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875711A9163; Mon, 10 Nov 2014 11:02:50 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C70B1100A6C7F; Mon, 10 Nov 2014 19:02:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415646165; bh=klMivqt6/hJjSYueIO++bpIDYUSGcd/c3SaEvg8zsVg=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=eSJQA7qvVVQgS+/+zio0bwgwEgEe+YY+m0XeLiiZuUr5WFqWu+ZEwtL/Xx5UNY29M tdpp3LytZ2zY8LQnN2xOYdb36ts+tEO8KHWxErwKavYHtKGMxpdALxC5pMycXNyMeg Qs3YCxItP2apJC4DghwgBhR2ro5ObheHKnQ3josEvubyNgxASEYm7Pmbmsm+4DfdYf PZiz/8/759DQlw2bzTlLIWEcO6amZ3qYBRLUuy5URZs8ri4gxr+ry1GuYubJ/EStBR qlsNNOuu3uFjaZeG9uFO62pDm8TyQTAiJ+N4C7kxs43yjGrlELBDDsuGc81oXPma8u 22ZbIW1PC6sbA== Message-ID: <54610BD4.2070600@massar.ch> Date: Mon, 10 Nov 2014 20:02:44 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> In-Reply-To: <54610AA7.6070100@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z9_k9SU59KjHx2uia4CX1QGsP5o Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 10 Nov 2014 19:02:57 -0000 On 2014-11-10 19:57, Brian E Carpenter wrote: > Er, no, you really can't use the flow label like that. RFC6437. Hence, redefining the bits :) Few implementations use them anyway, thus we still have time to actually make good use of them. Note that I am specifically proposing setting the first four bits to 1 aka 0xf so that the space can still be used for it's original intent too. > What you can do is use the flow label as intended, for ECMP or any > other kind of load balancing. RFC6438, RFC7098. They don't fix the > ICMPv6 problem though. It won't fix the 1-RTT issue that worries content providers either. That is the biggest problem for them: a ICMPv6 PTB is an extra round trip and they want speed. Hence including the MTU already in the packet. (though as noted in my reply, it won't work fully for async networks) > The key sentence in Joel's draft is > >> Because the PTB message is not identifiable as part of the >> original flow by the packet header the results of the ICMPv6 ECMP >> hash are unlikely to be hashed to the same nexthop as packets >> matching TCP or UDP ECMP hash. > > To fix that, I suspect that flow label reflection is needed. Won't work as that packet will not be matching the loadbalancers setup either. What would partially work is if the ICMPv6 PTB would copy the flow-label from the original flow that caused the PTB. But then still, large content providers will not be happy, as it does not satisfy the 1-RTT argument, which now causes them to just ignores PTBs and set the MSS to something tiny (thus in the end causing more packets, but at least all packets will go through). Greets, Jeroen From nobody Mon Nov 10 11:54:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1F61ACD40; Mon, 10 Nov 2014 11:54: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 kOZnrz808izh; Mon, 10 Nov 2014 11:54:31 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A096C1ACD3F; Mon, 10 Nov 2014 11:54:30 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so11708763wiv.6 for ; Mon, 10 Nov 2014 11:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H8YX/HY2GjomMY9bJ6RmJS+7WKid0+4M6bgqN7NxLaI=; b=JFaY0uw+tZynJJ4GDToXUryh8v8f8BBkvy04lG5yrKH0ktEL9B+WhaqbyHVi/dyG+q oUpx9ECvX9nw0L5nkELyZ+Y020ugATI5xu2AvDT3F0YggDBfM4wbCv/DgHw2475F/P5B yzLkZqVZkrmbWEwrUAXULgVuQ60ZQ3Y1D+zDkYQL7DA96aHO+sJvx8Vkwr0xIKpksruq 9JaUIkFf1rsLmlatS1JYCQ5YbtD8FDj0XqJHWVPCdRp9hw8D+UZo4Dezn8aXmeehiqN9 mTdCwdFOhJdC9dVRkYJi96+aRpY84+RArEc4Wm14VjjORadYs6ZE5eoTaWOTjV+54ENP vCpg== X-Received: by 10.180.95.74 with SMTP id di10mr34170389wib.54.1415649265967; Mon, 10 Nov 2014 11:54:25 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id t16sm18873012wjr.28.2014.11.10.11.54.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 11:54:25 -0800 (PST) Message-ID: <546117F0.8070800@gmail.com> Date: Tue, 11 Nov 2014 08:54:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> In-Reply-To: <54610BD4.2070600@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aFu1Pn-2PQpsaSrKUJPhKDSfICU Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 10 Nov 2014 19:54:32 -0000 On 11/11/2014 08:02, Jeroen Massar wrote: > On 2014-11-10 19:57, Brian E Carpenter wrote: >> Er, no, you really can't use the flow label like that. RFC6437. > > Hence, redefining the bits :) Few implementations use them anyway, thus > we still have time to actually make good use of them. > > Note that I am specifically proposing setting the first four bits to 1 > aka 0xf so that the space can still be used for it's original intent too. Yeah, well, 6man has consistently said no to every such proposal. >> What you can do is use the flow label as intended, for ECMP or any >> other kind of load balancing. RFC6438, RFC7098. They don't fix the >> ICMPv6 problem though. > > It won't fix the 1-RTT issue that worries content providers either. > > That is the biggest problem for them: a ICMPv6 PTB is an extra round > trip and they want speed. Hence including the MTU already in the packet. > (though as noted in my reply, it won't work fully for async networks) > >> The key sentence in Joel's draft is >> >>> Because the PTB message is not identifiable as part of the >>> original flow by the packet header the results of the ICMPv6 ECMP >>> hash are unlikely to be hashed to the same nexthop as packets >>> matching TCP or UDP ECMP hash. >> To fix that, I suspect that flow label reflection is needed. > > Won't work as that packet will not be matching the loadbalancers setup > either. > > What would partially work is if the ICMPv6 PTB would copy the flow-label > from the original flow that caused the PTB. Yes, that idea has come up a few times but frankly I will be amazed if it ever catches on. > > But then still, large content providers will not be happy, as it does > not satisfy the 1-RTT argument, which now causes them to just ignores > PTBs and set the MSS to something tiny (thus in the end causing more > packets, but at least all packets will go through). Sure. Isn't that the main reason that the IPv4 network actually works today? Brian From nobody Mon Nov 10 21:40:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DD1ACDC6; Mon, 10 Nov 2014 21:40:28 -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 j1qAdqbk6333; Mon, 10 Nov 2014 21:40:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE51AD291; Mon, 10 Nov 2014 21:40:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 21:40:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OiZatDP-EJ89ouSz-8W0ve2DWWU Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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: Tue, 11 Nov 2014 05:40:29 -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 : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-07.txt Pages : 7 Date : 2014-11-10 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet, especially in its anycast mode. This document requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 10 21:44:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D461ACDC6 for ; Mon, 10 Nov 2014 21:44:31 -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 pIHAqgV3drDx for ; Mon, 10 Nov 2014 21:44:29 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283481ACD85 for ; Mon, 10 Nov 2014 21:44:29 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so525793wiv.13 for ; Mon, 10 Nov 2014 21:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=55O5g6iJkCPJI1XB+D79FZvzKERC1ERjQ05enaIt8AY=; b=XPlDYChXcmHB8oxXovAWzXXzVYZaOzZNpIuw4+kIslMzFblNEEBqrRAp7BSRw/vPkK KUDMrXZ3EW0eN0tH4NEA1l9JRaEM+nQexS5DV2F+HPxDBM6e3UfUNznus22EJUGgC5gg EE3d/Tfp3iqZGycIe0NcsQoiWzYr/2x0Nc30x7a1NgHBXS0x04A6TBBALrB5+FeyawDF 5xgFCWVqKUz88uOzn3smVbAkpWMOG7wocsdlIfDkKRPLhQ5ahColQH8evsiuq/vaRybQ Bzd5ujCaX+dceP3qdexxMR9qhxvCBn+dYSjCy1SQlv8GMcxp9KnDRsiUftbZyRcrHyBC NZPg== X-Received: by 10.194.237.162 with SMTP id vd2mr50521523wjc.52.1415684667991; Mon, 10 Nov 2014 21:44:27 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id ce1sm25820212wjc.2.2014.11.10.21.44.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 21:44:27 -0800 (PST) Message-ID: <5461A23D.5020506@gmail.com> Date: Tue, 11 Nov 2014 18:44:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> In-Reply-To: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9VqmWq4Qw5JnZ6Y3NLk4AwgVQXA Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 05:44:31 -0000 This is intended to incorporate the result of today's discussion. Please let the authors know if we got it wrong. Brian On 11/11/2014 18:40, internet-drafts@ietf.org wrote: > 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 : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-07.txt > Pages : 7 > Date : 2014-11-10 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet, > especially in its anycast mode. This document requests that RFC > 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete > and moved to historic status. It also recommends that future > products should not support 6to4 anycast and that existing > deployments should be reviewed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 11 01:52:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E10C1A896A; Tue, 11 Nov 2014 01:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SomPJtYHTy-N; Tue, 11 Nov 2014 01:52:53 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A0D1A8978; Tue, 11 Nov 2014 01:52:52 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 6520D10060A2C; Tue, 11 Nov 2014 09:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415699569; bh=2xCBgWc4X+IypeGsnF5QrnDE5LH4LgOJNlcIkprEF6Q=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=dCEN9PM2aa3Imd7Q65XIT5+OP7++dznbeiDI/YwERGOp3OwC2EhxreLbxm65ClEIA 7BpsaAABPTBjbK57gzNxDWliI989b1EdOrH/WK0RmwaA6m88tT3r49FjcgvTvS4nuf M3NPqgInq1qW9qpweIhP7hL+GQDbgbma1NeUoOILSJE5o7nU1CCri7IaU8W9BpfECK n+chOu/H8MumLdCRZgU8exQJnGEVLD/Do4AveDXDD8X8obswn1rRHs4pR93A64X/h8 nVGlPEYgxeQo7QN3pG69v2o9ng/Voldo4o7aH04sZGax48vLhSg/jn9iVEeAcSDoOl CJWi/yWPIOLrA== Message-ID: <5461DC70.1090303@massar.ch> Date: Tue, 11 Nov 2014 10:52:48 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> In-Reply-To: <546117F0.8070800@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QBj54gAWUN7WfN1vDlr01zDqXdg Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 11 Nov 2014 09:52:55 -0000 On 2014-11-10 20:54, Brian E Carpenter wrote: > On 11/11/2014 08:02, Jeroen Massar wrote: >> On 2014-11-10 19:57, Brian E Carpenter wrote: >>> Er, no, you really can't use the flow label like that. RFC6437. >> >> Hence, redefining the bits :) Few implementations use them anyway, thus >> we still have time to actually make good use of them. >> >> Note that I am specifically proposing setting the first four bits to 1 >> aka 0xf so that the space can still be used for it's original intent too. > > Yeah, well, 6man has consistently said no to every such proposal. Well, maybe it is time to finally look at such a proposal instead of keeping those 20 bits be used for nothing useful. At minimum there should be a document describing WHY such a change is out of the question. It is not because anybody used the IPv6 Flowlabel for any useful data. Devices will always combine it with src+dst+nextheader at minimum, which is a lot more bits than those 20 bits wasted on a flowlabel. >>> What you can do is use the flow label as intended, for ECMP or any >>> other kind of load balancing. RFC6438, RFC7098. They don't fix the >>> ICMPv6 problem though. >> >> It won't fix the 1-RTT issue that worries content providers either. >> >> That is the biggest problem for them: a ICMPv6 PTB is an extra round >> trip and they want speed. Hence including the MTU already in the packet. >> (though as noted in my reply, it won't work fully for async networks) >> >>> The key sentence in Joel's draft is >>> >>>> Because the PTB message is not identifiable as part of the >>>> original flow by the packet header the results of the ICMPv6 ECMP >>>> hash are unlikely to be hashed to the same nexthop as packets >>>> matching TCP or UDP ECMP hash. >>> To fix that, I suspect that flow label reflection is needed. >> >> Won't work as that packet will not be matching the loadbalancers setup >> either. >> >> What would partially work is if the ICMPv6 PTB would copy the flow-label >> from the original flow that caused the PTB. > > Yes, that idea has come up a few times but frankly I will be amazed > if it ever catches on. Actually there is no need for it. The ICMPv6 PTB has a maximum of 1280 bytes (due to minimum MTU), but includes an IPv6 header (40 bytes), the ICMP PTB (~20 bytes) and then a copy of the original packet. Hence, unless devices do not trust those packets, it will contain at least the original 40 bytes of the original IPv6 packet that caused the PTB, which includes the source + dest + flow-label and likely even the UDP/TCP packet. As such, while handling ICMPv6 PTBs on a load-balancer is extra work, it can be done. There will be about 1200 bytes of the original packet in there, most of that will be data, not even headers that are needed to identify the packet. >> But then still, large content providers will not be happy, as it does >> not satisfy the 1-RTT argument, which now causes them to just ignores >> PTBs and set the MSS to something tiny (thus in the end causing more >> packets, but at least all packets will go through). > > Sure. Isn't that the main reason that the IPv4 network actually works > today? No. The IPv4 works as routers fragment and thus no ICMP is involved unless we are talking going below the extremely small IPv4 MTU. Greets, Jeroen From nobody Tue Nov 11 08:50:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4601A1A5E for ; Sun, 2 Nov 2014 22:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 IbuVtwRG6MJL for ; Sun, 2 Nov 2014 22:56:54 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991991A1A5D for ; Sun, 2 Nov 2014 22:56:54 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k15so6218731qaq.1 for ; Sun, 02 Nov 2014 22:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=1bE8eHxGwx37YpzkDi5mxqrzXWkM8FjryS63l5ADHgw=; b=Q+AUZd451EaJpbuhIo0+KVL08DxdY5/6/sA8X0bSSYIQpP63PdXHmUqnZ8n2l9k4ti MKkYJAjmGgBs9DyrT9g2vsImH5pehEj5wWvx1hX5e7OBF7tM+i96zoXBUJRBPkpW4lhX bEDGWIef/OnnCew5BoR1HFBNw6lyEhgGijxYZM9EykjcKAmeLN1dtVNJ8qK6iW0ie+la MRf8mL1boMUbW+v6sJzdOV84MCXoIF0+1IC+C3ybsDbSneDIikr+lacAm/B9kaUyppQR hofpdzyvW5DKQih1XBf9WJ8GxbcSMJfuiEXaqkl6anPX0BzKN9eEi5z43XA7xq9U8CQc Z9FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=1bE8eHxGwx37YpzkDi5mxqrzXWkM8FjryS63l5ADHgw=; b=Suu5M6uAtT70ShD6juJd85NMftuTWO3WY2zciX5qKQ15Hu16MSF9m4IYl6oRwz3Puw dtALGLHrswoAOo89+wAvw/rr++BoUVjxMfxKCHMUnRmxryHCBJreX9YJwGQg4te7YVyJ WYNGF6uClprz2QUYMDzY+iz9c04ZXajERJpmQVBcT/ksaapBwuAZMAE4NYPKeJlJSwSO fTW3fJrOosb01HTn46siFqHjEkrUOSSr6vc2Zr2EcK4Pkq0cdQaSYxyEy1aV/ig5tW9A Kx0JYatdUe/5ErMnLR7r6zVPznePxNS2euXjRnnZnFPmVKsGvAcB9oAPCJdL7zxvKf0C HFnA== X-Gm-Message-State: ALoCoQnSCkSaDL3uKQtdS17312wxltHM637aos2vO6+DD0TaA/EZQrw/wvbfjtpTvoA4D7A9nW+E X-Received: by 10.229.37.70 with SMTP id w6mr61721294qcd.11.1414997813589; Sun, 02 Nov 2014 22:56:53 -0800 (PST) MIME-Version: 1.0 References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <54572201.5040201@massar.ch> From: Erik Kline Date: Mon, 03 Nov 2014 06:56:53 +0000 Message-ID: To: Jeroen Massar , Keith Moore Content-Type: multipart/alternative; boundary=001a1133c916099cea0506eedaed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pPZOk1N7F2bsMT7dHTZBTQyFDuw X-Mailman-Approved-At: Tue, 11 Nov 2014 08:50:36 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] "protocol 41 isn't just IPv6 over IPv4." (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2014 06:56:56 -0000 --001a1133c916099cea0506eedaed Content-Type: text/plain; charset=UTF-8 Yes, clearly we're going need IPv4(TCP(TLS(HTTP(IPv6))))). /me ducks On Sun Nov 02 2014 at 10:34:53 PM Jeroen Massar wrote: > On 2014-11-03 06:09, Keith Moore wrote: > > On 11/02/2014 11:35 AM, Metzler, Dan J wrote: > >> That said, back to the original discussion, involving protocol 41, if > >> AT&T is truly blocking protocol 41 because they provide IPv6 native > >> support across the board already, that seems a lot less unreasonable. > > protocol 41 isn't just IPv6 over IPv4. > > What "else" is it then? :) > > > Yes, 6in4 (as in tunnelbrokers), 6rd, 6to4 and some others use it. > > But blocking proto-41 blocks in essence anything that is transmitting > proto-41 packets and thus "IPv6 over IPv4". > > The problem here is a ISP policy decision though; AT&T should not be > blocking things in the first place. Contact AT&T to resolve that matter, > nothing the IETF can do about (except suggesting alternative protocols > to circumvent such a block). > > Greets, > Jeroen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1133c916099cea0506eedaed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, clearly we're going need IPv4(TCP(TLS(HTTP(IPv6))))).

= /me ducks

On Sun Nov 02 2014 at 10:34:5= 3 PM Jeroen Massar <jeroen@massar.ch= > wrote:
On 2014-11-03 06:09, Keit= h Moore wrote:
> On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
>> That said, back to the original discussion, involving protocol 41,= if
>> AT&T is truly blocking protocol 41 because they provide IPv6 n= ative
>> support across the board already, that seems a lot less unreasonab= le.
> protocol 41 isn't just IPv6 over IPv4.

What "else" is it then? :)


Yes, 6in4 (as in tunnelbrokers), 6rd, 6to4 and some others use it.

But blocking proto-41 blocks in essence anything that is transmitting
proto-41 packets and thus "IPv6 over IPv4".

The problem here is a ISP policy decision though; AT&T should not be blocking things in the first place. Contact AT&T to resolve that matter= ,
nothing the IETF can do about (except suggesting alternative protocols
to circumvent such a block).

Greets,
=C2=A0Jeroen

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a1133c916099cea0506eedaed-- From nobody Tue Nov 11 08:59:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24071A6FF8 for ; Tue, 11 Nov 2014 08:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 9y0VFOezNI7o for ; Tue, 11 Nov 2014 08:58:51 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6341A1BC9 for ; Tue, 11 Nov 2014 08:58:51 -0800 (PST) Received: from t2001067c03700136283894a5afa71922.hotel-wireless.v6.meeting.ietf.org (t2001067c03700136283894a5afa71922.hotel-wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:136:2838:94a5:afa7:1922]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id sABGwfDK003010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 11:58:47 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 11 Nov 2014 11:58:38 -0500 Content-Transfer-Encoding: 7bit Message-Id: <35A04B6B-DD8D-43F5-A7E5-6D0C7C50EACF@puck.nether.net> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC8492@ITSNT440.iowa.uiowa.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC886B@ITSNT440.iowa.uiowa.edu> <54570E27.60504@network-heretics.com> <54572201.5040201@massar.ch> To: Erik Kline X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [IPv6:2001:418:3f4::5]); Tue, 11 Nov 2014 11:58:48 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7aWIhGPxuGWuqT1jblAwiHUslDw Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] "protocol 41 isn't just IPv6 over IPv4." (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 16:58:56 -0000 You left out GRE or a MPLS label, as well as NVGRE/VXLAN. - Jared > On Nov 3, 2014, at 1:56 AM, Erik Kline wrote: > > Yes, clearly we're going need IPv4(TCP(TLS(HTTP(IPv6))))). From nobody Tue Nov 11 10:46:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234021A1A62; Tue, 11 Nov 2014 10:46:19 -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 665Bl7dWgX8I; Tue, 11 Nov 2014 10:46:15 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5031A036A; Tue, 11 Nov 2014 10:46:15 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id r20so2691455wiv.5 for ; Tue, 11 Nov 2014 10:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xT92qMrmIed5XMmO3EMF6TiCNL8JM0OKZXASCPWQleE=; b=VAj0XshJQbABmu5XElMBTbJT7G+ttLbw8I7WxWwnla/FVfu6o4Sr8m6Pes3Gfjh9eO OKmiRyCiGArYVh7e9GWk4kMatjJn7bud2P1SQo/UhvU9xHJnsbApNtF2OWepZZhS8kDf O+NJCoOARRiLgGE7f8owT3ILDNQTQbq/p8LAobMhBZCDrc/6sRxI72Hx49IDdua9Rzet ealnfhrqMgvgsVXGFLwQNFuBsRo5+dpizjodmO8HFE4tzsDDJFK7G5wJJUocqLpzCfVA rmDpbnwoK1ufIsbZFvL7QAwAulgnfCr4QZox6yym5wcspCNVZJd9BEwC9qWng2IGPNFl F15A== X-Received: by 10.180.77.170 with SMTP id t10mr43855218wiw.57.1415731573979; Tue, 11 Nov 2014 10:46:13 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id mu4sm18580958wib.2.2014.11.11.10.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 10:46:13 -0800 (PST) Message-ID: <54625975.70604@gmail.com> Date: Wed, 12 Nov 2014 07:46:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> In-Reply-To: <5461DC70.1090303@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IfSS8zEfQjWYT6Ur_a9x3f4mNO4 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 11 Nov 2014 18:46:19 -0000 On 11/11/2014 22:52, Jeroen Massar wrote: > On 2014-11-10 20:54, Brian E Carpenter wrote: >> On 11/11/2014 08:02, Jeroen Massar wrote: >>> On 2014-11-10 19:57, Brian E Carpenter wrote: >>>> Er, no, you really can't use the flow label like that. RFC6437. >>> Hence, redefining the bits :) Few implementations use them anyway, thus >>> we still have time to actually make good use of them. >>> >>> Note that I am specifically proposing setting the first four bits to 1 >>> aka 0xf so that the space can still be used for it's original intent too. >> Yeah, well, 6man has consistently said no to every such proposal. > > Well, maybe it is time to finally look at such a proposal instead of > keeping those 20 bits be used for nothing useful. > > At minimum there should be a document describing WHY such a change is > out of the question. This is exactly why we did the RFCs I mentioned. EOM. Brian > > It is not because anybody used the IPv6 Flowlabel for any useful data. > Devices will always combine it with src+dst+nextheader at minimum, which > is a lot more bits than those 20 bits wasted on a flowlabel. > >>>> What you can do is use the flow label as intended, for ECMP or any >>>> other kind of load balancing. RFC6438, RFC7098. They don't fix the >>>> ICMPv6 problem though. >>> It won't fix the 1-RTT issue that worries content providers either. >>> >>> That is the biggest problem for them: a ICMPv6 PTB is an extra round >>> trip and they want speed. Hence including the MTU already in the packet. >>> (though as noted in my reply, it won't work fully for async networks) >>> >>>> The key sentence in Joel's draft is >>>> >>>>> Because the PTB message is not identifiable as part of the >>>>> original flow by the packet header the results of the ICMPv6 ECMP >>>>> hash are unlikely to be hashed to the same nexthop as packets >>>>> matching TCP or UDP ECMP hash. >>>> To fix that, I suspect that flow label reflection is needed. >>> Won't work as that packet will not be matching the loadbalancers setup >>> either. >>> >>> What would partially work is if the ICMPv6 PTB would copy the flow-label >>> from the original flow that caused the PTB. >> Yes, that idea has come up a few times but frankly I will be amazed >> if it ever catches on. > > Actually there is no need for it. The ICMPv6 PTB has a maximum of 1280 > bytes (due to minimum MTU), but includes an IPv6 header (40 bytes), the > ICMP PTB (~20 bytes) and then a copy of the original packet. > > Hence, unless devices do not trust those packets, it will contain at > least the original 40 bytes of the original IPv6 packet that caused the > PTB, which includes the source + dest + flow-label and likely even the > UDP/TCP packet. > > As such, while handling ICMPv6 PTBs on a load-balancer is extra work, it > can be done. > > There will be about 1200 bytes of the original packet in there, most of > that will be data, not even headers that are needed to identify the packet. > >>> But then still, large content providers will not be happy, as it does >>> not satisfy the 1-RTT argument, which now causes them to just ignores >>> PTBs and set the MSS to something tiny (thus in the end causing more >>> packets, but at least all packets will go through). >> Sure. Isn't that the main reason that the IPv4 network actually works >> today? > > No. The IPv4 works as routers fragment and thus no ICMP is involved > unless we are talking going below the extremely small IPv4 MTU. > > Greets, > Jeroen > > From nobody Tue Nov 11 11:34:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261551A87E9 for ; Tue, 11 Nov 2014 11:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XD_nHG9eEH0 for ; Tue, 11 Nov 2014 11:34:26 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9B1A880E for ; Tue, 11 Nov 2014 11:34:11 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 11 Nov 2014 13:34:01 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f171.google.com [209.85.223.171] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f171.google.com with SMTP id x19so12035092ier.2 for ; Tue, 11 Nov 2014 11:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4+/7hLrEclqKj7CdjDgRcTbDV4evbQC/asrl2il3qas=; b=mEnEhcoHWwlL6WiVrj7MRYkGHAGtuztHtNzCg8XylHkLJp1ynJZeGUfQnGZ1FxUil/ MeQ/o7A723sCOUhaVZz4+FroRxrtMC6htyrJA0a/0h5ZtycJxAC7it6me1KkwcnNFVO8 ZUaLQxEFCa5ojUxQRsXvyWnKHejeREQzB1XNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4+/7hLrEclqKj7CdjDgRcTbDV4evbQC/asrl2il3qas=; b=WrCCf4wn+PA1Vdo3guNWDzjuITcMt+rsRbp7TNAW7Ykw6Hy/w9PXMJ+mvnrDH4/SBg c9Kc0Gb3kzT2dEmbdz5Q/reFsF59U1QB4AVY7CLDpiDsYndic4YMFMYB63oOjdv8EwZx d0RSWJj34zqufUQ3tRDSewTG8bDDfFQxtC6bD/Ki9uqn7jIWSuJe2PaC5kBCvbV651vZ 18pQSB8KD0/8ehm1txZcJrXIzc1wJJ5cCdhl8bMSrhCQpgsNKKQvxbvwrXVDZXkXCRq0 B64tcox3PAZCxO2ZarVN0bAg3Q9oPyP6Z8ihWsoQWaGiL2REF4wd2qkiLTJ17K+tDfrj aM6g== X-Gm-Message-State: ALoCoQkXJ/dSiAmTUnzde4TXvDRign2aVpa4tjx77p5yaoprtk2nUsOykDRcVJNdvPQUcmC4tfPefKmDGa/fOvjqe88dSvLXUDxPwoyqWK83m1RhtyKLycGBZkVRG8L/UghZckfMahFG X-Received: by 10.50.119.3 with SMTP id kq3mr34750284igb.46.1415734441139; Tue, 11 Nov 2014 11:34:01 -0800 (PST) X-Received: by 10.50.119.3 with SMTP id kq3mr34750265igb.46.1415734440961; Tue, 11 Nov 2014 11:34:00 -0800 (PST) Received: from x-160-94-246-194.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:e583:488f:13ce:a9ba]) by mx.google.com with ESMTPSA id nj17sm1020022igb.5.2014.11.11.11.33.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:33:59 -0800 (PST) Message-ID: <546264A5.4050309@umn.edu> Date: Tue, 11 Nov 2014 13:33:57 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> In-Reply-To: <5461A23D.5020506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_ebPKQtvIsYGH7uyHvuQLB9g1YA Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 19:34:33 -0000 On 11/10/14, 23:44 , Brian E Carpenter wrote: > This is intended to incorporate the result of today's discussion. > Please let the authors know if we got it wrong. > > Brian I wasn't at the IETF Meeting so I don't know if you have the correct result from that discussion. However, I believe the result is consistent with my understanding of the consensus on the v6ops list. Further, I support deprecation of Anycast 6to4, and the general take of the Draft. But, I feel the Draft should also either update or replace RFC6343. Minimally, I think it is important for there to be a metadata linkage between RFC6343 and the Draft. I would suggest a formal update to Section 4 of RFC6343 substituting the use of Router 6to4 in place of Anycast 6to4. Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as the IPv4 source address for Return Relay traffic, this no longer seem appropriate with the deprecation of 192.88.99.1, the prefix 192.88.99.0/24, and Anycast 6to4 in general. The 6th paragraph of Section 4 of the Draft discusses Return Relays and references Section 4.5 of RFC6343, I believe the intent is that "content providers might choose to continue operating such a relay", but I think the recommendation regarding the use of 192.88.99.1 as the IPv4 source address of such traffic, contained in Section 4.5 of RFC6343 could be confusing and is no longer appropriate. The draft says RFC6890 should be updated to remove "the 6to4 relay anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be updated. RFC68980 created "Special-Purpose IP Address Registries", no update to the RFC is necessary, IANA only needs to update the appropriate registry, which is already requested in section 5. You may want to specifically call out the appropriate registry "IPv4 Special-Purpose Address Registry" in section 5, but there is no need to update RFC6890. 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 11 12:22:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921A01A1B5E for ; Tue, 11 Nov 2014 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 5pUGDeX_hIo0 for ; Tue, 11 Nov 2014 12:22:00 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C726B1A88C3 for ; Tue, 11 Nov 2014 12:21:55 -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 sABKLt7g023997; Tue, 11 Nov 2014 12:21:55 -0800 Received: from XCH-BLV-206.nw.nos.boeing.com (xch-blv-206.nw.nos.boeing.com [10.57.37.16]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sABKLmh4023475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 11 Nov 2014 12:21:48 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.169]) with mapi id 14.03.0210.002; Tue, 11 Nov 2014 12:21:46 -0800 From: "Templin, Fred L" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt Thread-Index: AQHP/XKY5DZQl323D0+A8e1MQXithJxb3Hrw Date: Tue, 11 Nov 2014 20:21:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D8366D@XCH-BLV-504.nw.nos.boeing.com> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> In-Reply-To: <5461A23D.5020506@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FratHM4Iecu7TbE73HdCvlGBvbs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 20:22:04 -0000 Hi Brian, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Monday, November 10, 2014 9:44 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt >=20 > This is intended to incorporate the result of today's discussion. > Please let the authors know if we got it wrong. It looks like you are not intending to include a section on candidate 6to4 replacements then (we had some discussion on those on the list). If there will be a consideration for replacements, I would like to add ip-proto-44 encapsulation to the list, i.e., tunneling over IPv6 Fragment Header. By th= at, I mean IPv6-in-IPv6FH-in-IPv4 encapsulation. I talk about this in a new dra= ft on "AERO Minimal Encapsulation": https://datatracker.ietf.org/doc/draft-templin-aeromin/ Note that in a "compressed" format not all packets need to include the IPv6 FH, though. In that case, these "compressed" packets would look just like ip-proto-41. Thanks - Fred fred.l.templin@boeing.com From nobody Tue Nov 11 12:29:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671331A90D5 for ; Tue, 11 Nov 2014 12:29:26 -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 fkkyghpINVvu for ; Tue, 11 Nov 2014 12:29:22 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE1D1A016F for ; Tue, 11 Nov 2014 12:29:22 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id h11so2818989wiw.6 for ; Tue, 11 Nov 2014 12:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kD0FZMXXMHIi2SshkTSr2t7aXDfwdJ8NjEhIvPyarqw=; b=q6N0kHqOGpwDOilDFpFnD8UXhr45ySZ7vmJvwN4rGORUpwtwGdxUgjzjNUGVCeaYt1 TShoHKjjeS0nCORVCZCN8tCrr/Sd5cObdxqM1brNka/VRsoQSobmeEe706jI6wCDI0M9 wxNVIpOzc0fwSNrNCUYZGg1Legj7omGq2NPZh650XkbzkvjlleLSs1k0SfcUuQ7qJgR2 MoOIusr71xMkLcJuwaO55eW+Ww6sB4raTNtHqrSIpn3hndtYQCajU9nwo6BZNXnTYX2A W6wZTqWlyrKbpVo1AkpejJ0dAy2cj6Lv9wQ/k4HAwwmgZLneC0CIqO6wsGW90dXiHkBd KJYg== X-Received: by 10.180.75.116 with SMTP id b20mr42942630wiw.49.1415737761060; Tue, 11 Nov 2014 12:29:21 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id f7sm18891929wiz.13.2014.11.11.12.29.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 12:29:20 -0800 (PST) Message-ID: <546271A2.907@gmail.com> Date: Wed, 12 Nov 2014 09:29:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> In-Reply-To: <546264A5.4050309@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SI82kUwbKpz6JQcOkYxIz8zREx4 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 20:29:26 -0000 Hi David, Thanks for the comments - see below. On 12/11/2014 08:33, David Farmer wrote: > On 11/10/14, 23:44 , Brian E Carpenter wrote: >> This is intended to incorporate the result of today's discussion. >> Please let the authors know if we got it wrong. >> >> Brian > > I wasn't at the IETF Meeting so I don't know if you have the correct > result from that discussion. However, I believe the result is > consistent with my understanding of the consensus on the v6ops list. > Further, I support deprecation of Anycast 6to4, and the general take of > the Draft. > > But, I feel the Draft should also either update or replace RFC6343. > Minimally, I think it is important for there to be a metadata linkage > between RFC6343 and the Draft. I would suggest a formal update to > Section 4 of RFC6343 substituting the use of Router 6to4 in place of > Anycast 6to4. 6343 is non-normative, so I'm not sure that we need to formally update it. Also I don't agree that we should *encourage* people to apply the Router 6to4 scenario (which has been essentially ignored by the market for 13 years). But you are correct that some of the guidelines in 6343 might be taken as a positive recommendation to run an anycast relay, so how about adding this: "The guidelines in Section 4 of [RFC6343] remain valid only for those who choose to continue operating Anycast 6to4 despite its deprecation." > Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as > the IPv4 source address for Return Relay traffic, this no longer seem > appropriate with the deprecation of 192.88.99.1, the prefix > 192.88.99.0/24, and Anycast 6to4 in general. The 6th paragraph of > Section 4 of the Draft discusses Return Relays and references Section > 4.5 of RFC6343, I believe the intent is that "content providers might > choose to continue operating such a relay", but I think the > recommendation regarding the use of 192.88.99.1 as the IPv4 source > address of such traffic, contained in Section 4.5 of RFC6343 could be > confusing and is no longer appropriate. Why? Setting 192.88.99.1 as a *source* address is orthogonal to whether it's filtered by the routing system as a destination. It's pretty much harmless. > The draft says RFC6890 should be updated to remove "the 6to4 relay > anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be > updated. RFC68980 created "Special-Purpose IP Address Registries", no > update to the RFC is necessary, IANA only needs to update the > appropriate registry, which is already requested in section 5. You may > want to specifically call out the appropriate registry "IPv4 > Special-Purpose Address Registry" in section 5, but there is no need to > update RFC6890. Table 10 of 6890 explicitly mentions 192.88.99.0/24, so I think it does need to be updated. Actually we could do it right here in the draft by adding "Updates: 6890" and specifying that Table 10 is deleted. We do need to improve the IANA Considerations wording on that point, too. Regards Brian From nobody Tue Nov 11 12:34:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C981A9133 for ; Tue, 11 Nov 2014 12:34:40 -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 y1ImCiaE34mV for ; Tue, 11 Nov 2014 12:34:38 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086ED1A9125 for ; Tue, 11 Nov 2014 12:34:31 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so1710814wgg.7 for ; Tue, 11 Nov 2014 12:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HpXZtWPqXaB3ppB2UQ5YX/FdEMyLludNneEzOJO1pcY=; b=0+mtBTrMivOvIoihb9RUnPnz/qIYhTYgzF7DcO8rzSuZ+28a9Ve8Uslx5xv6GSoJ2n 3Z4eiWy4KKWWvtiRMnOepaoj9Fu5OB7DF3E8G8LoF+lq1M1MiHBNA/aGmX1jzaOvFIoP yIbGJ3/NYzu9T58ItaoPvu7VwA1k/jINm1gepRBHqZBcue5hV4PmBKRDnVpTNCCQAhZn YUP3WQHJbfmiNfmq665WBdTXOWYExNeuRMtG7DQwweGDSQYqv5nUB/6pS/up9GBMxGXq 89ate2PBV9W72YY5PwyUJV15QIBeSuV7opYaw3svMK4X9MNxwzRGhAtNNJswOBXrEpzj zSjQ== X-Received: by 10.194.71.6 with SMTP id q6mr56911131wju.98.1415738069863; Tue, 11 Nov 2014 12:34:29 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id v10sm18895756wiy.21.2014.11.11.12.34.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 12:34:29 -0800 (PST) Message-ID: <546272D7.9090208@gmail.com> Date: Wed, 12 Nov 2014 09:34:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <2134F8430051B64F815C691A62D9831832D8366D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D8366D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lyhYTfrdDQB80Ba8iPu1mkyBBm0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 20:34:40 -0000 On 12/11/2014 09:21, Templin, Fred L wrote: > Hi Brian, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Monday, November 10, 2014 9:44 PM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt >> >> This is intended to incorporate the result of today's discussion. >> Please let the authors know if we got it wrong. > > It looks like you are not intending to include a section on candidate 6to4 > replacements then (we had some discussion on those on the list). That was the message I got (i.e. discussing alternatives is out of scope for *this* document). Brian If there > will be a consideration for replacements, I would like to add ip-proto-44 > encapsulation to the list, i.e., tunneling over IPv6 Fragment Header. By that, > I mean IPv6-in-IPv6FH-in-IPv4 encapsulation. I talk about this in a new draft > on "AERO Minimal Encapsulation": > > https://datatracker.ietf.org/doc/draft-templin-aeromin/ > > Note that in a "compressed" format not all packets need to include the > IPv6 FH, though. In that case, these "compressed" packets would look just > like ip-proto-41. > > Thanks - Fred > fred.l.templin@boeing.com > From nobody Tue Nov 11 12:56:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018FB1AC3CC for ; Tue, 11 Nov 2014 12:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 McHp5oPp_xPz for ; Tue, 11 Nov 2014 12:56:44 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9401A1A70 for ; Tue, 11 Nov 2014 12:56:44 -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 sABKuiUk016419; Tue, 11 Nov 2014 12:56:44 -0800 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sABKuhkn016410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 11 Nov 2014 12:56:43 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.151]) with mapi id 14.03.0210.002; Tue, 11 Nov 2014 12:56:43 -0800 From: "Templin, Fred L" To: Brian E Carpenter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt Thread-Index: AQHP/XKY5DZQl323D0+A8e1MQXithJxb3HrwgACMh4D//3+IUA== Date: Tue, 11 Nov 2014 20:56:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D83873@XCH-BLV-504.nw.nos.boeing.com> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <2134F8430051B64F815C691A62D9831832D8366D@XCH-BLV-504.nw.nos.boeing.com> <546272D7.9090208@gmail.com> In-Reply-To: <546272D7.9090208@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: http://mailarchive.ietf.org/arch/msg/v6ops/ySN6Szbqlt9WTHs_qZ7oqCaanEg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 20:56:46 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDExLCAyMDE0IDEyOjM1IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVk IEwNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYy0wNy50eHQNCj4gDQo+IE9uIDEy LzExLzIwMTQgMDk6MjEsIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBIaSBCcmlhbiwNCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRl cg0KPiA+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDEwLCAyMDE0IDk6NDQgUE0NCj4gPj4gVG86 IHY2b3BzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYy0wNy50eHQNCj4gPj4NCj4gPj4gVGhpcyBp cyBpbnRlbmRlZCB0byBpbmNvcnBvcmF0ZSB0aGUgcmVzdWx0IG9mIHRvZGF5J3MgZGlzY3Vzc2lv bi4NCj4gPj4gUGxlYXNlIGxldCB0aGUgYXV0aG9ycyBrbm93IGlmIHdlIGdvdCBpdCB3cm9uZy4N Cj4gPg0KPiA+IEl0IGxvb2tzIGxpa2UgeW91IGFyZSBub3QgaW50ZW5kaW5nIHRvIGluY2x1ZGUg YSBzZWN0aW9uIG9uIGNhbmRpZGF0ZSA2dG80DQo+ID4gcmVwbGFjZW1lbnRzIHRoZW4gKHdlIGhh ZCBzb21lIGRpc2N1c3Npb24gb24gdGhvc2Ugb24gdGhlIGxpc3QpLg0KPiANCj4gVGhhdCB3YXMg dGhlIG1lc3NhZ2UgSSBnb3QgKGkuZS4gZGlzY3Vzc2luZyBhbHRlcm5hdGl2ZXMgaXMgb3V0IG9m IHNjb3BlIGZvcg0KPiAqdGhpcyogZG9jdW1lbnQpLg0KDQpNYXliZSB3ZSBzaG91bGQganVzdCBw dXQgIk9ic29sZXRlcyBSRkMzMDU2LCBSRkMzMDY4IiBpbiB0aGUgaGVhZGVyIG9mIEFFUk8/DQoN ClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAgICBCcmlhbg0K PiANCj4gSWYgdGhlcmUNCj4gPiB3aWxsIGJlIGEgY29uc2lkZXJhdGlvbiBmb3IgcmVwbGFjZW1l bnRzLCBJIHdvdWxkIGxpa2UgdG8gYWRkIGlwLXByb3RvLTQ0DQo+ID4gZW5jYXBzdWxhdGlvbiB0 byB0aGUgbGlzdCwgaS5lLiwgdHVubmVsaW5nIG92ZXIgSVB2NiBGcmFnbWVudCBIZWFkZXIuIEJ5 IHRoYXQsDQo+ID4gSSBtZWFuIElQdjYtaW4tSVB2NkZILWluLUlQdjQgZW5jYXBzdWxhdGlvbi4g SSB0YWxrIGFib3V0IHRoaXMgaW4gYSBuZXcgZHJhZnQNCj4gPiBvbiAiQUVSTyBNaW5pbWFsIEVu Y2Fwc3VsYXRpb24iOg0KPiA+DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdGVtcGxpbi1hZXJvbWluLw0KPiA+DQo+ID4gTm90ZSB0aGF0IGluIGEgImNvbXByZXNz ZWQiIGZvcm1hdCBub3QgYWxsIHBhY2tldHMgbmVlZCB0byBpbmNsdWRlIHRoZQ0KPiA+IElQdjYg RkgsIHRob3VnaC4gSW4gdGhhdCBjYXNlLCB0aGVzZSAiY29tcHJlc3NlZCIgcGFja2V0cyB3b3Vs ZCBsb29rIGp1c3QNCj4gPiBsaWtlIGlwLXByb3RvLTQxLg0KPiA+DQo+ID4gVGhhbmtzIC0gRnJl ZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0K From nobody Tue Nov 11 13:15:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4C1ACDC5 for ; Tue, 11 Nov 2014 13:15:03 -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 A_jS_tocT6EA for ; Tue, 11 Nov 2014 13:15:02 -0800 (PST) Received: from pacdcmhout01.cable.comcast.com (unknown [68.87.31.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0821ACDC4 for ; Tue, 11 Nov 2014 13:15:02 -0800 (PST) X-AuditID: 44571fa7-f79716d000006a1f-0b-54627c5577a7 Received: from pacdcexhub04.cable.comcast.com (pacdcexhub04.cable.comcast.com [24.40.56.121]) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id FB.5C.27167.55C72645; Tue, 11 Nov 2014 16:15:01 -0500 (EST) Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.113]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.03.0181.006; Tue, 11 Nov 2014 16:15:01 -0500 From: "Brzozowski, John" To: "v6ops@ietf.org" Thread-Topic: Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) Thread-Index: AQHP/fSJrP3CwUnyzUKuknaVNLjrwA== Date: Tue, 11 Nov 2014 21:15:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="utf-8" Content-ID: <85E86B6F659B6D469B0DF9902B101709@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUioWFRqRtakxRi0HDAwuL0sb3MDoweS5b8 ZApgjOK2SUosKQvOTM/Tt0vgznjYN52t4B9fRc/EuAbGM3xdjJwcEgImEq+3rmGHsMUkLtxb z9bFyMUhJHCTUWL67HXMIAkhgUOMEpc3ZIHYbAI2Eq8//GQEsUUEVCVOP70MViMskCJxb8l7 Foh4pkTP2QtsELaexPyvW4FqODhYgOpP9WSAhHkF7CXWTt0KVs4ItPf7qTVMIDazgLjErSfz mSDuEZBYsuc8M4QtKvHy8T9WEFsUaOS8h6/YIOIKEr9n/mMCGc8soCmxfpc+xBgHieWv5rBA 2IoSU7ofskOsFZQ4OfMJywRG0VlIts1C6J6FpHsWku5ZSLoXMLKuYpQrSExOSc7NyC8tMTDU S05MyknVS87PTU4sLgHRmxiBceMSLr98B+O9F06HGAU4GJV4eDX8E0OEWBPLiitzgUHKwawk wssQlhQixJuSWFmVWpQfX1Sak1p8iFGag0VJnFd5gVeIkEB6YklqdmpqQWoRTJaJgxOkm0tK pDg1LyW1KLG0JCMeFNPxxcColmpgPCKgzVoo1jqHa5lYa7Nxz/mZKnbiPDENW8JMs3YtuHS5 Y1dAUnzlV4my6r9mMk+4Htw9KXDjjQZXLJ+OeJFj37Rbl57deRdq/FKDbbaK8r71+dvXtTys 8fxrIfHMbbvdB68X7sfj+MufVeaqCGuYZLlPv+f92GnGyo2rZB40e4v2iz05qtCvxFKckWio xVxUnAgAQ6F2QrICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0YstS4w7A7zS0nfeBWSlYL9d_bc Subject: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 21:15:03 -0000 Q29tY2FzdCBkZXBsb3llZCA2dG80IHJlbGF5cyBzZXZlcmFsIHllYXJzIGFnbywgb3VyIHJlbGF5 cyByZW1haW4gYWN0aXZlDQp0b2RheS4gIE92ZXIgdGhlIHllYXJzIHRyYWZmaWMgaGFzIGRlY3Jl YXNlZCBzaWduaWZpY2FudGx5LiAgSSB3aWxsIHNlZSBpZg0KSSBjYW4gZGlnIHVwIHRyYWZmaWMg dHJlbmRzIG92ZXIgdGhlIHBhc3QgY291cGxlIG9mIHllYXJzLiAgSWYgSSBjYW4gSQ0Kd2lsbCBz ZW5kIHRoZW0gdG8gdGhlIGxpc3QuDQoNCldlIGludGVuZCB0byBvcGVyYXRlIHRoZXNlIHJlbGF5 cyB1bnRpbCB0aGVyZSBpcyBsaXR0bGUgdG8gbm8gNnRvNCB0cmFmZmljDQpvbiBvdXIgbmV0d29y ay4gIFRoZSByZWxheXMgd2VyZSBkZXBsb3llZCBsYXJnZWx5IHRvIGVuc3VyZSB0aGF0IGN1c3Rv bWVycw0KdXNpbmcgNnRvNCwgZWl0aGVyIG9uIHB1cnBvc2Ugb3IgYnkgYWNjaWRlbnQsIGhhdmUg YSByZWFzb25hYmxlDQpleHBlcmllbmNlLiAgV2UgYnkgbm8gbWVhbnMgd2FudCBvdXIgY3VzdG9t ZXJzIHRvIHVzZSA2dG80LCBpbiBmYWN0LCB3ZQ0Kd291bGQgcHJlZmVyIHRoYXQgdGhleSBub3Qg dXNlIElQdjYgYXQgYWxsIGlmIDZ0bzQgaXMgdGhlaXIgb25seSBvcHRpb24uDQoNClRocm91Z2hv dXQgdGhpcyB5ZWFyIHRoZXJlIHdlcmUgc29tZSBlZGdlIGNhc2VzIHJlbGF0ZWQgdG8gNnRvNCB0 aGF0DQpyZXF1aXJlZCBvdXIgYXR0ZW50aW9uLCBtZWFuaW5nIGlzc3VlcyB3ZXJlIHJlcG9ydGVk IHJlbGF0ZWQgdG8gdGhlIHVzZSBvZg0KNnRvNC4gIFRoaXMgaXMgbm90IGFuIGlkZWFsIHVzZSBv ZiBlbmdpbmVlcmluZyB0aW1lIGFuZCBlbmVyZ3kuICBJIGFncmVlDQp3aXRoIGEgc3RhdGVtZW50 IHRoYXQgTWlrYWVsIEFicmFoYW1zc29uIG1hZGUgYXQgdGhlIG1pY3JvcGhvbmUgZHVyaW5nDQpJ RVRGOTEsIHdlIHNob3VsZCBzdHJpdmUgdG8gZW50aXJlbHkgcmV0aXJlIHRoZSB1c2Ugb2YgNnRv NCBhbmQgSSBzZWUgbm8NCnZhbHVlIGluIHJlcGxhY2luZyA2dG80LiAgVGhpcyBhZ2FpbiBpcyBm cm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBhbg0Kb3BlcmF0b3IgdGhhdCBoYXMgYW4gZXh0ZW5zaXZl IG5hdGl2ZSBJUHY2IGRlcGxveW1lbnQgYW5kIGFjdGl2ZWx5DQpkZXBsb3llZCA2dG80IHJlbGF5 cy4NCg0KSWYgcHJlc3NlZCB0byBkbyBzb21ldGhpbmcgSSB3b3VsZCBzb29uZXIgcHJlZmVyIHRo YXQgNnRvNCBiZSByZXBsYWNlZA0Kd2l0aCA2cmQuICBGaW5hbGx5LCBJIGp1c3QgZG8gbm90IHNl ZSB0aGUgdmFsdWUgaW4gZXhwZW5kaW5nIHY2b3BzIFdHIHRpbWUNCmFuZCBlbmVyZ3kgb24gdGhl IHRvcGljIG9mIHJlcGxhY2luZyA2dG80LiAgV2UgaGF2ZSBwbGVudHkgb2YgZm9yd2FyZA0KbG9v a2luZyB3b3JrIHRvIHB1cnN1ZS4NCg0KSm9obg0KDQo= From nobody Tue Nov 11 13:20:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3D91ACDC5 for ; Tue, 11 Nov 2014 13:20:25 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeMGFKUJDUtI for ; Tue, 11 Nov 2014 13:20:22 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B164F1ACE08 for ; Tue, 11 Nov 2014 13:20:22 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id CC1B61003A8FE; Tue, 11 Nov 2014 21:20:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415740818; bh=D0PQdLh3UXSIJcxO/ZayiC1zNPmhyd1e1YaOIJ50rjI=; h=Date:From:To:Subject:References:In-Reply-To; b=SYC1+J0+IebArABRHb1UPfltV+Jjh4bi0X4++Tw/LawnySjv3Gv+kivWMvcrULHwm p5Wv2OAjhujRX88vMyAeRrLgk7tCutjjxpDsBHo5CkKmROZDJIZJ73EIE013P+s2FN WnoPaTNtIIioXi5z7f1frB9uNIpgdKM1RlrNxxQLo4g/xfCipsO22N6PiZg118FJSD EruNri47OW1uUq3D0A9g1oQzWFjsJmHg2jBQkHVFP35aBpfvFpEPPp84uytidnSLau T0LYOQdlAk4FZ4Dqjl0FmITKOXo3Icm5pCGYU4Nq3xp7NjUfXCyo8Qt7lcFE0O01KE 9ddpp4llr0EIQ== Message-ID: <54627D90.1060901@massar.ch> Date: Tue, 11 Nov 2014 22:20:16 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Brzozowski, John" , "v6ops@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zbg5nrph5h4mP7ZaqGUu9DLT3a0 Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 21:20:25 -0000 On 2014-11-11 22:15, Brzozowski, John wrote: > Comcast deployed 6to4 relays several years ago, our relays remain active > today. Over the years traffic has decreased significantly. I will see if > I can dig up traffic trends over the past couple of years. If I can I > will send them to the list. > > We intend to operate these relays until there is little to no 6to4 traffic > on our network. The relays were deployed largely to ensure that customers > using 6to4, either on purpose or by accident, have a reasonable > experience. We by no means want our customers to use 6to4, in fact, we > would prefer that they not use IPv6 at all if 6to4 is their only option. > > Throughout this year there were some edge cases related to 6to4 that > required our attention, meaning issues were reported related to the use of > 6to4. This is not an ideal use of engineering time and energy. I agree > with a statement that Mikael Abrahamsson made at the microphone during > IETF91, we should strive to entirely retire the use of 6to4 and I see no > value in replacing 6to4. This again is from the perspective of an > operator that has an extensive native IPv6 deployment and actively > deployed 6to4 relays. I'll add my note to that too. Indeed, 6to4 served it's purpose. > If pressed to do something I would sooner prefer that 6to4 be replaced > with 6rd. They have a completely different target group and 6rd properly stands on it's own. Hence, IMHO, just marking the end of 6to4 is a good thing. > Finally, I just do not see the value in expending v6ops WG time > and energy on the topic of replacing 6to4. We have plenty of forward > looking work to pursue. Fully agree. Greets, Jeroen From nobody Tue Nov 11 13:52:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3301A00FA for ; Tue, 11 Nov 2014 13:52:52 -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 zyeRivg5VuZ3 for ; Tue, 11 Nov 2014 13:52:51 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01621A0039 for ; Tue, 11 Nov 2014 13:52:50 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so12672289wgh.29 for ; Tue, 11 Nov 2014 13:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nmT6K+9iUNhW85GiK7bwbvvD9KBSmfuXGcHsBPmQpj0=; b=IVMrnRxy6BKitWnLgy5aK7JUvM/Z9IL50rCx4Lurm6YbQ/rwFeytMnLGSJ9TyZusUs z2xyado0TJI9vv9E3/lYTU9JSCZgAWVtej+DuV6srEnzr+sNbhA6qMzo9KQcVJvCrEoq bS1snPVqN3GQoLnr3JzPpkp5FyQVrJHBHAKX/ilRICdLruA/tEXyVjA+p8LkSvxjivOe 4UuZDZNLqHDTmfxKh7v+gZsXAVzKG2U2Xw0Lz8lXuxyhLuoXk5u6/Op3DfcyYZ+YGmJv uA/ITsGZ/pfnTPh3n9mgklTYxZm8jWVFMOK0Xo2a5fQ1gGGPC0m94xRekbrbX0kLgyrV zChQ== X-Received: by 10.180.74.201 with SMTP id w9mr43815158wiv.17.1415742769617; Tue, 11 Nov 2014 13:52:49 -0800 (PST) Received: from [130.129.10.183] ([130.129.10.183]) by mx.google.com with ESMTPSA id q10sm28904785wjq.35.2014.11.11.13.52.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 13:52:48 -0800 (PST) Message-ID: <54628533.1010206@gmail.com> Date: Wed, 12 Nov 2014 10:52:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Brzozowski, John" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QSKykxpK54ukhnLiLCSxMchB4DI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 21:52:52 -0000 John, I don't see any inconsistency between what you write and what the draft says. Please correct me if I'm wrong. Regards Brian On 12/11/2014 10:15, Brzozowski, John wrote: > Comcast deployed 6to4 relays several years ago, our relays remain active > today. Over the years traffic has decreased significantly. I will see if > I can dig up traffic trends over the past couple of years. If I can I > will send them to the list. > > We intend to operate these relays until there is little to no 6to4 traffic > on our network. The relays were deployed largely to ensure that customers > using 6to4, either on purpose or by accident, have a reasonable > experience. We by no means want our customers to use 6to4, in fact, we > would prefer that they not use IPv6 at all if 6to4 is their only option. > > Throughout this year there were some edge cases related to 6to4 that > required our attention, meaning issues were reported related to the use of > 6to4. This is not an ideal use of engineering time and energy. I agree > with a statement that Mikael Abrahamsson made at the microphone during > IETF91, we should strive to entirely retire the use of 6to4 and I see no > value in replacing 6to4. This again is from the perspective of an > operator that has an extensive native IPv6 deployment and actively > deployed 6to4 relays. > > If pressed to do something I would sooner prefer that 6to4 be replaced > with 6rd. Finally, I just do not see the value in expending v6ops WG time > and energy on the topic of replacing 6to4. We have plenty of forward > looking work to pursue. > > John > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 11 14:14:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59EB1AD029 for ; Tue, 11 Nov 2014 14:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdSnQtXpNrg8 for ; Tue, 11 Nov 2014 14:14:33 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9BB1A1AF4 for ; Tue, 11 Nov 2014 14:14:33 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so362788vcb.35 for ; Tue, 11 Nov 2014 14:14:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6x1b2L74mHQhdALBaNfmCoaI64YUEUNIxylvfF2MJ/0=; b=OHgD4+ZnzAsO1yet+CHXL69wNjH6aJUgbh5moU7TnMwoCrAIMWZHOFr61JdixtLGlI LSsF+fGZfWB662f/6RuXclzzGkar8wkH6E+JtR86V/ezIGK+v1mX/oxFIQ6Swj/SCTTF o3zhRfDZ3Jmh+0oHdbGqnzV6bJqUEek+FzwCM0YqqS3bF/k0Km/mLYT5Qlvs9Rj6Dh2r mbeE0tL3dILTJm+G2zVP1arQy9P7QdCz/hS96dv0pMkjMWfOBCrOp7V0KUp/vAoZawVc uXBlmbCP8sEvhI6pdtPvY9fearSLI462cNbfiagoMMxVpoIoKoqYyGE4xu8OVZqimYhE Zh4w== X-Gm-Message-State: ALoCoQnyc17YUPG/xB3OrhibDX8w5VzAuh69Zwv0UEFbceLHlwhtduTD6FL5NbQ8hU+FdqK2TsqY MIME-Version: 1.0 X-Received: by 10.220.188.201 with SMTP id db9mr30191400vcb.10.1415744072305; Tue, 11 Nov 2014 14:14:32 -0800 (PST) Received: by 10.31.10.65 with HTTP; Tue, 11 Nov 2014 14:14:32 -0800 (PST) In-Reply-To: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> Date: Tue, 11 Nov 2014 12:14:32 -1000 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c1bda285e25905079c9a6d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sLm3nbrGE88DbCHDWiSuq6tGqss Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 22:14:37 -0000 --001a11c1bda285e25905079c9a6d Content-Type: text/plain; charset=UTF-8 My comment is not an objection to this draft. I am generally supportive of this draft. I have only one comment, which I suppose *might* rise to the level of a "complaint" if it were shared by a significant fraction of other participants, which is simply this: we are retaining RFC 3056 on the Standards Track, and we are considering an RFC that advises content providers that supporting 6to4 users with return relays to 2002::/16, maybe even new ones that aren't currently there, is consistent with Best Current Practice, but we are not advising anyone else that maybe new deployment of return relays to 2002::/16 is an idea worth reviewing. Why not? Some obvious places to locate a 6to4 return relay spring immediately to mind, e.g. wherever there is a NAT64 gateway, e.g. in dual-stack customer edge routers with interfaces numbered with public IPv4 addresses. Anyplace where an IPv6-only host might be reachable from a host using RFC 3056 (and not RFC 3068) to get IPv6 packets into the IPv6-only world from some benighted place where it's the 21st century and still IPv4 is the only service available to them. If I were a content provider (oh wait! I work for one now!), then I might notice the fact this document singles me out for special attention and leaves unmolested all the other places where broken 6to4 return relay service might be just as noticeable to legitimate users of RFC 3056 who are using manually configured forward relay services. I might think to myself: hey, why do I need a 6to4 return relay in my network when nobody else has one, and IETF can't even be bothered to advise them that it's even worth thinking about? As I said above, this is not actually a complaint. It's just a comment, and if nobody pipes up with a "me too" observation, then that's fine. I don't have any significant objection to publishing this revision of the draft now. On Mon, Nov 10, 2014 at 7:40 PM, wrote: > > 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 : Deprecating Connection of IPv6 Domains via IPv4 > Clouds (6to4) > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-07.txt > Pages : 7 > Date : 2014-11-10 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet, > especially in its anycast mode. This document requests that RFC > 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete > and moved to historic status. It also recommends that future > products should not support 6to4 anycast and that existing > deployments should be reviewed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- james woodyatt Nest Labs, Communications Engineering --001a11c1bda285e25905079c9a6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My comment is not an objection to this draft. I am general= ly supportive of this draft.

I have only one comment, wh= ich I suppose *might* rise to the level of a "complaint" if it we= re shared by a significant fraction of other participants, which is simply = this: we are retaining RFC 3056 on the Standards Track, and we are consider= ing an RFC that advises content providers that supporting 6to4 users with r= eturn relays to 2002::/16, maybe even new ones that aren't currently th= ere, is consistent with Best Current Practice, but we are not advising anyo= ne else that maybe new deployment of return relays to 2002::/16 is an idea = worth reviewing. Why not?

Some obvious places to locate = a 6to4 return relay spring immediately to mind, e.g. wherever there is a NA= T64 gateway, e.g. in dual-stack customer edge routers with interfaces numbe= red with public IPv4 addresses.=C2=A0 Anyplace where an IPv6-only host migh= t be reachable from a host using RFC 3056 (and not RFC 3068) to get IPv6 pa= ckets into the IPv6-only world from some benighted place where it's the= 21st century and still IPv4 is the only service available to them.

If I were a content provider (oh wait! I work for one now= !), then I might notice the fact this document singles me out for special a= ttention and leaves unmolested all the other places where broken 6to4 retur= n relay service might be just as noticeable to legitimate users of RFC 3056= who are using manually configured forward relay services. I might think to= myself: hey, why do I need a 6to4 return relay in my network when nobody e= lse has one, and IETF can't even be bothered to advise them that it'= ;s even worth thinking about?

As I said above, thi= s is not actually a complaint. It's just a comment, and if nobody pipes= up with a "me too" observation, then that's fine. I don'= t have any significant objection to publishing this revision of the draft n= ow.


On Mon, Nov 10, 2014 at 7:40 PM, <= internet-draf= ts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ole = Troan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Carpenter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-6to4-to-historic-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-11-10

Abstract:
=C2=A0 =C2=A0Experience with the "Connection of IPv6 Domains via IPv4 = Clouds
=C2=A0 =C2=A0(6to4)" IPv6 transition mechanism has shown that the mech= anism is
=C2=A0 =C2=A0unsuitable for widespread deployment and use in the Internet,<= br> =C2=A0 =C2=A0especially in its anycast mode.=C2=A0 This document requests t= hat RFC
=C2=A0 =C2=A03068, "An Anycast Prefix for 6to4 Relay Routers", be= made obsolete
=C2=A0 =C2=A0and moved to historic status.=C2=A0 It also recommends that fu= ture
=C2=A0 =C2=A0products should not support 6to4 anycast and that existing
=C2=A0 =C2=A0deployments should be reviewed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6t= o4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-hist= oric-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6= ops-6to4-to-historic-07


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

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

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



--
james woodyatt <jhw@nestlabs.com>
Nest Labs,= Communications Engineering
--001a11c1bda285e25905079c9a6d-- From nobody Tue Nov 11 14:23:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804BF1A1C06 for ; Tue, 11 Nov 2014 14:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 h-ls15Os6RDk for ; Tue, 11 Nov 2014 14:23:01 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398EB1A1AF4 for ; Tue, 11 Nov 2014 14:23:01 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so12364526ieb.36 for ; Tue, 11 Nov 2014 14:23:00 -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=VWv5qTSnDQZaZPflb19DMy8ZIZDAq7ypoUYJ83HI8u8=; b=WydcamnWyqBI5DBPfwQikEgLTv6bMr4KS0EAIDy7ijGDX0Osnhr0VxjaTTpSDXEnLb U5uYhUNdYOIhHOvqGMaZjvpn+psJBEAmPT22so2IjzHcNAcXubp/MrBfcIPt4ejL4xJL hXlnBVGlQU5I9AjPxMfyPLP1LNSgSXccJ3Qgp2B06qtiSdcLU+NivTZ7zM+FcEsnyMxG jmoo2ZCRQsR+wDQYXz7W/VOvTl1Tq0dKvEXwqqUBYlC4Jvbb33SiNa0dtN6lUfwyRZ/r xow4DOr79vc39AXPL4QtoG6zFYwfzOd3nUjBE+fIdb+cW7a+R+zw5tZ6jo5JGeB5y8Z4 +HYA== 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=VWv5qTSnDQZaZPflb19DMy8ZIZDAq7ypoUYJ83HI8u8=; b=g9+R2m4lelWynAinboDwn2zF+5KFOqINY4gyVbIyL3mtCVhZjfy4TZ0FHruvFJcTMj WS/ue32ri5OVBU63Gi/i0I610b0G42QgeCOmbKvtuEzvHGjGIhDvJ/UCe122XDSX4AqZ oUyh9URfnJ1KZc4k2oV4lHsvGXwKSdv8hCaXr2DMXFVnDwELQVqU3dMQcLc7g+m7qG6d E0Tj0HLzk+SA9qCE8HHYxysRARVJwowiv8omROuU10cDDU71sRfYJXIH3sOr9mZN7TKz rAqooWnwnN0O7Yki3rBP3kxJS6Y4UYr4VUti9a1fqMKsh9Qdn/QX8okvW8nWpynjle4i hvlQ== X-Gm-Message-State: ALoCoQmPayEst5lB9j4OcTfxBF1NQPpMRITrSh/GMHxPzFYletGOHY+NyjpEiqEQ+RPe71xxTIBq X-Received: by 10.50.136.133 with SMTP id qa5mr35998217igb.2.1415744580151; Tue, 11 Nov 2014 14:23:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.126.233 with HTTP; Tue, 11 Nov 2014 14:22:39 -0800 (PST) In-Reply-To: References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 11 Nov 2014 12:22:39 -1000 Message-ID: To: James Woodyatt Content-Type: multipart/alternative; boundary=089e0141a76acb1e3905079cb8e0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K1qtZFCG5oIxSw30Y5lX5OfcmlA Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 22:23:05 -0000 --089e0141a76acb1e3905079cb8e0 Content-Type: text/plain; charset=UTF-8 But if you're a content provider, your stats would show that 6to4 traffic is ~ 0.01% of total traffic, and therefore, you might well choose not to optimize it (even to the extent of not having your own relays and using third-party relays), as long as it works reasonably well. On Tue, Nov 11, 2014 at 12:14 PM, James Woodyatt wrote: > My comment is not an objection to this draft. I am generally supportive of > this draft. > > I have only one comment, which I suppose *might* rise to the level of a > "complaint" if it were shared by a significant fraction of other > participants, which is simply this: we are retaining RFC 3056 on the > Standards Track, and we are considering an RFC that advises content > providers that supporting 6to4 users with return relays to 2002::/16, maybe > even new ones that aren't currently there, is consistent with Best Current > Practice, but we are not advising anyone else that maybe new deployment of > return relays to 2002::/16 is an idea worth reviewing. Why not? > > Some obvious places to locate a 6to4 return relay spring immediately to > mind, e.g. wherever there is a NAT64 gateway, e.g. in dual-stack customer > edge routers with interfaces numbered with public IPv4 addresses. Anyplace > where an IPv6-only host might be reachable from a host using RFC 3056 (and > not RFC 3068) to get IPv6 packets into the IPv6-only world from some > benighted place where it's the 21st century and still IPv4 is the only > service available to them. > > If I were a content provider (oh wait! I work for one now!), then I might > notice the fact this document singles me out for special attention and > leaves unmolested all the other places where broken 6to4 return relay > service might be just as noticeable to legitimate users of RFC 3056 who are > using manually configured forward relay services. I might think to myself: > hey, why do I need a 6to4 return relay in my network when nobody else has > one, and IETF can't even be bothered to advise them that it's even worth > thinking about? > > As I said above, this is not actually a complaint. It's just a comment, > and if nobody pipes up with a "me too" observation, then that's fine. I > don't have any significant objection to publishing this revision of the > draft now. > > > On Mon, Nov 10, 2014 at 7:40 PM, wrote: > >> >> 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 : Deprecating Connection of IPv6 Domains via IPv4 >> Clouds (6to4) >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-07.txt >> Pages : 7 >> Date : 2014-11-10 >> >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism has shown that the mechanism is >> unsuitable for widespread deployment and use in the Internet, >> especially in its anycast mode. This document requests that RFC >> 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete >> and moved to historic status. It also recommends that future >> products should not support 6to4 anycast and that existing >> deployments should be reviewed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > -- > james woodyatt > Nest Labs, Communications Engineering > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --089e0141a76acb1e3905079cb8e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But if you're a content provider, your stats would sho= w that 6to4 traffic is ~ 0.01% of total traffic, and therefore, you might w= ell choose not to optimize it (even to the extent of not having your own re= lays and using third-party relays), as long as it works reasonably well.
On Tue, Nov 11, 2014= at 12:14 PM, James Woodyatt <jhw@nestlabs.com> wrote:
My comment is not an objection= to this draft. I am generally supportive of this draft.

I have only one comment, which I suppose *might* rise to the level of a &q= uot;complaint" if it were shared by a significant fraction of other pa= rticipants, which is simply this: we are retaining RFC 3056 on the Standard= s Track, and we are considering an RFC that advises content providers that = supporting 6to4 users with return relays to 2002::/16, maybe even new ones = that aren't currently there, is consistent with Best Current Practice, = but we are not advising anyone else that maybe new deployment of return rel= ays to 2002::/16 is an idea worth reviewing. Why not?

So= me obvious places to locate a 6to4 return relay spring immediately to mind,= e.g. wherever there is a NAT64 gateway, e.g. in dual-stack customer edge r= outers with interfaces numbered with public IPv4 addresses.=C2=A0 Anyplace = where an IPv6-only host might be reachable from a host using RFC 3056 (and = not RFC 3068) to get IPv6 packets into the IPv6-only world from some benigh= ted place where it's the 21st century and still IPv4 is the only servic= e available to them.

If I were a content provider = (oh wait! I work for one now!), then I might notice the fact this document = singles me out for special attention and leaves unmolested all the other pl= aces where broken 6to4 return relay service might be just as noticeable to = legitimate users of RFC 3056 who are using manually configured forward rela= y services. I might think to myself: hey, why do I need a 6to4 return relay= in my network when nobody else has one, and IETF can't even be bothere= d to advise them that it's even worth thinking about?

As I said above, this is not actually a complaint. It's just a = comment, and if nobody pipes up with a "me too" observation, then= that's fine. I don't have any significant objection to publishing = this revision of the draft now.


On Mon, Nov 10, 2= 014 at 7:40 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ole = Troan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Carpenter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-6to4-to-historic-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-11-10

Abstract:
=C2=A0 =C2=A0Experience with the "Connection of IPv6 Domains via IPv4 = Clouds
=C2=A0 =C2=A0(6to4)" IPv6 transition mechanism has shown that the mech= anism is
=C2=A0 =C2=A0unsuitable for widespread deployment and use in the Internet,<= br> =C2=A0 =C2=A0especially in its anycast mode.=C2=A0 This document requests t= hat RFC
=C2=A0 =C2=A03068, "An Anycast Prefix for 6to4 Relay Routers", be= made obsolete
=C2=A0 =C2=A0and moved to historic status.=C2=A0 It also recommends that fu= ture
=C2=A0 =C2=A0products should not support 6to4 anycast and that existing
=C2=A0 =C2=A0deployments should be reviewed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6t= o4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-hist= oric-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6= ops-6to4-to-historic-07


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

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

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



<= font color=3D"#888888">--
james woodyatt <jhw@nestlabs.com><= div>Nest Labs, Communications Engineering

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


--089e0141a76acb1e3905079cb8e0-- From nobody Tue Nov 11 14:48:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE291A1C06 for ; Tue, 11 Nov 2014 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 pSM7pbEVzKoV for ; Tue, 11 Nov 2014 14:47:55 -0800 (PST) Received: from nm41-vm3.bullet.mail.ne1.yahoo.com (nm41-vm3.bullet.mail.ne1.yahoo.com [98.138.120.219]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8DF1A1BC4 for ; Tue, 11 Nov 2014 14:47:52 -0800 (PST) Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2014 22:47:51 -0000 Received: from [98.138.100.102] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2014 22:44:49 -0000 Received: from [66.196.81.170] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2014 22:44:49 -0000 Received: from [98.139.212.214] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 22:44:49 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 11 Nov 2014 22:44:49 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 525090.28162.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 69028 invoked by uid 60001); 11 Nov 2014 22:44:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1415745889; bh=439rTfNnMN33X+cnmNdEEtP/OhuUbCwE+ZAwSVdRKdI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uoObgGKFRKqPrhMPrvvDB+xm+mbHVvhm5p8z8SI+7GBEtSrfJqdWwPXPARNae5qhYReACL+3xlw6fsVZmDonS07VsVtTZ8yDC5f+xIiPmf1wDfTzgyQtb28eyIYfpMEE8lnfIZKZP5FWb4EwwDx3DWQLXANTNnodbLNiDOvs0XA= X-YMail-OSG: 2BWf_1IVM1nWM7CVPflawN3pGiKTaDQOa0sl6bwGQ2tlXHD A2SPXaCdtEYRANLFweh1zHA7XXL9myUTmihYafGG0Cf4M06_9SLPvkOPazLh xWXkN5sxn3Z9MY97PPXTlopQGKY.eRsApAB4YVzcQAY6U_uk63eFhYAWqsFx yi02cQFeCu3sHxeTz7yVKHUKMi2C8TkYLlJQhbXxdPs91y6q6nirtEXX059a t26izKWjHtRfvdf8JXe5Xi45uzzZZBfIP2Fs7JnxwbyLEF17Y_XP9j_iY1ey 5kRK.SwQLQzQm3_GScmP3owGcsiXfXvapAJDEsK4qzemxo39hT5ZyasLvTaf cfALicMrL9GNQdDp2zv7C8bCdtb4Szaqy3u6w0vpoSerI0W7Vsu4L3aeW1kT inhL6QC31deqpYC0zHN.Ocjb0DYsPz75PrcBc7fld47tHHLhwvfFA8PZ6656 f1hNVkC_bo90vCwffHvmFXnr4q2y5pUcIPzALYfcMEs8nAP8JFdNTyLZ47O2 XHAI6jDfb9Lig5GOqmtzpVZWuMHQyudLIfNpzZAVR2PE.maqTaWvlkvuddSi ya623i5YE1vJrDWE6gTNzBYg- Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Tue, 11 Nov 2014 14:44:49 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBKZXJvZW4gTWFzc2FyIDxqZXJvZW5AbWFzc2FyLmNoPgo.VG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.IAo.Q2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc.OyA2bWFuIDxpcHY2QGlldGYub3JnPiAKPlNlbnQ6IFR1ZXNkYXksIDExIE5vdmVtYmVyIDIwMTQsIDY6MDIKPlN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgTVRVIEZsb3ctbGFiZWwuLi4uIChyZWxhdGVkIHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> Message-ID: <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Tue, 11 Nov 2014 14:44:49 -0800 From: Mark ZZZ Smith To: Jeroen Massar , Brian E Carpenter In-Reply-To: <54610BD4.2070600@massar.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z1ktTUAlyU2uQetrRoOHHmjnlk0 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:47:57 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Jeroen Massar =0A>To: Brian E Carpenter =0A= >Cc: IPv6 Operations ; 6man =0A>Sent: Tuesd= ay, 11 November 2014, 6:02=0A>Subject: Re: [v6ops] IPv6 MTU Flow-label.... = (related to draft-v6ops-pmtud-ecmp-problem-01)=0A> =0A>=0A>On 2014-11-10 19= :57, Brian E Carpenter wrote:=0A>> Er, no, you really can't use the flow la= bel like that. RFC6437.=0A>=0A>Hence, redefining the bits :) Few implementa= tions use them anyway, thus=0A>we still have time to actually make good use= of them.=0A>=0A=0ASo the "flow label" then field name wouldn't then be acc= urate, because an MTU value doesn't identify or contribute to the identific= ation or labelling of a flow very well. There's a lot of troubleshooting an= d other value in "truth in advertising", or less clich=E9'd "accuracy in na= ming". Encoding non-flow labelling MTU information in that existing flow la= belling field would therefore be a hack (MTU might be an attribute of a flo= w, but it isn't very specific or unique to a flow) for this one special cas= e of stateless ECMP based load balancing. It wouldn't be useful in most or = perhaps all other IP use cases. (So if this idea gained more traction, I'd = start lobbying for the field to be renamed.)=0A=0AIt seems to me that the f= undamental issue is that given how the IP protocols work (as this problem a= lso occurs in IPv4), stateless ECMP isn't a very effective method of perfor= ming load balancing. While probably chosen for pure performance/throughput,= it isn't distributing load to the LB hosts based on their current load (so= it isn't actually 'balancing'), and because it isn't maintaining per-host = state, isn't able to perform per-host specific processing/forwarding, which= is what is needed for PMTUD to function in this scenario.=0A=0AThis/these = methods of load balancing have generally annoyed me for a while, primarily = because I have also had to troubleshoot or deal with these sorts of issues = in the past. I think the fundamental issue is that to the network, the unic= ast LB address is looks like a single unicast destination/host, where as in= reality is being shared by a number of hosts. While that might sound like = the anycast problem, I think the difference is that even though with anycas= t multiple addresses are shared between a set of hosts, for any particular = source host there is no variation in which of the anycast hosts is used ove= r time, unless it fails (i.e., the routing system would normally consistent= ly pick one of the anycast destinations for a particular source, as would I= Pv6's 'on-link' anycast method (see RFC7094 for more discussion)). In this = LB case the destination LB host changes based on changes in TCP or UDP port= s, which is occurring all of the time.=0A=0AIf high performance stateless a= nd therefore load insensitive LB distribution is needed or wanted, then per= haps something more simple that doesn't use TCP or UDP port information mig= ht be better. For example, using SA+DA based forwarding in the LB, and then= statically mapping portions of the SA address space to a particular LB hos= t (e.g., 1/4 to LB host a, 1/4 to LB host b etc. for four LB hosts), with a= ll LB hosts configured with the LB 'shared' unicast address (i.e., no NAT).= If you want anything smarter than that, then I think the LB needs to becom= e stateful, and start maintaining per-connection state.=0A=0A=0A>Note that = I am specifically proposing setting the first four bits to 1=0A>aka 0xf so = that the space can still be used for it's original intent too.=0A>=0A>> Wha= t you can do is use the flow label as intended, for ECMP or any=0A>> other = kind of load balancing. RFC6438, RFC7098. They don't fix the=0A>> ICMPv6 pr= oblem though.=0A>=0A>It won't fix the 1-RTT issue that worries content prov= iders either.=0A>=0A>That is the biggest problem for them: a ICMPv6 PTB is = an extra round=0A>trip and they want speed. Hence including the MTU already= in the packet.=0A>(though as noted in my reply, it won't work fully for as= ync networks)=0A>=0A>> The key sentence in Joel's draft is=0A>> =0A>>> B= ecause the PTB message is not identifiable as part of the=0A>>> original= flow by the packet header the results of the ICMPv6 ECMP=0A>>> hash are= unlikely to be hashed to the same nexthop as packets=0A>>> matching TCP= or UDP ECMP hash.=0A>> =0A>> To fix that, I suspect that flow label reflec= tion is needed.=0A>=0A>Won't work as that packet will not be matching the l= oadbalancers setup=0A>either.=0A>=0A>What would partially work is if the IC= MPv6 PTB would copy the flow-label=0A>from the original flow that caused th= e PTB.=0A>=0A>But then still, large content providers will not be happy, as= it does=0A>not satisfy the 1-RTT argument, which now causes them to just i= gnores=0A>PTBs and set the MSS to something tiny (thus in the end causing m= ore=0A>packets, but at least all packets will go through).=0A>=0A>=0A>=0A>= =0A>=0A>Greets,=0A>Jeroen=0A>=0A>__________________________________________= _____=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailm= an/listinfo/v6ops=0A>=0A>=0A>=0A> From nobody Tue Nov 11 15:25:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE01A6F64 for ; Tue, 11 Nov 2014 15:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 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_22=0.6, RP_MATCHES_RCVD=-0.594, 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 7Cyb71n7UKrD for ; Tue, 11 Nov 2014 15:25:24 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643BA1A6F56 for ; Tue, 11 Nov 2014 15:25:24 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so2094405iga.8 for ; Tue, 11 Nov 2014 15:25: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:date:message-id:subject:from:to :cc:content-type; bh=ouAnXMfD4mth7NHbgxeG9lNKs8Y+5LaOYIEzx9W0V1E=; b=iotWMK0uyRL2byBz1cC//2nlZb4gtD4KN/lPngVw35QDIdGbDaC4LK8r915p0wOihw UdtW3KAEwQmvGHIdKFIrg7Z/7hTde4QwTqRlTDcQZIDb2L2j612EgTp/Pw2KZFDIinyL c2VhRqv0l+6Iho76igBzc9MMxk+Y37anBL4tlFjlSR7jEFBQiHvs9qYh1U0tvEhQ2HVF +g2HS1BV8MYLl6PpN2/M+prFy/dVjI1cZw/D9tCPhdR5YGUl/PMl5U8YYKx8rXcDHk7J TnRPg17S7SvdvtOEBx+8FCbsOFtfV/jfw2iLmhi8rbuGG9rCztJu7aJjcvwOOp0zcoQc ttQw== 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=ouAnXMfD4mth7NHbgxeG9lNKs8Y+5LaOYIEzx9W0V1E=; b=Q0KzXrMcQRPCmc5hRxxX5Fsm/rY27sdeUYY5lKz8StLfwOGRzTyLTegj1qK3VaLL0h Efrh1VstUZJHfetPn2kdQOwoyqZsXs/IiHYRYC6CEtlS7pTe7BI53ASHSsgX02OwJTTF D+8WsltJajyBWQnFpB+k/z4ASY/TvlSMWMgO9P+DFqlFFNoJtFmYiF7K9jn6xcD0809m 4yj8A7C0rivWDA26fcCUaDSRRbfjYpp2Bbx3BuqItxdi66hpdP4vo34smbq7MW4Tc+ws x/ZwWRX7c5VikWM0A8n1v4734z44FUrm5ybUKeA7OCcsOpc/u6BvRqkk2OPymQoydnmv 8ECw== X-Gm-Message-State: ALoCoQlP7O+vvAMb3JhGzM6OX9i2vpCqtmJBeeorIMPK9KhEIbS1iPMJPUxqGS9j5ZC+6AckeiSg MIME-Version: 1.0 X-Received: by 10.43.143.18 with SMTP id jk18mr11116263icc.73.1415748323606; Tue, 11 Nov 2014 15:25:23 -0800 (PST) Received: by 10.64.126.233 with HTTP; Tue, 11 Nov 2014 15:25:23 -0800 (PST) Received: by 10.64.126.233 with HTTP; Tue, 11 Nov 2014 15:25:23 -0800 (PST) In-Reply-To: <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Tue, 11 Nov 2014 13:25:23 -1000 Message-ID: From: Lorenzo Colitti To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=001a11c2af94ebc68605079d97d1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ta40J0bm6-07VR1VT1mi4QsSPPE Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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, 11 Nov 2014 23:25:25 -0000 --001a11c2af94ebc68605079d97d1 Content-Type: text/plain; charset=UTF-8 On 11 Nov 2014 12:47 pm, "Mark ZZZ Smith" wrote: > If high performance stateless and therefore load insensitive LB distribution is needed or wanted, then perhaps something more simple that doesn't use TCP or UDP port information might be better. For example, using SA+DA based forwarding in the LB, and then statically mapping portions of the SA address space to a particular LB host (e.g., 1/4 to LB host a, 1/4 to LB host b etc. for four LB hosts), with all LB hosts configured with the LB 'shared' unicast address (i.e., no NAT). If you want anything smarter than that, then I think the LB needs to become stateful, and start maintaining per-connection state. The problem is not that the TCP/UDP port changes. The problem is that the source address of the intermediate router sending the PTB hashes differently than the source address of the client. So SA+DA only load-balancing won't help. --001a11c2af94ebc68605079d97d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 11 Nov 2014 12:47 pm, "Mark ZZZ Smith" <markzzzsmith@yahoo.com.au> wrote:
> If high performance stateless and therefore load insensitive LB distri= bution is needed or wanted, then perhaps something more simple that doesn&#= 39;t use TCP or UDP port information might be better. For example, using SA= +DA based forwarding in the LB, and then statically mapping portions of the= SA address space to a particular LB host (e.g., 1/4 to LB host a, 1/4 to L= B host b etc. for four LB hosts), with all LB hosts configured with the LB = 'shared' unicast address (i.e., no NAT). If you want anything smart= er than that, then I think the LB needs to become stateful, and start maint= aining per-connection state.

The problem is not that the TCP/UDP port changes. The proble= m is that the source address of the intermediate router sending the PTB has= hes differently than the source address of the client. So SA+DA only load-b= alancing won't help.

--001a11c2af94ebc68605079d97d1-- From nobody Tue Nov 11 15:33:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C581A7000 for ; Tue, 11 Nov 2014 15:33:27 -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 CpGzA-EOeSvg for ; Tue, 11 Nov 2014 15:33:25 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70E11A7017 for ; Tue, 11 Nov 2014 15:33:24 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so12820361wgh.20 for ; Tue, 11 Nov 2014 15:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SyP1OpgL4s6kKqi+it3O9ttacHu3D0+HVrqaPDfLcaY=; b=DKqCplIHXD2vw6Onjl2vv/W1dtCaHzJ5OIzWBneNXoiqa8WWBCkHN6si3ZtxrjMNOX yaO2gz6G8nEccTTiWr1FfTbNh4iXxtxWSMSqJlENX1EXiAFD51qNHjkaKyNUO/UYXz+Q lb02G12Cy96Z21UBKGoNNN3CHERVKsBqva1hn8S5uLo57KKPrGMH2qcQTNgTrGLjPiLE tQXWqn4UuJc9d9MmGDerr85vFCQ2SOM9TNZ+ThioypTY7hx34gcw10oF53VwVCRiyXKC VUYfziFtdF0Zux4hx24QMewMDKXJSoGRyqXxtT9e6MA8cU/RaRtAgAxFSXxi6EWIsABy kYyg== X-Received: by 10.180.91.227 with SMTP id ch3mr44360045wib.17.1415748803551; Tue, 11 Nov 2014 15:33:23 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id ci9sm19350595wid.24.2014.11.11.15.33.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 15:33:23 -0800 (PST) Message-ID: <54629CC5.7020405@gmail.com> Date: Wed, 12 Nov 2014 12:33:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: James Woodyatt References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4-6jaVPQgyHMwbNajVFGDjFc7_Q Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 11 Nov 2014 23:33:28 -0000 James, On 12/11/2014 11:14, James Woodyatt wrote: > My comment is not an objection to this draft. I am generally supportive of > this draft. > > I have only one comment, which I suppose *might* rise to the level of a > "complaint" if it were shared by a significant fraction of other > participants, which is simply this: we are retaining RFC 3056 on the > Standards Track, and we are considering an RFC that advises content > providers that supporting 6to4 users with return relays to 2002::/16, maybe > even new ones that aren't currently there, is consistent with Best Current > Practice, but we are not advising anyone else that maybe new deployment of > return relays to 2002::/16 is an idea worth reviewing. Why not? We are not rescinding RFC 6343, which is Informational, and does suggest some cases where an operator could usefully run a return relay. But that is a bit different from advocating new deployments in a BCP... > Some obvious places to locate a 6to4 return relay spring immediately to > mind, e.g. wherever there is a NAT64 gateway, I tried and tried and couldn't see the direct relevance of a NAT64. But there is a use case, which is at the boundary between an IPv6-only network and the IPv4 Internet (which is coincidentally the same place where you put a NAT64). > e.g. in dual-stack customer > edge routers with interfaces numbered with public IPv4 addresses. That is exactly the classical case described in RFC 3056, which we are not deprecating. > Anyplace > where an IPv6-only host might be reachable from a host using RFC 3056 (and > not RFC 3068) to get IPv6 packets into the IPv6-only world from some > benighted place where it's the 21st century and still IPv4 is the only > service available to them. Well, yes, the requirement is that there is a route to 2002::/16 that reaches a working return relay. That's why the draft now says "Internet service providers SHOULD announce the IPv6 prefix 2002::/16 if and only if it leads to a correctly operating return relay as described in RFC 6343." Is it really the job of this draft to suggest where that relay should be? There is a weakness in RFC 6343. In Section 4.3. "Consumer ISPs, and Enterprise Networks, That Do Support IPv6" it implicitly assumes that these are dual-stack networks. It would be better if it also offered guidelines for IPv6-only networks. There is indeed a case for such networks to operate a 2002::/16 return relay. But nobody made that point while 6343 was being developed... > > If I were a content provider (oh wait! I work for one now!), then I might > notice the fact this document singles me out for special attention and > leaves unmolested all the other places where broken 6to4 return relay > service might be just as noticeable to legitimate users of RFC 3056 who are > using manually configured forward relay services. I might think to myself: > hey, why do I need a 6to4 return relay in my network when nobody else has > one, and IETF can't even be bothered to advise them that it's even worth > thinking about? Content providers presumably have a strong interest in not losing client sessions. That's the reason they have their own section in 6343. But the current draft only mentions them once, and the following sentence is a rather stronger recommendation to ISPs. So I don't quite get your point. Brian > > As I said above, this is not actually a complaint. It's just a comment, and > if nobody pipes up with a "me too" observation, then that's fine. I don't > have any significant objection to publishing this revision of the draft now. > > > On Mon, Nov 10, 2014 at 7:40 PM, wrote: > >> 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 : Deprecating Connection of IPv6 Domains via IPv4 >> Clouds (6to4) >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-07.txt >> Pages : 7 >> Date : 2014-11-10 >> >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism has shown that the mechanism is >> unsuitable for widespread deployment and use in the Internet, >> especially in its anycast mode. This document requests that RFC >> 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete >> and moved to historic status. It also recommends that future >> products should not support 6to4 anycast and that existing >> deployments should be reviewed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 11 15:44:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215F21A6FBF for ; Tue, 11 Nov 2014 15:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQVWI0sf1sxh for ; Tue, 11 Nov 2014 15:44:24 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A0F1A1B27 for ; Tue, 11 Nov 2014 15:44:23 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so2380240vcb.9 for ; Tue, 11 Nov 2014 15:44:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SiVAGXJxGNL2Tfk2PVlEngNLO6q/QNl5Fj4lUREYunQ=; b=R5XnSLK7XhD+Urz5rCls1XhRi+UGlGSxA5mSAT154+KAt2nxRe5101fz09cR+skZDA qb0qXTTwewzx8RDNO9xxYgLhiRD+4g17W6TU9eNzOMeegahJpVhKwWQ5nkF67+nznTV1 XUz6wQ/aNNI9Y2X4LADhsfTp7fCMyM4hC/JUbvGuL64h29feinr6DGPqMnhvsZSN6t8R V5Mf3a5SBxoPQFc9s1MYLZKtfg9W7WIXuE67n50MulYH3Bk/RMG8gQR5yVB8k0ZWpAhh QJea1Tzwrieo8HhORpZtZY8C5xslUX5vUX4zmPQvj8OW9ldgLnxxKa01T0/M8MOO/CVh jCMg== X-Gm-Message-State: ALoCoQnThSqGvVLHC/A00ZSQk/XHHfaHqHmkWupp9AnRF6RxZ2M8mrKnMuCLZam9NIfj+yx74gqh MIME-Version: 1.0 X-Received: by 10.220.252.134 with SMTP id mw6mr4131487vcb.75.1415749463078; Tue, 11 Nov 2014 15:44:23 -0800 (PST) Received: by 10.31.10.65 with HTTP; Tue, 11 Nov 2014 15:44:23 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 13:44:23 -1000 Message-ID: From: James Woodyatt To: "Brzozowski, John" , IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e011613d2d6c0b405079ddb89 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z2fWZUMGltlmZYvUYDcLMGqFc-s Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 23:44:26 -0000 --089e011613d2d6c0b405079ddb89 Content-Type: text/plain; charset=UTF-8 John, What about the return relays? Did you deploy return relays? If you did, then 1) have you ever encountered any problems related to your deployment of return relays? and 2) do you have data concerning how much usage those return relays are seeing? On Tue, Nov 11, 2014 at 11:15 AM, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > Comcast deployed 6to4 relays several years ago, our relays remain active > today. Over the years traffic has decreased significantly. I will see if > I can dig up traffic trends over the past couple of years. If I can I > will send them to the list. > > We intend to operate these relays until there is little to no 6to4 traffic > on our network. The relays were deployed largely to ensure that customers > using 6to4, either on purpose or by accident, have a reasonable > experience. We by no means want our customers to use 6to4, in fact, we > would prefer that they not use IPv6 at all if 6to4 is their only option. > > Throughout this year there were some edge cases related to 6to4 that > required our attention, meaning issues were reported related to the use of > 6to4. This is not an ideal use of engineering time and energy. I agree > with a statement that Mikael Abrahamsson made at the microphone during > IETF91, we should strive to entirely retire the use of 6to4 and I see no > value in replacing 6to4. This again is from the perspective of an > operator that has an extensive native IPv6 deployment and actively > deployed 6to4 relays. > > If pressed to do something I would sooner prefer that 6to4 be replaced > with 6rd. Finally, I just do not see the value in expending v6ops WG time > and energy on the topic of replacing 6to4. We have plenty of forward > looking work to pursue. > > John > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- james woodyatt Nest Labs, Communications Engineering --089e011613d2d6c0b405079ddb89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

What about the return relays?=C2= =A0 Did you deploy return relays?=C2=A0 If you did, then 1) have you ever e= ncountered any problems related to your deployment of return relays? and 2)= do you have data concerning how much usage those return relays are seeing?=

On Tu= e, Nov 11, 2014 at 11:15 AM, Brzozowski, John <John_Brzozo= wski@cable.comcast.com> wrote:
Comcast deployed 6to4 relays several years ago, our relays remain activ= e
today.=C2=A0 Over the years traffic has decreased significantly.=C2=A0 I wi= ll see if
I can dig up traffic trends over the past couple of years.=C2=A0 If I can I=
will send them to the list.

We intend to operate these relays until there is little to no 6to4 traffic<= br> on our network.=C2=A0 The relays were deployed largely to ensure that custo= mers
using 6to4, either on purpose or by accident, have a reasonable
experience.=C2=A0 We by no means want our customers to use 6to4, in fact, w= e
would prefer that they not use IPv6 at all if 6to4 is their only option.
Throughout this year there were some edge cases related to 6to4 that
required our attention, meaning issues were reported related to the use of<= br> 6to4.=C2=A0 This is not an ideal use of engineering time and energy.=C2=A0 = I agree
with a statement that Mikael Abrahamsson made at the microphone during
IETF91, we should strive to entirely retire the use of 6to4 and I see no value in replacing 6to4.=C2=A0 This again is from the perspective of an
operator that has an extensive native IPv6 deployment and actively
deployed 6to4 relays.

If pressed to do something I would sooner prefer that 6to4 be replaced
with 6rd.=C2=A0 Finally, I just do not see the value in expending v6ops WG = time
and energy on the topic of replacing 6to4.=C2=A0 We have plenty of forward<= br> looking work to pursue.

John

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



--
james woodyatt <jhw@nestlabs.com>
Nest Labs,= Communications Engineering
--089e011613d2d6c0b405079ddb89-- From nobody Tue Nov 11 15:59:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF61A710D for ; Tue, 11 Nov 2014 15:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 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, RP_MATCHES_RCVD=-0.594, 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 OTEharx7Sa0l for ; Tue, 11 Nov 2014 15:59:40 -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 F2C601A802C for ; Tue, 11 Nov 2014 15:59:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C2BC7A2; Wed, 12 Nov 2014 00:59:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1415750377; bh=yDVR1uBCNFIy2q3L5ZTFIxodolzfcH4SsCRO7Tet9vM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3OJaxxyW2IwKcs0cHQYkwUvffNWrnH+Ua7mpHcS8B+JlUMWBYWZo4pATeFW/aWUvF TxbCT+VfW1WGj/ETZAsnhCBoQNEct9+DjHJylKhzZgZV7w8UPXnGLqKVRyftJo+Ir5 P+eXf9E0DUe9jG3uMHoGDgvpxt64AS91eCgdq/dE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BE9A2A1; Wed, 12 Nov 2014 00:59:37 +0100 (CET) Date: Wed, 12 Nov 2014 00:59:37 +0100 (CET) From: Mikael Abrahamsson To: James Woodyatt In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xiv1qKgjWo_mTosJGUDjJ7PHPmc Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2014 23:59:42 -0000 On Tue, 11 Nov 2014, James Woodyatt wrote: > What about the return relays? Did you deploy return relays? If you > did, then 1) have you ever encountered any problems related to your > deployment of return relays? and 2) do you have data concerning how much > usage those return relays are seeing? Most people I know of that say they deploy "6to4 relays" mean they're doing bidirectional relaying. Talking operationally, it doesn't make much sense to do just one direction. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 11 16:27:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88EB1A8948 for ; Tue, 11 Nov 2014 16:26: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 JZTbwJ3vTQBD for ; Tue, 11 Nov 2014 16:26:55 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568DA1A87E9 for ; Tue, 11 Nov 2014 16:26:55 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so12857760wgg.36 for ; Tue, 11 Nov 2014 16:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c+8AEc56UGCJ1Cfn+fofhwqpRfF79bIFFHqThShbOg4=; b=Wq0jY6nPumfatBCSYCZI6p8opHLxb4JN1UuTQCYOLuH7ZxW7LGD9lF0tc84IJlKgBR M6jvO4q42pogT7E7PSG7jUaSLKUndt9YaUeISRaUtzO2qLiGmRLHPlvmpP0ndEOP/5Y1 /yfycztazA1gnXpy3zwZYQYHYmjgNAI2dMLMGkNmgQ+NvAarb2x3Hj57qePho37sU0dN zus7yXHXbnnWgerNg+uVs4fhhjAGxQ9EkjllnCCmoZnBO7BO3aQ71AoI+Z/Job4Gt6jj rG4L/xvwSRcDZpfU8GvzXrk9JVlwtQrsVnrqz/YHJjo3HU6o7A5BLjKnUO6eIoKjoS6+ oGSw== X-Received: by 10.194.92.148 with SMTP id cm20mr58394286wjb.88.1415752014047; Tue, 11 Nov 2014 16:26:54 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id w4sm167185wjw.39.2014.11.11.16.26.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 16:26:53 -0800 (PST) Message-ID: <5462A950.5000108@gmail.com> Date: Wed, 12 Nov 2014 13:26:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uqZT1GPdM-9qBqaRfOF7hRVLlWA Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 00:26:57 -0000 On 12/11/2014 12:59, Mikael Abrahamsson wrote: > On Tue, 11 Nov 2014, James Woodyatt wrote: > >> What about the return relays? Did you deploy return relays? If you >> did, then 1) have you ever encountered any problems related to your >> deployment of return relays? and 2) do you have data concerning how >> much usage those return relays are seeing? > > Most people I know of that say they deploy "6to4 relays" mean they're > doing bidirectional relaying. Talking operationally, it doesn't make > much sense to do just one direction. Well, it does make sense for content providers who want to provide a good return relay service but have no interest in attracting clients to the anycast address. And I think that James Woodyatt's alongside-NAT64 case makes sense for an IPv6-only provider. (Except that this is a dying protocol, not a growth area.) Brian From nobody Tue Nov 11 16:40:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204021A8751 for ; Tue, 11 Nov 2014 16:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh-zZgUPQ_ku for ; Tue, 11 Nov 2014 16:40:32 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4953E1A1BF9 for ; Tue, 11 Nov 2014 16:40:32 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id hy10so4849627vcb.40 for ; Tue, 11 Nov 2014 16:40:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+fFw5XcESZKF7S05QrnmFzK/CwOnIUSfs8Xmqieq/Sg=; b=NxxigoJJvnVZHnSW9fuQxtiHlnV2+UUcHmWSR82AmzjDF7YSsVsv1hF2kXTjiKAiD4 Qk8TmitwxOEU37xu3+r/9lbfZYymcsDQ7EV3s28MfN2gCJGgodpV14dmj2K/yDLG4wj3 9GD0MmG7pcfuq0MxGbJDls3xMJJV9opA1t/ROK4BIRIjhD1lSSzL0StIyA7eht3LAuWA 3ZthLWsk4nbRWrwCAwkNruskVvlsY+tMLfTckAPGFOZG0kf+AINEvSrLbNSuWTxGgiFS jbI8ItF7Xy69ZgU3E7KcIrTfzdG6S6yeRffqOW6nGXO2HlWK0ycYzjecRwPWAXKo92Gr i0cA== X-Gm-Message-State: ALoCoQk5egleX32oPt/u0ou3m233KqKsbUXAMu2omh98Ed+3ref/8eLWcAzXDPBFzMRMb/jn3gJE MIME-Version: 1.0 X-Received: by 10.220.252.134 with SMTP id mw6mr4347461vcb.75.1415752831409; Tue, 11 Nov 2014 16:40:31 -0800 (PST) Received: by 10.31.10.65 with HTTP; Tue, 11 Nov 2014 16:40:31 -0800 (PST) In-Reply-To: <5462A950.5000108@gmail.com> References: <5462A950.5000108@gmail.com> Date: Tue, 11 Nov 2014 14:40:31 -1000 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e011613d29b376505079ea4ab Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qbc3EWoArliwPwVPbWhbxZSVQbA Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 00:40:34 -0000 --089e011613d29b376505079ea4ab Content-Type: text/plain; charset=UTF-8 RFC 6343 recommends transit providers and content providers to have a working 6to4 return relay, but it leaves consumer and enterprise network operators without such guidance. If you're an enterprise network or a residential retail network, and your transit operators are failing to comply with RFC 6343, then I would say it's your problem that packets sent from your IPv6-only customers are not getting delivered properly to the 2002::/16 prefix. Because RFC 3056 is still Standards Track and the Sun is still shining on IPv4 from very high in the sky. If you are a consumer ISP or an enterprise network without a 6to4 return path, then you can fix your problem by finding a transit provider that succeeds at RFC 6343, or you can fix it by installing a 6to4 relay yourself, but I would say that Best Current Practice is definitely to fix it. I would prefer that Best Current Practice not include leaving it broken and blaming the victim. That's all I'm trying to say. On Tue, Nov 11, 2014 at 2:26 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 12/11/2014 12:59, Mikael Abrahamsson wrote: > > On Tue, 11 Nov 2014, James Woodyatt wrote: > > > >> What about the return relays? Did you deploy return relays? If you > >> did, then 1) have you ever encountered any problems related to your > >> deployment of return relays? and 2) do you have data concerning how > >> much usage those return relays are seeing? > > > > Most people I know of that say they deploy "6to4 relays" mean they're > > doing bidirectional relaying. Talking operationally, it doesn't make > > much sense to do just one direction. > > Well, it does make sense for content providers who want to provide a good > return relay service but have no interest in attracting clients to the > anycast > address. And I think that James Woodyatt's alongside-NAT64 case makes sense > for an IPv6-only provider. (Except that this is a dying protocol, not > a growth area.) > > Brian > -- james woodyatt Nest Labs, Communications Engineering --089e011613d29b376505079ea4ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC 6343 recommends transit providers and content provider= s to have a working 6to4 return relay, but it leaves consumer and enterpris= e network operators without such guidance. If you're an enterprise netw= ork or a residential retail network, and your transit operators are failing= to comply with RFC 6343, then I would say it's your problem that packe= ts sent from your IPv6-only customers are not getting delivered properly to= the 2002::/16 prefix.

Because RFC 3056 is still Standar= ds Track and the Sun is still shining on IPv4 from very high in the sky.
If you are a consumer ISP or an enterprise network without= a 6to4 return path, then you can fix your problem by finding a transit pro= vider that succeeds at RFC 6343, or you can fix it by installing a 6to4 rel= ay yourself, but I would say that Best Current Practice is definitely to fi= x it.

I would prefer that Best Current Practice no= t include leaving it broken and blaming the victim.=C2=A0 That's all I&= #39;m trying to say.

On Tue, Nov 11, 2014 at 2:26 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 12/11/2014 12:= 59, Mikael Abrahamsson wrote:
> On Tue, 11 Nov 2014, James Woodyatt wrote:
>
>> What about the return relays?=C2=A0 Did you deploy return relays?= =C2=A0 If you
>> did, then 1) have you ever encountered any problems related to you= r
>> deployment of return relays? and 2) do you have data concerning ho= w
>> much usage those return relays are seeing?
>
> Most people I know of that say they deploy "6to4 relays" mea= n they're
> doing bidirectional relaying. Talking operationally, it doesn't ma= ke
> much sense to do just one direction.

Well, it does make sense for content providers who want to prov= ide a good
return relay service but have no interest in attracting clients to the anyc= ast
address. And I think that James Woodyatt's alongside-NAT64 case makes s= ense
for an IPv6-only provider. (Except that this is a dying protocol, not
a growth area.)

=C2=A0 =C2=A0 Brian



--
james woodyatt <jhw@nestlabs.com>Nest Labs, Communications Engineering
--089e011613d29b376505079ea4ab-- From nobody Tue Nov 11 18:11:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4C1A88F8 for ; Tue, 11 Nov 2014 18:11:48 -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 PHQUmKLnw6Wl for ; Tue, 11 Nov 2014 18:11:47 -0800 (PST) Received: from copdcmhout01.cable.comcast.com (unknown [162.150.44.71]) by ietfa.amsl.com (Postfix) with ESMTP id 888AE1A88C7 for ; Tue, 11 Nov 2014 18:11:47 -0800 (PST) X-AuditID: a2962c47-f79ba6d000001037-77-5462c1e21936 Received: from pacdcexhub05.cable.comcast.com (pacdcexhub05.cable.comcast.com [24.40.56.122]) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 12.8C.04151.2E1C2645; Tue, 11 Nov 2014 19:11:47 -0700 (MST) Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.113]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.03.0181.006; Tue, 11 Nov 2014 21:11:46 -0500 From: "Brzozowski, John" To: Brian E Carpenter Thread-Topic: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) Thread-Index: AQHP/fSJrP3CwUnyzUKuknaVNLjrwJxcS5aA//+grwA= Date: Wed, 12 Nov 2014 02:11:45 +0000 Message-ID: References: <54628533.1010206@gmail.com> In-Reply-To: <54628533.1010206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="utf-8" Content-ID: <279B73FC064B4D44963E82D1CDB28EC0@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUioWFRpfv4YFKIQf93Rou2i/uYLE4f28vs wOSxc9Zddo8lS34yBTBFcdskJZaUBWem5+nbJXBnfL46i6VgjVTFg2u/2BsYr0h2MXJySAiY SMy/vYYZwhaTuHBvPVsXIxeHkMBNRom96z8xQTiHGCXeH/zFClLFJmAj8frDT0YQW0TAWKKx 6zRQnIODWUBVYvYffpCwsECBxP1Vx5kgSgolOjavYoWwrSQ+rF3KDlLOAlR+/ZYxSJhXwF7i Rs93sIlCAnES7cdugbVyCmhKXH0xB6yVEei276fWgMWZBcQlbj2ZzwRxs4DEkj3noe4XlXj5 +B9YvaiAnsS8h6/YIOIKEi/33mGDuFJTYv0ufYgxDhJf3j9mhrAVJaZ0P2SHOEdQ4uTMJywT GCVmIdk2C6F7FpLuWUi6ZyHpXsDIuopRLjm/ICU5NyO/tMTAUC85MSknVS85Pzc5sbgERG9i BEblomk67jsYL/Q6H2IU4GBU4uHlXJUUIsSaWFZcmQsMdg5mJRHeB0uBQrwpiZVVqUX58UWl OanFhxilOViUxHlVFniFCAmkJ5akZqemFqQWwWSZODhBurmkRIpT81JSixJLSzLiQckhvhiY HqQaGEOKL6a5yTxwqM8xPFEvdvp75o+5mQ/PK7/gZyyt9N0SvWNnbVTEBnHJczOUoiztJ1yQ Pnwmlm3JxIs/rapnbQwwe5t142tNMLtZnf2xJ/dblZyFTOfNPHjsxkK+/JePVfZc23Xkvsd7 PuVskcXBMhI/5vxsszfc8GivV2z089vc4aZ+Nw3fXVFiKc5INNRiLipOBAC34vU94QIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xvNDvKxfBrlWaZ44ZnEpM5arCDo Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 02:11:49 -0000 QWdyZWVkLCB0aGFua3MgQnJpYW4uDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpKb2huIEphc29uIEJyem96b3dza2kNCkNvbWNhc3QgQ2FibGUNCm0pIDYwOS0z NzctNjU5NA0KbykgNDg0LTk2Mi0wMDYwDQp3KSB3d3cuY29tY2FzdDYubmV0DQplKSBqb2huX2Jy em96b3dza2lAY2FibGUuY29tY2FzdC5jb20NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogQnJpYW4gQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQpPcmdhbml6 YXRpb246IFVuaXZlcnNpdHkgb2YgQXVja2xhbmQNCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDEx LCAyMDE0IGF0IDExOjUyDQpUbzogSm9obiBCcnpvem93c2tpIDxKb2huX0Jyem96b3dza2lAQ2Fi bGUuQ29tY2FzdC5jb20+DQpDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gT3BpbmlvbiBmcm9tIGFuIG9wZXJhdG9yIHRoYXQgYXMgZGVwbG95ZWQgNnRvNCBy ZWxheXMNCihkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMpDQoNCj5Kb2huLA0KPg0K PkkgZG9uJ3Qgc2VlIGFueSBpbmNvbnNpc3RlbmN5IGJldHdlZW4gd2hhdCB5b3Ugd3JpdGUgYW5k IHdoYXQgdGhlDQo+ZHJhZnQgc2F5cy4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nLg0K Pg0KPlJlZ2FyZHMNCj4gICBCcmlhbg0KPg0KPk9uIDEyLzExLzIwMTQgMTA6MTUsIEJyem96b3dz a2ksIEpvaG4gd3JvdGU6DQo+PiBDb21jYXN0IGRlcGxveWVkIDZ0bzQgcmVsYXlzIHNldmVyYWwg eWVhcnMgYWdvLCBvdXIgcmVsYXlzIHJlbWFpbiBhY3RpdmUNCj4+IHRvZGF5LiAgT3ZlciB0aGUg eWVhcnMgdHJhZmZpYyBoYXMgZGVjcmVhc2VkIHNpZ25pZmljYW50bHkuICBJIHdpbGwgc2VlDQo+ PmlmDQo+PiBJIGNhbiBkaWcgdXAgdHJhZmZpYyB0cmVuZHMgb3ZlciB0aGUgcGFzdCBjb3VwbGUg b2YgeWVhcnMuICBJZiBJIGNhbiBJDQo+PiB3aWxsIHNlbmQgdGhlbSB0byB0aGUgbGlzdC4NCj4+ IA0KPj4gV2UgaW50ZW5kIHRvIG9wZXJhdGUgdGhlc2UgcmVsYXlzIHVudGlsIHRoZXJlIGlzIGxp dHRsZSB0byBubyA2dG80DQo+PnRyYWZmaWMNCj4+IG9uIG91ciBuZXR3b3JrLiAgVGhlIHJlbGF5 cyB3ZXJlIGRlcGxveWVkIGxhcmdlbHkgdG8gZW5zdXJlIHRoYXQNCj4+Y3VzdG9tZXJzDQo+PiB1 c2luZyA2dG80LCBlaXRoZXIgb24gcHVycG9zZSBvciBieSBhY2NpZGVudCwgaGF2ZSBhIHJlYXNv bmFibGUNCj4+IGV4cGVyaWVuY2UuICBXZSBieSBubyBtZWFucyB3YW50IG91ciBjdXN0b21lcnMg dG8gdXNlIDZ0bzQsIGluIGZhY3QsIHdlDQo+PiB3b3VsZCBwcmVmZXIgdGhhdCB0aGV5IG5vdCB1 c2UgSVB2NiBhdCBhbGwgaWYgNnRvNCBpcyB0aGVpciBvbmx5IG9wdGlvbi4NCj4+IA0KPj4gVGhy b3VnaG91dCB0aGlzIHllYXIgdGhlcmUgd2VyZSBzb21lIGVkZ2UgY2FzZXMgcmVsYXRlZCB0byA2 dG80IHRoYXQNCj4+IHJlcXVpcmVkIG91ciBhdHRlbnRpb24sIG1lYW5pbmcgaXNzdWVzIHdlcmUg cmVwb3J0ZWQgcmVsYXRlZCB0byB0aGUgdXNlDQo+Pm9mDQo+PiA2dG80LiAgVGhpcyBpcyBub3Qg YW4gaWRlYWwgdXNlIG9mIGVuZ2luZWVyaW5nIHRpbWUgYW5kIGVuZXJneS4gIEkgYWdyZWUNCj4+ IHdpdGggYSBzdGF0ZW1lbnQgdGhhdCBNaWthZWwgQWJyYWhhbXNzb24gbWFkZSBhdCB0aGUgbWlj cm9waG9uZSBkdXJpbmcNCj4+IElFVEY5MSwgd2Ugc2hvdWxkIHN0cml2ZSB0byBlbnRpcmVseSBy ZXRpcmUgdGhlIHVzZSBvZiA2dG80IGFuZCBJIHNlZSBubw0KPj4gdmFsdWUgaW4gcmVwbGFjaW5n IDZ0bzQuICBUaGlzIGFnYWluIGlzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGFuDQo+PiBvcGVy YXRvciB0aGF0IGhhcyBhbiBleHRlbnNpdmUgbmF0aXZlIElQdjYgZGVwbG95bWVudCBhbmQgYWN0 aXZlbHkNCj4+IGRlcGxveWVkIDZ0bzQgcmVsYXlzLg0KPj4gDQo+PiBJZiBwcmVzc2VkIHRvIGRv IHNvbWV0aGluZyBJIHdvdWxkIHNvb25lciBwcmVmZXIgdGhhdCA2dG80IGJlIHJlcGxhY2VkDQo+ PiB3aXRoIDZyZC4gIEZpbmFsbHksIEkganVzdCBkbyBub3Qgc2VlIHRoZSB2YWx1ZSBpbiBleHBl bmRpbmcgdjZvcHMgV0cNCj4+dGltZQ0KPj4gYW5kIGVuZXJneSBvbiB0aGUgdG9waWMgb2YgcmVw bGFjaW5nIDZ0bzQuICBXZSBoYXZlIHBsZW50eSBvZiBmb3J3YXJkDQo+PiBsb29raW5nIHdvcmsg dG8gcHVyc3VlLg0KPj4gDQo+PiBKb2huDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3Bz QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+PiANCj4NCg0K From nobody Tue Nov 11 18:32:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6857E1AC3E6 for ; Tue, 11 Nov 2014 18:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmRLWMsm2BfT for ; Tue, 11 Nov 2014 18:32:19 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903381A914D for ; Tue, 11 Nov 2014 18:32:19 -0800 (PST) Received: from dhcp-b324.meeting.ietf.org (dhcp-b324.meeting.ietf.org [31.133.179.36]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sAC2W6Em087677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 03:32:09 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 11 Nov 2014 16:32:06 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2NbqAxWZ0z67CEtVrx_4ejVTZdk Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 02:32:21 -0000 On 11 Nov 2014, at 13:59, Mikael Abrahamsson wrote: > Most people I know of that say they deploy "6to4 relays" mean they're = doing bidirectional relaying. Talking operationally, it doesn't make = much sense to do just one direction. Hm, I have the following on my server: stf0: flags=3D1 mtu 1280 inet6 2002:5395:4101::1 prefixlen 16 This means that if a 6to4 user visits my website at its (native) IPv6 = address, I tunnel the responses back directly to that user without = having to go through a public relay. Running a relay in the other direction only makes sense if you have 6to4 = users that you are willing to provide this service for, i.e., only when = you are an ISP or are prepared to run a public relay.= From nobody Tue Nov 11 23:18:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B61A1A03 for ; Tue, 11 Nov 2014 23:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y3FoDNrYy6h for ; Tue, 11 Nov 2014 23:18:06 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFCF1A00F0 for ; Tue, 11 Nov 2014 23:18:05 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 133E810060A4C; Wed, 12 Nov 2014 07:18:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415776682; bh=A6h/wdq97W+YwG6NvHCiIPpsOAKYwsmPC61dKD/oGLk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=xZIK+4j7LM+FVIO6gSsBeZRYgO2otbiDeKS4iHqFoSvZ/rsEpWOAe5YscvLqJp2Wk iHkKXIruT0Tp3S1iurGJ+mPGY9Fau/gA60To4EYVBZ9legZVT4aL6eKcoM4urHnXF5 aHgJTmsAAuUGHo9ybbop0N0NCS5A7ukOa+vddIRKbfTPHvOLnUeCxpw3uwUPJ8/hs9 1B+fIfyNjpwYVh8nIE+38A264vaFIBf/HjYKlqUr21tNSITorkOfkv8RCgCjxquNcN 3UNszy/RfMPqYuqNQcqw5YTiSw2NB07hDKRHK1A7CLjMXdSqoyYYO7L4u0I/VIaYtr k8I7X8+PVoIIg== Message-ID: <546309A7.1020007@massar.ch> Date: Wed, 12 Nov 2014 08:17:59 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VxnHy16I_ptXqQam-1nRRxDm5KU Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 07:18:08 -0000 On 2014-11-12 03:32, Iljitsch van Beijnum wrote: > On 11 Nov 2014, at 13:59, Mikael Abrahamsson > wrote: > >> Most people I know of that say they deploy "6to4 relays" mean >> they're doing bidirectional relaying. Talking operationally, it >> doesn't make much sense to do just one direction. > > Hm, I have the following on my server: > > stf0: flags=1 mtu 1280 inet6 2002:5395:4101::1 prefixlen 16 > > This means that if a 6to4 user visits my website at its (native) IPv6 > address, I tunnel the responses back directly to that user without > having to go through a public relay. The fun with that one is, if the state tracking on the source host (thus the one who contacted your native address), is accepting that 6to4 packet which comes in directly instead of through that relay they previously talked to. Hence, it might just cause broken behavior. Greets, Jeroen From nobody Wed Nov 12 00:46:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801901A8852; Wed, 12 Nov 2014 00:46:51 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We6cgvWxsXu6; Wed, 12 Nov 2014 00:46:46 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFCE1A8850; Wed, 12 Nov 2014 00:46:45 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 3318110060A50; Wed, 12 Nov 2014 08:46:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415782003; bh=HUMqkzZYFIBcF8/W3dy/ob8Ik9q6lRJmQ6gjTuSxaEE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Or026I2fZRqDB91R3ojXmqGtdpHqwt04FeNAv7f1t8LzTCzblC9HGBt/EgkLwn3Vw 5HIfOgVilh4cU+Fp5SG9v5paXwLqyK4oaeT+gNLfz9iKu3nryqcSWhYa8VEEqKWyuP kuvMHNcGle6JKTGws2tf+UmR+bJJ6TgI2oRBWY0LfX7/wTyXdNdzFFC9n79jhUDWFX vRr+egSKrvBj/6tgaPBqfBw4DqUKm9a1SzBnlTp1hY/ppTe0avbq3RGnwgb+nOD8RN 9gIJOlgEXqe3Fi2KK9w8EjMiY6NBEQXpmNYIndbI1rNt99LkQQ9S/uAp6UaV3oobxG KS62JC6wHbzbg== Message-ID: <54631E71.60403@massar.ch> Date: Wed, 12 Nov 2014 09:46:41 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Mark ZZZ Smith References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/59UjwQHWvXoZQFJd3e4lzexyOcQ Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 08:46:51 -0000 On 2014-11-11 23:44, Mark ZZZ Smith wrote: [..] >> On 2014-11-10 19:57, Brian E Carpenter wrote: >>> Er, no, you really can't use the flow label like that. RFC6437. >> >> Hence, redefining the bits :) Few implementations use them anyway, thus >> we still have time to actually make good use of them. >> > > So the "flow label" then field name wouldn't then be accurate, because an > MTU value doesn't identify or contribute to the identification or labelling > of a flow very well. Yes, that field name would have to get a better name indeed. > There's a lot of troubleshooting and other value in "truth in advertising", > or less cliché'd "accuracy in naming". Encoding non-flow labelling MTU > information in that existing flow labelling field would therefore be a hack > (MTU might be an attribute of a flow, but it isn't very specific or unique to a flow) > for this one special case of stateless ECMP based load balancing. It is only a hack if somebody currently does it. It would not be a hack when it is an official RFC.... and then for sure the name would be updated to reflect this information. Note that I specifically propose setting the the first four bits to 1 so that the old mechanism can keep on working. As the flow-label does not add anything to the magic bits (src + dst) that are already present and as it does not solve the actual problem that loadbalancers have: associating any ICMPv6 message caused by the 'flow' to be associated; the flow label as currently specified is quite useless anyway. Copying the flow-label from the real flow into the flow-label of the ICMPv6 would not help either, as the load balancer, per the current spec, uses src+dst+flow-id and as the src == router-which-sent-icmpv6 the flow might end up at a different device. Vendors will not like the flow-id either, as it cannot be promised to be uniformly distributed by the sending source, thus just using flow-label is not good enough. Ignoring the part where, if the flow-label was the only part used for load balancing it would be useless for all current implementations that do not set the flow-id at all. The more correct answer to that problem is that Load Balancers MUST look at the content of the ICMPv6 packet for making load balancing decisions and not just do it based on src/dst(+flow-label). > It wouldn't be useful in most or perhaps all other IP use cases. > (So if this idea gained more traction, I'd start lobbying for the field to be renamed.) > > It seems to me that the fundamental issue is that given how the IP protocols work > (as this problem also occurs in IPv4), stateless ECMP isn't a very effective method > of performing load balancing. While probably chosen for pure performance/throughput, > it isn't distributing load to the LB hosts based on their current load (so it isn't > actually 'balancing'), and because it isn't maintaining per-host state, isn't able > to perform per-host specific processing/forwarding, which is what is needed for PMTUD to function in this scenario. Just letting the load balancer peek into the ICMPv6 packet, which includes a large portion of the packet that would be sufficient. For performance reasons apparently these devices are not doing so. But next to load-balancers, there are still people who think they have the need to filter ICMPv6 completely. These devices miss out on PMTUD altogether. > This/these methods of load balancing have generally annoyed me for a while, primarily because > I have also had to troubleshoot or deal with these sorts of issues in the past. > I think the fundamental issue is that to the network, the unicast LB address is looks > like a single unicast destination/host, where as in reality is being shared by a number of hosts. [..] Indeed. The problem there is simply that IP was not designed with such a system (load-balancers looking only at src/dst(/flow-label)) in mind, especially when considering these devices have to look at ICMPv6 too, which they clearly do not (for performance reasons, hardware/asic etc). What is sad about this is that the vendors who built those devices did not discover this till they deployed those devices and that when they did, they apparently did not raise this for discussion in the community so that a proper fix could be made. Greets, Jeroen From nobody Wed Nov 12 00:57:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35131A8965; Wed, 12 Nov 2014 00:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_51=0.6] 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 0lvSiH2wLmZA; Wed, 12 Nov 2014 00:57:32 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7B81A8852; Wed, 12 Nov 2014 00:57:32 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D368F10060A54; Wed, 12 Nov 2014 08:57:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415782650; bh=jH0PhM6AYEd/Gh9LDcrbD3Jj6dG5T1QbwRkGCeVBqG4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=SHzEWT+Jn4EDiYbD/X7A6/78ZRABWES2I+tf2LU/RkYu8eUv54SKQ+aovFYm1JAh3 8gS4hDvo9vi8UjM5ItIUgL76RDhfUmEiBM6SYYfPoDL/0MR8JjDPRDNY05MX5yK6sM 0EOs++DPM/4LO0b4KxYqWIshGRd14Bq7dGo8y8GRuPGGwrT7q7FvdII7xc12J3oATN 68mVZITFxyVCLGDjCwrZGe8I0TNeECCTrBeewP8qgcUcxAOpzO90aeTLjLte9pGVAd ayMLNTgQDhhJ5SzpbYt7hlBGroI431cizAX1b3LneX1WcnGc6ev23OFzRQhcnJG52U qpDjUEn5LiY1w== Message-ID: <546320F7.9000809@massar.ch> Date: Wed, 12 Nov 2014 09:57:27 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Lorenzo Colitti , Mark ZZZ Smith References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CUi4QCGtUebzDElN2Ym--YWhKkU Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 08:57:36 -0000 On 2014-11-12 00:25, Lorenzo Colitti wrote: > > On 11 Nov 2014 12:47 pm, "Mark ZZZ Smith" > wrote: >> If high performance stateless and therefore load insensitive LB >> distribution is needed or wanted, then perhaps something more simple >> that doesn't use TCP or UDP port information might be better. For >> example, using SA+DA based forwarding in the LB, and then statically >> mapping portions of the SA address space to a particular LB host (e.g., >> 1/4 to LB host a, 1/4 to LB host b etc. for four LB hosts), with all LB >> hosts configured with the LB 'shared' unicast address (i.e., no NAT). If >> you want anything smarter than that, then I think the LB needs to become >> stateful, and start maintaining per-connection state. > > The problem is not that the TCP/UDP port changes. The problem is that > the source address of the intermediate router sending the PTB hashes > differently than the source address of the client. So SA+DA only > load-balancing won't help. Thus what the load balancer should be doing is unfortunately special casing the situation when the next-header (which might need an extension header walk) is ICMPv6 and then look into the copy (first portion upto a max of 1280 total packet size) of the original packet that caused that ICMPv6 and actually make the load balancing decision based on that. But it is quite likely that such a decision branch does not fit in the ASICs how they where designed, thus all currently deployed hardware and stuff coming out in the next years will be broken for this kind of setup. Though, they could in theory avoid doing the extension walk, and only handling this special case when the first header is ICMPv6. Though then you still get magic breakage when Even if we get such a "IPv6 MTU Label" it does not exclude that ICMPv6s might get send. It only minimizes the chance that they happen. What The "IPv6 MTU Label" will give us is that that Load Balancer does not need to know about it, it can just pass the packets based on src/dst as it has been doing anyway. Just in case the process is possibly better described in: http://www.ietf.org/id/draft-massar-v6man-mtu-label-00.txt Though I was already informed of a small oversight in that only the 3rd+ packet should attempt to increase the MTU to the MTU that is discovered. packet 1 @ 1280 max: A -> B to discover MTU on A -> B packet 2 @ 1280 max: B -> A to discover MTU on B -> A and inform A of A-B-A path packet 3 @ MTU max I'll prepare an update to include that detail after processing some other comments that where received. More comments/arguments and even "We should not do this because Y" and "it does not work because X" are very welcome of course, those things are called Requests for Comments after all and it is not a STD yet... Greets, Jeroen From nobody Wed Nov 12 01:27:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4A1A1B96; Wed, 12 Nov 2014 01:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeTHmy-I7mUJ; Wed, 12 Nov 2014 01:27:21 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C551A1BB4; Wed, 12 Nov 2014 01:27:20 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 214C110060A56; Wed, 12 Nov 2014 09:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415784436; bh=GXDdnBtPNIrw76/rDlxve9cl6oOnQs/llh6FcK4Qegw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=dnCp6uSzxmRQ4d/rWW59Qg8dtty0i9109NDi4TomTtgiAtQpC+alWDmub7+LshNbr VZyK0xThrvxGv81YfMWLPzdbK0bFxjRlWwR47Q22KKdl48e+johWK02gEVeSQiQ0Nk 2F9tBTtOke1U6ijUEhXlzEmmtACkjG+Dxs6i9mrlBtTwqPdVmvN3M5VShEpZZrpOjw 68P/67JtgMheqyw17moFW/xJ/hLOJewOROYzeCECIpil33PMFyAmW+4aviqPStyhgj c31ZpHnPGz2Nchq9hoxe47SKoeDAGYwjYD9Z2tkmc/Z00Z/TriErDSon34K8wad7ll k6cELufjRLd6w== Message-ID: <546327F2.7040901@massar.ch> Date: Wed, 12 Nov 2014 10:27:14 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> In-Reply-To: <54625975.70604@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0xkfLGpxJUvqiyeaxxT9Kszmkt8 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 09:27:23 -0000 On 2014-11-11 19:46, Brian E Carpenter wrote: > On 11/11/2014 22:52, Jeroen Massar wrote: >> On 2014-11-10 20:54, Brian E Carpenter wrote: >>> On 11/11/2014 08:02, Jeroen Massar wrote: >>>> On 2014-11-10 19:57, Brian E Carpenter wrote: >>>>> Er, no, you really can't use the flow label like that. RFC6437. >>>> Hence, redefining the bits :) Few implementations use them anyway, thus >>>> we still have time to actually make good use of them. >>>> >>>> Note that I am specifically proposing setting the first four bits to 1 >>>> aka 0xf so that the space can still be used for it's original intent too. >>> Yeah, well, 6man has consistently said no to every such proposal. >> >> Well, maybe it is time to finally look at such a proposal instead of >> keeping those 20 bits be used for nothing useful. >> >> At minimum there should be a document describing WHY such a change is >> out of the question. > > This is exactly why we did the RFCs I mentioned. EOM. I assume you meant RFC6294. This does not discuss the possibility of using the bits for the purposes of making the live of every operator easier and avoiding PMTUD blackholes. Also note from the introduction of that document: "However, it [Flow Label] is used very little in practice" The new set of RFCs are only from later in that year and have the same problem. But the bigger issue is simply that for load-balancing purposes "on just the IP layer" it does not work because of ICMPv6. Which is documented in RFC7098: 8<---------------------------- 2. A layer 3/4 balancer must correctly handle Path MTU Discovery by forwarding relevant ICMPv6 packets in both directions. This too is not directly affected by use of the flow label. It should be noted that there may be difficulty correlating an ICMPv6 "Packet too big" response with the session it refers to, but that is out of the scope of the present document. --------------------------->8 As the layer 3/4 balancer is then looking into the lower layers anyway (ICMPv6), they don't need the flow-label as then they can then also look at TCP/UDP ports which are much better for uniqueness than an arbitrarily set 20 bit label instead of a much better src & dst-port = 2x16bit = 32bits; though okay, indeed dst-port is likely always 80 or 443. Then again, src/dst should be enough to balance load, if a certain src is creating most of your traffic, better let one node handle that one then DoS your whole cluster. It is also evident that the balancers out there (at least some of them used by large corporations) only care about the src + dst pair. The big point still remains: We can still redefine these recent RFCs that are nowhere close to STDs and optimize something that will have a benefit for the lifetime of IPv6. Or we can keep living in a world where the MTU of IPv6 will defacto be 1280. While in the proposal I made that MTU can be anything upwards from 1280. Greets, Jeroen From nobody Wed Nov 12 04:35:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075791A049A for ; Wed, 12 Nov 2014 04:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asto-15LGZfU for ; Wed, 12 Nov 2014 04:34:56 -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 EA9521A891C for ; Wed, 12 Nov 2014 04:34:55 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D8AB0631B0 for ; Wed, 12 Nov 2014 13:34:53 +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 7C8DA6012B for ; Wed, 12 Nov 2014 13:34:53 +0100 (CET) Received: (qmail 12419 invoked by uid 1007); 12 Nov 2014 13:34:53 +0100 Date: Wed, 12 Nov 2014 13:34:53 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141112123453.GB31092@Space.Net> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <2134F8430051B64F815C691A62D9831832D8366D@XCH-BLV-504.nw.nos.boeing.com> <546272D7.9090208@gmail.com> <2134F8430051B64F815C691A62D9831832D83873@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832D83873@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hzBxwDX6aqI9ggQtJjkzhR1rcpU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 12:34:58 -0000 Hi, On Tue, Nov 11, 2014 at 08:56:42PM +0000, Templin, Fred L wrote: > Maybe we should just put "Obsoletes RFC3056, RFC3068" in the header of AERO? No, as it doesn't. 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 12 10:37:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3BC1ACD8D for ; Wed, 12 Nov 2014 10:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.594, 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 mxoSJ26XRBS4 for ; Wed, 12 Nov 2014 10:37:05 -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 F0F441A8A64 for ; Wed, 12 Nov 2014 10:35:37 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 371DE1FCAB8; Wed, 12 Nov 2014 18:35:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0CBF0160060; Wed, 12 Nov 2014 18:38:51 +0000 (UTC) Received: from rock.dv.isc.org (dhcp-b712.meeting.ietf.org [31.133.183.18]) by zmx1.isc.org (Postfix) with ESMTPSA id ED454160030; Wed, 12 Nov 2014 18:38:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 79F712367D9C; Wed, 12 Nov 2014 20:03:44 +1100 (EST) To: Jeroen Massar From: Mark Andrews References: <546309A7.1020007@massar.ch> In-reply-to: Your message of "Wed, 12 Nov 2014 08:17:59 +0100." <546309A7.1020007@massar.ch> Date: Wed, 12 Nov 2014 20:03:44 +1100 Message-Id: <20141112090344.79F712367D9C@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SHaepgfG_oOmLJHtRuR3ywWnFFk Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 18:37:06 -0000 In message <546309A7.1020007@massar.ch>, Jeroen Massar writes: > On 2014-11-12 03:32, Iljitsch van Beijnum wrote: > > On 11 Nov 2014, at 13:59, Mikael Abrahamsson > > wrote: > > > >> Most people I know of that say they deploy "6to4 relays" mean > >> they're doing bidirectional relaying. Talking operationally, it > >> doesn't make much sense to do just one direction. > > > > Hm, I have the following on my server: > > > > stf0: flags=1 mtu 1280 inet6 2002:5395:4101::1 prefixlen 16 > > > > This means that if a 6to4 user visits my website at its (native) IPv6 > > address, I tunnel the responses back directly to that user without > > having to go through a public relay. > > The fun with that one is, if the state tracking on the source host (thus > the one who contacted your native address), is accepting that 6to4 > packet which comes in directly instead of through that relay they > previously talked to. > > Hence, it might just cause broken behavior. 6to4 always has asymetric routing unless you are *very* lucky. The way to avoid that is to have *exactly* *one* gateway in the world or to start injecting more specifics when you know your client population. 6to4 + state tracking is known not to work. This is why we worked on HE for those people who are behind such firewalls or firewalls that block proto 41 outright. Adding more relay points (either direction) will not hurt 6to4 users which have working 6to4 today. They will already be handling the asymetry. What hurts 6to4 is broken relays and firewalls blocking the traffic. What the purists don't like is symetric routing and that it is not native. Mark > Greets, > Jeroen > > _______________________________________________ > 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 12 11:13:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67C1A1BAD; Wed, 12 Nov 2014 07:50: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 fERiYzCD_wk8; Wed, 12 Nov 2014 07:50:20 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C31A1BAC; Wed, 12 Nov 2014 07:50:20 -0800 (PST) Received: from oasis.uclouvain.be (unknown [130.104.6.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPS id B885718343B; Wed, 12 Nov 2014 16:50:13 +0100 (CET) Received: from [130.104.228.78] (130.104.228.78) by ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 12 Nov 2014 16:49:57 +0100 Message-ID: <546381B8.6090607@uclouvain.be> Date: Wed, 12 Nov 2014 16:50:16 +0100 From: David Lebrun User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl" X-Originating-IP: [130.104.228.78] X-ClientProxiedBy: UCL-CAS03.OASIS.UCLOUVAIN.BE (10.10.10.43) To ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; helo= Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; envelope-from= X-SGSI-MailScanner-ID: B885718343B.AE568 X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-2.806, requis 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_00 -1.60, RDNS_NONE 0.79) X-SGSI-From: david.lebrun@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mWli54jsc5JfPUNYS1KFLD5Ci1c X-Mailman-Approved-At: Wed, 12 Nov 2014 11:13:26 -0800 Cc: v6ops@ietf.org, Julien Pivotto , "Dave Barach \(dbarach\)" , "Leddy, John" , "Christian Martin \(martincj\)" , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , Stephen McCarthy Subject: [v6ops] Supporting IPv6 Segment Routing in the Linux kernel X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 15:50:23 -0000 --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For the past few months we have been working on a Linux kernel implementation of the IPv6 version of Segment Routing as defined in draft-previdi-6man-segment-routing-header. We performed an interoperability demonstration with Cisco and Comcast at Bits-n-Bytes of IETF90. At this point we assume that our implementation is ready for a public release, thus enabling contributions, feedback, discussions, etc. We provide a front page for this implementation: http://www.segment-routing.org. Basically, it links to three main things:= 1. The source code hosted on github at http://github.com/segment-routing/sr-ipv6 and the userland tool http://github.com/segment-routing/seg6ctl 2. A technical report describing the implementation at http://www.segment-routing.org/sr6-doc.pdf 3. A public mailing list at https://listes-2.sipr.ucl.ac.be/sympa/info/sr6-dev to enable discussions, patch submissions, etc. The long-term goal is to make this implementation stable and mature enough for merging in the upstream Linux kernel. Moreover, we have a public testbed composed of 4 routers and 1 host, all running our SR-IPv6 implementation, to facilitate interoperability tests. We will release more information about this testbed later. Feel free to use, modify, play with the code ! David --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRjgb8ACgkQjbzn67sZ6AMKXgCdFRrBkDKXjP7QN3py80dQTkdC jokAnjsNfw8TE6Cl0nvu+93948Pb/OjK =Jnlg -----END PGP SIGNATURE----- --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl-- From nobody Wed Nov 12 11:19:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4957C1ACEDE; Wed, 12 Nov 2014 11:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7spnw8ICJUSr; Wed, 12 Nov 2014 11:19:09 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DC61A914F; Wed, 12 Nov 2014 11:19:08 -0800 (PST) Received: from dhcp-b324.meeting.ietf.org (dhcp-b324.meeting.ietf.org [31.133.179.36]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sACJIsa6092754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 20:18:57 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <546327F2.7040901@massar.ch> Date: Wed, 12 Nov 2014 09:18:57 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yxisaQpwjxQdqG4x8O_6kKRIat0 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 19:19:11 -0000 Before answering Jeroen, about the draft in the original subject: huh? I = don't understand the problem. Why would PMTUD packets need to flow over = the same path as the forward packets unless the load balancing is over = multiple paths with unequal MTUs? And in the latter case: DON'T DO THAT. On 11 Nov 2014, at 23:27, Jeroen Massar wrote: > As the layer 3/4 balancer is then looking into the lower layers anyway > (ICMPv6), they don't need the flow-label as then they can then also = look > at TCP/UDP ports which are much better for uniqueness than an > arbitrarily set 20 bit label instead of a much better src & dst-port =3D= > 2x16bit =3D 32bits; That may or may not be the case, opinions about the best way to do = something have no bearing on what's out there in the real world. If I were to implement ECMP for IPv6 I would love to be able to use the = flow label for this rather than overload port numbers which have a = completely different purpose, aren't even available in some types of = packets and aren't always found at the same offset from the beginning of = the packet. (Also, it would be cool for multipath TCP to express path = selection through changing the flow label.) But the problem is that some implementations don't set the flow label. The length of the fields is irrelevant because all of this will be = hashed to a handful of bits anyway. > Or we can keep living in a world where the MTU of IPv6 will defacto be = 1280. > While in the proposal I made that MTU can be anything upwards from = 1280. Which proposal? IPv6 traffic is routinely 1500 bytes today and PMTUD failures are = _relatively_ infrequent. Of course 1500 is nothing to write home about = either, we really need to go beyond that. See: http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 I'll be presenting it on Friday.= From nobody Wed Nov 12 11:22:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB061ACF07; Wed, 12 Nov 2014 11:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Y-RMY989wM0G; Wed, 12 Nov 2014 11:22:25 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9533D1A19E9; Wed, 12 Nov 2014 11:21:54 -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 sACJLs4i010423; Wed, 12 Nov 2014 11:21:54 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sACJLoga010209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Nov 2014 11:21:50 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.131]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 11:21:50 -0800 From: "Templin, Fred L" To: Jeroen Massar , Brian E Carpenter Thread-Topic: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) Thread-Index: AQHP/lrXoiax4UBNqkesFhNd01Xe0JxdXFTg Date: Wed, 12 Nov 2014 19:21:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D847EE@XCH-BLV-504.nw.nos.boeing.com> References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> In-Reply-To: <546327F2.7040901@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/g39MMzQhiYREm1cCkW1OwbCS8ak Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 19:22:27 -0000 Hi, > http://www.ietf.org/id/draft-massar-v6man-mtu-label-00.txt This looks very similar to RFC1063, which was obsoleted by RFC1191. There was an analysis done that more or less concluded the RFC1063 was for all practical purposes not deployable. > Or we can keep living in a world where the MTU of IPv6 will defacto be 12= 80. >=20 > While in the proposal I made that MTU can be anything upwards from 1280. What you are proposing is not the only way forward to accomplish this. RFC4821 progressively grows the size of packets it sends to achieve a more optimal size even if no PTBs are received. Also, I do not see how what you are proposing applies to tunnels, or even more specifically tunnels-within-tunnels. Can you say more about that? Thanks - Fred fred.l.templin@boeing.com From nobody Wed Nov 12 11:23:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE5B1A1B76 for ; Wed, 12 Nov 2014 11:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 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, RP_MATCHES_RCVD=-0.594, 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 dSAyZAL9IbHP for ; Wed, 12 Nov 2014 11:23:20 -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 A6A431A19E8 for ; Wed, 12 Nov 2014 11:23:20 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BF4BCA2; Wed, 12 Nov 2014 20:23:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1415820198; bh=BIEkPV6tMbCt6cG/Xl2YzYJvGtPrUD+Pkpu22X2SGoA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iCth314a5kCzKoBm3xjSrrg5Irg9miB6lp63HaLZnecSCjG2n/u9WpqilFkEHOpOU esd80ixarEJ4OG+3wbx5SCrcX4/rXHcz/59hkFlbIMBxfv0m/g/4R4Dq3wQFmmJNO5 DCcSKw0nnDH8Ej9ldiUqMD8v3HwN112GXOjKUAiw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BB328A1; Wed, 12 Nov 2014 20:23:18 +0100 (CET) Date: Wed, 12 Nov 2014 20:23:18 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20141112090344.79F712367D9C@rock.dv.isc.org> Message-ID: References: <546309A7.1020007@massar.ch> <20141112090344.79F712367D9C@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: http://mailarchive.ietf.org/arch/msg/v6ops/mphuWRVO5ROunt_6Uo_EODZZyb8 Cc: IPv6 Ops WG Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 19:23:26 -0000 On Wed, 12 Nov 2014, Mark Andrews wrote: > What hurts 6to4 is broken relays and firewalls blocking the traffic. Correct. There is nothing wrong with 6to4 as a protocol, apart from the fact that human nature (or whatever) makes it not work in reality. Thus we need to get rid of it, and make sure people are running IPv6 natively. Operationally, tunneling is hard to get working, asymmetric tunneling is worse than the managed tunnels (point to point) or tunnels that are managed by a single entity (6RD), because when they break it's harder to fault find. > What the purists don't like is symetric routing and that it is not > native. I guess you meany "asymmetric"? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Nov 12 11:42:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFCD1ACFE2; Wed, 12 Nov 2014 11:42:38 -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 73P01z9ljGDx; Wed, 12 Nov 2014 11:42:36 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE641A1A7F; Wed, 12 Nov 2014 11:42:36 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so6040332wiv.0 for ; Wed, 12 Nov 2014 11:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k1OicroDEf6ESyrENN/GZOmUTfSzcWNc9yEdGziBrkE=; b=mi4Ux1RcmIGm871XMg6/dDQb3m0O76o3svDx5LkVnUCfos/Bmr964PXoXuzAhfdJjI WFlvr1M0ErrNCy3D9r3hriKiRISu0MA9Wq0LB+ELYhPj5qQ3sv5gb30TvVI+8u0JijJN ZkyRxiBjn6CtLAXlfMnVVo6Hv6JLq9/apJ86rNJ+FQLD9SAh3Q3D3QKAPjkHGXv/Y2NA gBvVe47nZXXblUy7/uVaMld5TOpDQSLPIInla4GrTPdkdrKXW0Y8J4z5MtokfePzksGU uRIdjNG5n/jbEWFYvyWLzDRYepm1vGYIsGubLZllGc+BuzMifGBfuaSyHW+ExCg5gKhQ ec7Q== X-Received: by 10.180.107.1 with SMTP id gy1mr52585298wib.8.1415821355218; Wed, 12 Nov 2014 11:42:35 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id ji10sm22834612wid.7.2014.11.12.11.42.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 11:42:34 -0800 (PST) Message-ID: <5463B82F.1050704@gmail.com> Date: Thu, 13 Nov 2014 08:42:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x0825u-PkGixtaPR34YipMDZnb0 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 19:42:38 -0000 On 13/11/2014 08:18, Iljitsch van Beijnum wrote: > Before answering Jeroen, about the draft in the original subject: huh? I don't understand the problem. Why would PMTUD packets need to flow over the same path as the forward packets unless the load balancing is over multiple paths with unequal MTUs? And in the latter case: DON'T DO THAT. It would imply that one path was native and the other path was tunnelled, or something else rather strange. I agree with "don't do that" but maybe the real world tells us that people do do that? > On 11 Nov 2014, at 23:27, Jeroen Massar wrote: > >> As the layer 3/4 balancer is then looking into the lower layers anyway >> (ICMPv6), they don't need the flow-label as then they can then also look >> at TCP/UDP ports which are much better for uniqueness than an >> arbitrarily set 20 bit label instead of a much better src & dst-port = >> 2x16bit = 32bits; > > That may or may not be the case, opinions about the best way to do something have no bearing on what's out there in the real world. > > If I were to implement ECMP for IPv6 I would love to be able to use the flow label for this rather than overload port numbers which have a completely different purpose, aren't even available in some types of packets and aren't always found at the same offset from the beginning of the packet. (Also, it would be cool for multipath TCP to express path selection through changing the flow label.) > > But the problem is that some implementations don't set the flow label. Right. Which is why the recent updates to the flow label standard allow routers to set the flow label on behalf of hosts that don't. Also why RFC 6438 "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels" was written (and my co-author on that was a real genuine operator). If vendors aren't implementing the most recent flow label RFCs, it's presumably because operators aren't asking for it. I think they're even less likely to ask for encoding MTU in the flow label to be suppported, even if the IETF changed the standard yet again. Brian > > The length of the fields is irrelevant because all of this will be hashed to a handful of bits anyway. > >> Or we can keep living in a world where the MTU of IPv6 will defacto be 1280. > >> While in the proposal I made that MTU can be anything upwards from 1280. > > Which proposal? > > IPv6 traffic is routinely 1500 bytes today and PMTUD failures are _relatively_ infrequent. Of course 1500 is nothing to write home about either, we really need to go beyond that. See: > > http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 > > I'll be presenting it on Friday. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 12 12:11:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783A41A879F; Wed, 12 Nov 2014 12:10: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY0IrXNf66jD; Wed, 12 Nov 2014 12:10:52 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709C81AD037; Wed, 12 Nov 2014 12:09:17 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id F01FF10060A58; Wed, 12 Nov 2014 20:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415822954; bh=YHA+23ggX88eC0NjGYI0bVAfeAEM1O+rBmpltGzrjyE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ZXrX2mm5+UEnMcSKcAb41WjrC62eHdbyYG5+vaPpuB8GNsPXrOzeWxr5yEKJrlZZA jZGH4HXVDxRqKnxOAYo2bzAXU7vEuOIm9RT7cgFoS3UT/Qkmtsb3jyIOfgW1zP0fbI 08RJywvi6VIWUpUsuoxtbpWcLlQsPLRXI3Nnr1/3EJz323brv/1OvVFw96nnUXuXxm 63Jv9+b+Jkt5nOvkjmGB8UwfDRsnEDmnAnbVpGzKsVZ9Trdl2z++qQCWTJtnGG3h7m ca5AdtZ0781FQ4sox5MuY0eu96jEPeBt4ObrJExVVatq0jDLr8G12x7imeGuddkiDy BPcaVMkaWbLkQ== Message-ID: <5463BE68.8050106@massar.ch> Date: Wed, 12 Nov 2014 21:09:12 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/980Vi20v9HDj58AIrltAcoqWreQ Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 20:10:59 -0000 On 2014-11-12 20:18, Iljitsch van Beijnum wrote: > Before answering Jeroen, about the draft in the original subject: huh? > > I don't understand the problem. Why would PMTUD packets need to flow over > the same path as the forward packets unless the load balancing is over > multiple paths with unequal MTUs? And in the latter case: DON'T DO THAT. Different paths is just an example, and it indeed mostly happens on the wild Internet, likely not behind your LB and especially not with a different MTU there (though some people might GRE tunnel some traffic somewhere else actually, but that is very scary). Note that in the ECMP draft the loadbalancer does not _terminate_ the connection and thus handle the ICMPv6 unreachable but just forwards the packets (likely even without decreasing TTL). This unlike for instance a TCP proxy that thus does terminate the TCP connection (or UDP etc) and then creates a new connection to a backend system. > On 11 Nov 2014, at 23:27, Jeroen Massar wrote: > >> As the layer 3/4 balancer is then looking into the lower layers anyway >> (ICMPv6), they don't need the flow-label as then they can then also look >> at TCP/UDP ports which are much better for uniqueness than an >> arbitrarily set 20 bit label instead of a much better src & dst-port = >> 2x16bit = 32bits; > > That may or may not be the case, opinions about the best way to do > something have no bearing on what's out there in the real world. But this is exactly what those load balancers do and why they fail at it. Hence why there is a draft that is a WG doc out on this problem. > If I were to implement ECMP for IPv6 I would love to be able to > use the flow label for this rather than overload port numbers > which have a completely different purpose, aren't even available > in some types of packets and aren't always found at the same offset > from the beginning of the packet. (Also, it would be cool for multipath > TCP to express path selection through changing the flow label.) Note that the Flow-Label set in the ICMPv6 PTB is not the same as the original flow. Which thus causes the issue as then the ECMP decision goes to the wrong place. > But the problem is that some implementations don't set the flow label. I'll have to run a check grabbing packets of the wire and analyzing the distribution at one point. But looking at various open source stacks and wireshark, I don't see much of labels in my local network. > The length of the fields is irrelevant because all of this will be hashed to a handful of bits anyway. Quite correct. Hence why bother with flow-labels at all when src+dst gives you those bits? :) >> Or we can keep living in a world where the MTU of IPv6 will defacto be 1280. > >> While in the proposal I made that MTU can be anything upwards from 1280. > > Which proposal? See: http://www.ietf.org/id/draft-massar-v6man-mtu-label-01.txt Originally in the email, now nicely in a draft so that everybody can comment on it in a much easier way. > IPv6 traffic is routinely 1500 bytes today and PMTUD failures are _relatively_ infrequent. Tell that to both Google who is bandaiding this by forcing the MSS to a small size and Akamai who are currently at a 1.5 months long outage likely related to this problem. > Of course 1500 is nothing to write home about either, we really need to go beyond that. See: > > http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 > > I'll be presenting it on Friday. Check: http://www.ietf.org/id/draft-massar-v6man-mtu-label-01.txt For a much easier solution that and also solves this for load balancer setups. It does not discuss direct-neighbor discovery, but it could do that too. IMHO though on the same link it should be using the MTU configured on the L2 (eg Ethernet) and L3 (IP) should not be second guessing that configuration. Greets, Jeroen From nobody Wed Nov 12 12:14:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759C61AD02E for ; Wed, 12 Nov 2014 12:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_wNKc5X9riQ for ; Wed, 12 Nov 2014 12:14:37 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E871AD1A6 for ; Wed, 12 Nov 2014 12:12:28 -0800 (PST) Received: from t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org (t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:6d42:b7fe:f54:8b94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sACKCFZB093280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Nov 2014 21:12:18 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> Date: Wed, 12 Nov 2014 10:12:17 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rvKJpENyy2273Qkx4ALxjCeC7w8 Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 20:14:41 -0000 I've been talking to a few people and I think there is potential for a = draft that lets home gateways (and any other system so inclined) have = IPv6 tunneling enabled out of the box (like 6to4) but in a way that = works pretty reliably (unlike 6to4). My question to (potential) implementers: - Is requiring HTTP digest authentication problematic? - Is requiring HTTPS problematic? - Is requiring JSON parsing problematic? * Would using plain text similar to HTTP headers to pass parameters = be better? - Is requiring DHCPv6 (the prefix delegation client role) problematic? Thanks, Iljitsch= From nobody Wed Nov 12 12:17:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CCD1A873C; Wed, 12 Nov 2014 12:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y8RJaMiUgsl; Wed, 12 Nov 2014 12:17:28 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB101AD09D; Wed, 12 Nov 2014 12:15:54 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 50DEE10060A5D; Wed, 12 Nov 2014 20:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415823352; bh=rIg5bFnjuIfH8oetRULGkdfgxUWfonneLPpiubbsvnE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ZIHvaAj7AP/7QYOWOxnZ/T4N0DAp6I42EmP8mAoAPXVafNfr+Q4wREw0bAyOqwDa1 +GYnXle9XmIVFl16oIAmIAGGdYM0DlxRar/w9/BAel5a39rpYnxO1o9NPjojazxeCF Iumt9GivkunOwsY0pnRQleOniMXB33DCeBufZ9Egacy2RhH7DSaW+NDQKqBshkGUr8 yH8CB0jJRiC4yvMrAs5RhDnHDXUY3O/iGhKk/+JAthWuY9egMiODbqF03OXbtCMUtc RWFJaxjct/aV1ZgX95mfgLmWZa5pFiqS888OTPptEghh1GFO9EFgYoQXEPNNQV4uj9 HwJqDgf4rqopg== Message-ID: <5463BFF5.6000300@massar.ch> Date: Wed, 12 Nov 2014 21:15:49 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" , Brian E Carpenter References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> <2134F8430051B64F815C691A62D9831832D847EE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D847EE@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iVufql4JKIHdwggJjIHO757izO4 Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 20:17:30 -0000 On 2014-11-12 20:21, Templin, Fred L wrote: > Hi, > >> http://www.ietf.org/id/draft-massar-v6man-mtu-label-00.txt > > This looks very similar to RFC1063, which was obsoleted by RFC1191. There > was an analysis done that more or less concluded the RFC1063 was for all > practical purposes not deployable. Thanks for mentioning that RFC, I missed the "Obsoletes: 1063" at the top of 1191, while 1063 has a lot more background, even though it is from 1988. Will study that and related google-able documents to see if I can gain some extra info out of it. >> Or we can keep living in a world where the MTU of IPv6 will defacto be 1280. >> >> While in the proposal I made that MTU can be anything upwards from 1280. > > What you are proposing is not the only way forward to accomplish this. > RFC4821 progressively grows the size of packets it sends to achieve a > more optimal size even if no PTBs are received. The major problem with that sending a lot of packets is RTT. The big content providers want to go to 0-RTT. Hence protocols like QUIC coming into existence. Also, at the scale of say a Google, Amazon, Akamai, you don't want to start spraying more packets and doing probing around the world for such a situation. The proposed http://www.ietf.org/id/draft-massar-v6man-mtu-label-01.txt avoids any need for that too. > Also, I do not see how what you are proposing applies to tunnels, Tunnels typically have smaller MTUs than native links, hence lower MTU. But there are also other link technologies that are not tunnels that use a non-1500 MTU. Hence why tunnels are not mentioned in the document as it is a generic "lower MTU case" > or even more specifically > tunnels-within-tunnels. Can you say more about that? For the IP layer does it matter how many things are nested into it? As long as the minimum MTU for a link technology is 1280 all is fine. If the link-technology has a lower MTU than 1280 it will have to make sure that it can transport those packets by splitting them up in a magical way. Greets, Jeroen From nobody Wed Nov 12 12:29:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15F71A1A28; Wed, 12 Nov 2014 12:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4lh6RBeESBz; Wed, 12 Nov 2014 12:28:58 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2F01A07BC; Wed, 12 Nov 2014 12:28:58 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C9A1C10060A58; Wed, 12 Nov 2014 20:28:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415824136; bh=MmZzbfNPhuVqEDR+GXm28Ie8LcjiG9m0SOq378RtG1M=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Br1sAfltwCl60DEJnHbi6zCoePtet/df6h/aqS6X8ieGJZMoX3pAWzh3rZqNb8l0l Z5yLLhwXT6K5xkcAcFt4aVjL+Z9kkOEdYkS8FRRhK5lIJA5teknzHZTQPrXd4pxeWj wYJ8hrw4/VoSbgQfOvk8ys+SXTEhD5vTOfX2ODEvfPth+9qDT0ZfyxjiuV0g4iQzCn zLQ4kPCK2yoZPYqDku2lxvQx14sQoyo5euHdCK31sMKxHhlxhml/IOLFjSmjhIX+0/ cE5IPWj6xxxkz20H/UIXO3+yxj1CLlsEjqVf4EfJFY4um3g2gZclc6j6WGdPiAXlYU ipAgQpnULLpXg== Message-ID: <5463C306.5040306@massar.ch> Date: Wed, 12 Nov 2014 21:28:54 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter , Iljitsch van Beijnum References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> <5463B82F.1050704@gmail.com> In-Reply-To: <5463B82F.1050704@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2Ttv_EjtBrSBZlSs-UTS8-u-wkE Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 20:29:01 -0000 On 2014-11-12 20:42, Brian E Carpenter wrote: > On 13/11/2014 08:18, Iljitsch van Beijnum wrote: >> Before answering Jeroen, about the draft in the original subject: huh? I don't > understand the problem. Why would PMTUD packets need to flow over the same path > as the forward packets unless the load balancing is over multiple paths with > unequal MTUs? And in the latter case: DON'T DO THAT. > > It would imply that one path was native and the other path was tunnelled, > or something else rather strange. I agree with "don't do that" but maybe > the real world tells us that people do do that? Behind the LB, not likely though possible if one is moving datacenters and thus forwarding packets to the new backend in another datacenter which is linked up over a GRE tunnel to move those bits around. But it is then a much better idea terminate the TCP conection on the host that is the loadbalancer or directly behind it and do a TCP or application-specific proxy. The document (draft-v6ops-pmtud-ecmp-problem-01) mentions problems with ICMP because the *internet* is inherently asymmetric. At least I rarely see a symetric link when crossing an ocean. >> On 11 Nov 2014, at 23:27, Jeroen Massar wrote: >> >>> As the layer 3/4 balancer is then looking into the lower layers anyway >>> (ICMPv6), they don't need the flow-label as then they can then also look >>> at TCP/UDP ports which are much better for uniqueness than an >>> arbitrarily set 20 bit label instead of a much better src & dst-port = >>> 2x16bit = 32bits; >> >> That may or may not be the case, opinions about the best way to do something have no bearing on what's out there in the real world. >> >> If I were to implement ECMP for IPv6 I would love to be able to use the flow label for this rather than overload port numbers which have a completely different purpose, aren't even available in some types of packets and aren't always found at the same offset from the beginning of the packet. (Also, it would be cool for multipath TCP to express path selection through changing the flow label.) >> >> But the problem is that some implementations don't set the flow label. > > Right. Which is why the recent updates to the flow label standard allow > routers to set the flow label on behalf of hosts that don't. In that case if we have: A - R1 - R2 - R3 - B A sets FL = 0 R1 passes it R2 "updates" the FL to R3 passes it B receives B sends back a packet with FL= ... A receives a unknown flow with FL= I don't see how that can work if some people think to be smart and start firewalling on the FL... Or what about a IPFIX export from R1, those flows suddenly are different, which completely defies having a unique label. More importantly though as the label is randomly set it is unknown if it is 0 (common) or a random label, or changed by an intermediary. Hence for IPFIX/analysis functions, for loadbalancing and firewalling that label as defined is IMHO completely useless.. > Also why > RFC 6438 "Using the IPv6 Flow Label for Equal Cost Multipath Routing and > Link Aggregation in Tunnels" was written (and my co-author on that was > a real genuine operator). (https://tools.ietf.org/html/rfc6438) As draft-v6ops-pmtud-ecmp-problem-01 shows, there is a major oversight called ICMP in that system. There is also no reference to ICMP or Packets Too Big in that doc. IMHO, that is a major Errata.... Note that it appears not many people thought/realized the 'pmtud-ecmp-problem', hence why that is a majorly awesome draft that definitely should become an RFC. > If vendors aren't implementing the most recent flow label RFCs, it's > presumably because operators aren't asking for it. I think they're even > less likely to ask for encoding MTU in the flow label to be suppported, > even if the IETF changed the standard yet again. Possibly because they don't see the value of such a Flow Label as nothing uses it. I am fairly confident that my "MTU Label" proposal though IS valuable to solve a lot of real life problems AND as a bonus allows nodes to negotiate a Internet wide high MTU. Google and likely Akamai (as we don't know their problem yet...) would have likely not have an outage if we had this in place. With all the Fiber deployments coming out, there is a major difference between a 1500 MTU and a 9000 MTU.... even bigger as the 18% for 1280->1500, 1500->9000 is a factor 5 less packets to send (and that is while ignoring IP, TCP headers etc). Greets, Jeroen From nobody Wed Nov 12 12:38:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E51A8774 for ; Wed, 12 Nov 2014 12:38:10 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_KcWN8N3EVj for ; Wed, 12 Nov 2014 12:38:09 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562CB1A8750 for ; Wed, 12 Nov 2014 12:38:09 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 990BA10060A5D; Wed, 12 Nov 2014 20:38:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415824686; bh=YzDLNfTCdvyeVcdKzLqrzdxLCdsyFH5kDJ8YhjFEonE=; h=Date:From:To:Subject:References:In-Reply-To; b=FpWqjOFtoCtXEntmMuWoQ61Lsmq2iaN74WPAPlrsx/8+P7hsB7oz8wbWb/J6PKXk4 dRa9KVoR2hyMt6+J/H0oeKqqtaVJ2skt0yIZd4JcFRun6pUdQwYWZMsmE2xoE4wdmJ i+VCpYzhbHOh/bBdaDPnftdzG8SljMCRZV/sZ2k06aTtytmgRqqScVZSPVDhJx12um joWo877gRHHJfWixrhMDkFs67UBdjWAQ5Wo65fUiqqJ+8Tm9CYucXT9NuPYo9UASs1 ovirKOY+Vy+UeMq0DmSWPe4gggy5av9inFAIHrxskZ9AftDdtZ8j7MIayK+d0jM/a1 QRuJgm2BGlDOw== Message-ID: <5463C52C.8060908@massar.ch> Date: Wed, 12 Nov 2014 21:38:04 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum , "v6ops@ietf.org WG" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WKjZbadbRdLUdsAGSNYuw_vyzX8 Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 20:38:11 -0000 On 2014-11-12 21:12, Iljitsch van Beijnum wrote: > I've been talking to a few people and I think there is potential for > a draft that lets home gateways (and any other system so inclined) > have IPv6 tunneling enabled out of the box (like 6to4) but in a way > that works pretty reliably (unlike 6to4). "pretty reliably" or "reliable" As somebody who is terminating an extreme amount of tunnels to get those people who don't have native IPv6 some IPv6: can you provide more details please of what direction you are thinking of? What does 6rd not resolve and what does this better? And as below you are asking for HTTP things, what is it that TSP and TIC do not resolve or do 'incorrectly'? Note that there is no magic "IPv6 Tunnel Broker Discovery". Somebody has to type a URL somewhere or provide parameters. And the moment that you can do DHCPv4 you can do 6rd. > My question to (potential) implementers: > > - Is requiring HTTP digest authentication problematic? > - Is requiring HTTPS problematic? > - Is requiring JSON parsing problematic? Typically these components are already available in those systems. The problem with HTTPS and anything security though is this annoying thing called time. Most CPEs are not NTP synced as they do not have a RTC. And without proper time you can't do proper TLS or any other variant of crypto that has timestamps for replayattack protection etc. > * Would using plain text similar to HTTP headers to > pass parameters be better? Depends completely on what you are talking about. Examples would be useful. > - Is requiring DHCPv6 (the prefix delegation client role) > problematic? Any proper "IPv6 capable CPE" SHOULD have this. Greets, Jeroen From nobody Wed Nov 12 12:46:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC49A1A19E2 for ; Wed, 12 Nov 2014 12:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m03CdQM-IUkb for ; Wed, 12 Nov 2014 12:46:21 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 46CA01A07BC for ; Wed, 12 Nov 2014 12:46:21 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Nov 2014 14:46:19 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f180.google.com [209.85.223.180] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f180.google.com with SMTP id y20so14477588ier.39 for ; Wed, 12 Nov 2014 12:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ULjaiMykhSEftDItxD0ybOohnrd2EZK5MI5kdrFRkGc=; b=dH35zyFqZMYDHrob+eIaafIuPa6RTf4WECyjyP4AQnmMNPLyya3Qf8PMkXcgNBGyaf 0AT3ZvwdL5D73vcRvAudEGkP1P5mio8/1CfO48z0b7SbYdU6zVkvoAdMEgNPvyZOY5Dg uyL2BdYK1l8xsghDwFwUhKd4DVGEjBVizGObg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ULjaiMykhSEftDItxD0ybOohnrd2EZK5MI5kdrFRkGc=; b=OxzqVdlFnV6WKy3flzD5M9M3milYNLQlMZdhvM5WdLRClCgUWCR5qOLieowrQwkm7r QSZ/GGHK3H8MIDxbBObmx/gbD7TcrCr8BprTqdS0scGQ81kLYL1jvaLepyYIgVm+5gWP 12zoIiebRC93xq+kXbZ20hOJVEwOGfUrduz/MF26p0tqa5mZ622JCRceF6eefaGYkK0k SyP1DiQk1yZaVoSKjf0hUoM+YpgDj2aXl/1peLvZUUbjXoo20ctSUtOxijgWLTdG3wmo 0lYrOYuDEYz17njdsGBULKycqdlP+SLpiVodis6Tauz2Z06X+Pq0pPNJNKrM+Vx9RvCV NanA== X-Gm-Message-State: ALoCoQk436qqaIA6Q30ty7gLjewpNFH8ihsQoEyiO1P7ydpdUJZ4bgzFX8Q1RXmGEIh2yvEXbFtDGGUKwlxNy8/Wh71CcpxWaoqiPNKWyoWSH29cvzMop1MKK3MRlj5VYWwUlCfAVt/x X-Received: by 10.50.26.99 with SMTP id k3mr42095921igg.47.1415825178728; Wed, 12 Nov 2014 12:46:18 -0800 (PST) X-Received: by 10.50.26.99 with SMTP id k3mr42095909igg.47.1415825178553; Wed, 12 Nov 2014 12:46:18 -0800 (PST) Received: from x-134-84-51-131.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:3c92:9598:55d4:c24a]) by mx.google.com with ESMTPSA id f17sm11795522iof.3.2014.11.12.12.46.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 12:46:17 -0800 (PST) Message-ID: <5463C716.1030805@umn.edu> Date: Wed, 12 Nov 2014 14:46:14 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> In-Reply-To: <546271A2.907@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0v51yuDRxAMU5ewcBoTeU-KVBWo Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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: Wed, 12 Nov 2014 20:46:23 -0000 On my first pass I missed the current title "Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)", this implies more than is intended by the current consensus. So, I'd suggest the title be changed to reflect the new scope of the Draft, how about "Deprecating the Anycast Prefix for 6to4 Relay Routers". More responses inline; On 11/11/14, 14:29 , Brian E Carpenter wrote: ... > On 12/11/2014 08:33, David Farmer wrote: ... >> But, I feel the Draft should also either update or replace RFC6343. >> Minimally, I think it is important for there to be a metadata linkage >> between RFC6343 and the Draft. I would suggest a formal update to >> Section 4 of RFC6343 substituting the use of Router 6to4 in place of >> Anycast 6to4. > > 6343 is non-normative, so I'm not sure that we need to formally > update it. Also I don't agree that we should *encourage* people > to apply the Router 6to4 scenario (which has been essentially > ignored by the market for 13 years). But you are correct that some > of the guidelines in 6343 might be taken as a positive recommendation > to run an anycast relay, so how about adding this: > > "The guidelines in Section 4 of [RFC6343] remain valid only for > those who choose to continue operating Anycast 6to4 despite its > deprecation." OK, that is probably good enough, but I'd still like to see a metadata linkage from RFC 6343 to the Draft such that an update provides even though RFC 6343 is non-normative. >> Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as >> the IPv4 source address for Return Relay traffic, this no longer seem >> appropriate with the deprecation of 192.88.99.1, the prefix >> 192.88.99.0/24, and Anycast 6to4 in general. The 6th paragraph of >> Section 4 of the Draft discusses Return Relays and references Section >> 4.5 of RFC6343, I believe the intent is that "content providers might >> choose to continue operating such a relay", but I think the >> recommendation regarding the use of 192.88.99.1 as the IPv4 source >> address of such traffic, contained in Section 4.5 of RFC6343 could be >> confusing and is no longer appropriate. > > Why? Setting 192.88.99.1 as a *source* address is orthogonal to whether > it's filtered by the routing system as a destination. It's pretty much > harmless. I guess my issue was that the recommendation that routes for 192.88.99.1 be filtered will be taken by some operators to also filter traffic to or from 192.88.99.1 as well. How about an explicit recommendation against filtering traffic to or from 192.88.99.1, then the source address issue is orthogonal. But, if traffic sourced from 192.88.99.1 gets filtered, then the issue is not orthogonal. Also, I'd like to see the recommendation expanded beyond just "Internet service providers", how about "All networks, but in particular Internet service providers". I'd also like to see the recommendations regarding Return Relays to include similar wording, focusing on, but not limited to content providers. So how about replacing; Internet service providers SHOULD filter out routes to 192.88.99.1. With; All networks, but in particular Internet service providers, SHOULD filter routes for 192.88.99.1 or the prefix 192.88.99.0/24, yet they SHOULD NOT filter traffic sourced from or destine to 192.88.99.1. >> The draft says RFC6890 should be updated to remove "the 6to4 relay >> anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be >> updated. RFC68980 created "Special-Purpose IP Address Registries", no >> update to the RFC is necessary, IANA only needs to update the >> appropriate registry, which is already requested in section 5. You may >> want to specifically call out the appropriate registry "IPv4 >> Special-Purpose Address Registry" in section 5, but there is no need to >> update RFC6890. > > Table 10 of 6890 explicitly mentions 192.88.99.0/24, so I think it > does need to be updated. Actually we could do it right here in the > draft by adding "Updates: 6890" and specifying that Table 10 is > deleted. We do need to improve the IANA Considerations wording > on that point, too. From RFC 6890; 2.2.2. IPv4 Special-Purpose Address Registry Entries Tables 1 though 16, below, represent entries with which IANA has initially populated the IPv4 Special-Purpose Address Registry. Table 10, along with tables 1 through 16, are only the initial data to go in the registry, the whole point of creating the registry is not to have publish summary RFCs or even update an RFC every time something changes. With the execution of RFC 6890 and the creation of the registries, then the registries themselves become the authoritative references and sources for the information, the information in the tables of RFC 6890 are essentially Historical once the registries are created. So, unless the intent was to modify the policy for the registry itself I don't see the need to update RFC 6890. I'll leave it to you, the WG Chairs, and the AD to consult with IANA on the best solution, but below is what I was thinking for the IANA Considerations section. There isn't a status field for an entry in the registry, so I thought setting the name to "deprecated" with the original name in parenthesis seemed a reasonable solution to communicate the intended result. Would we want to add a Termination Date? Maybe like December 2020? 5. IANA Considerations IANA is requested to update the "IPv4 Special-Purpose Address Registry" [IANA.IPv4] for the prefix 192.88.99.0/24 as defined in Table 1. Redelegation of this prefix for any usage requires justification via an IETF Standards Action [RFC5226]. +----------------------+-------------------------------------+ | Attribute | Value | +----------------------+-------------------------------------+ | Address Block | 192.88.99.0/24 | | Name | Deprecated (6to4 Relay Anycast) | | RFC | [draft-ietf-v6ops-6to4-to-historic] | | Allocation Date | June 2001 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | True | | Reserved-by-Protocol | False | +----------------------+-------------------------------------+ Table 1: 6to4 Relay Anycast [IANA.IPv4] IANA, "IPv4 Special-Purpose Address Registry", . -- ================================================ 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 12 13:00:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA41A8AC0; Wed, 12 Nov 2014 13:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.594, 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 dola4TZ230oZ; Wed, 12 Nov 2014 13:00:15 -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 823481A89B9; Wed, 12 Nov 2014 13:00:15 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id AC5823493F2; Wed, 12 Nov 2014 21:00:13 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 262C8160059; Wed, 12 Nov 2014 21:03:34 +0000 (UTC) Received: from rock.dv.isc.org (dhcp-b712.meeting.ietf.org [31.133.183.18]) by zmx1.isc.org (Postfix) with ESMTPSA id 0F403160030; Wed, 12 Nov 2014 21:03:34 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 102AA2368F0B; Thu, 13 Nov 2014 04:03:45 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-reply-to: Your message of "Tue, 11 Nov 2014 13:25:23 -1000." Date: Thu, 13 Nov 2014 04:03:45 +1100 Message-Id: <20141112170345.102AA2368F0B@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i_TeZNpwuILbVvW6u8U6hanDAQo Cc: 6man , IPv6 Operations Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 21:00:16 -0000 In message , Lorenzo Colitti writes: > > On 11 Nov 2014 12:47 pm, "Mark ZZZ Smith" wrote: > > If high performance stateless and therefore load insensitive LB > distribution is needed or wanted, then perhaps something more simple that > doesn't use TCP or UDP port information might be better. For example, using > SA+DA based forwarding in the LB, and then statically mapping portions of > the SA address space to a particular LB host (e.g., 1/4 to LB host a, 1/4 > to LB host b etc. for four LB hosts), with all LB hosts configured with the > LB 'shared' unicast address (i.e., no NAT). If you want anything smarter > than that, then I think the LB needs to become stateful, and start > maintaining per-connection state. > > The problem is not that the TCP/UDP port changes. The problem is that the > source address of the intermediate router sending the PTB hashes > differently than the source address of the client. So SA+DA only > load-balancing won't help. The PTB MUST have the source and destination addresses of the original packet to work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Nov 12 13:06:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB571AD04C for ; Wed, 12 Nov 2014 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPrwHrALeBBN for ; Wed, 12 Nov 2014 13:06:21 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C790D1AD01C for ; Wed, 12 Nov 2014 13:06:17 -0800 (PST) Received: from t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org (t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:6d42:b7fe:f54:8b94] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sACL63nv093543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 22:06:06 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <5463C52C.8060908@massar.ch> Date: Wed, 12 Nov 2014 11:06:05 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <5463C52C.8060908@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/B5RJh-JlhnkHbPiY_VN5cko6_KM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 21:06:24 -0000 On 12 Nov 2014, at 10:38, Jeroen Massar wrote: >> that works pretty reliably (unlike 6to4). > "pretty reliably" or "reliable" Nothing is perfect in this world, but the idea is that it should be so = reliable that it can safely be turned on "set and forget" by default. > As somebody who is terminating an extreme amount of tunnels to get = those > people who don't have native IPv6 some IPv6: can you provide more > details please of what direction you are thinking of? Sure. > What does 6rd not resolve and what does this better? 6rd requires cooperation from your ISP. Now if your ISP offers 6rd, you = should use it. But a third-party home gateway doesn't necessarily know = how to configure itself to use 6rd for your ISP. If your ISP doesn't do = 6rd but you have a SixXS account, you'll want to use that account and = set up an AYIYA tunnel - but only if your home gateway supports AYIYA. = But maybe you have a public IPv4 address so you could use a proto 41 = tunnel. Today, determining all of this, selecting the right tunnel and then = configuring at least some parameters are done manually. Which is a = non-starter for most users. The draft aims not so much to come up with a = new tunneling mechanism but rather to allow devices to find and = configure existing tunneling options. However, I do think it will be necessary to define an additional = tunneling option that's simple to implement that could be the "mandatory = to implement" default one. > And as below you are asking for HTTP things, what is it that TSP and = TIC > do not resolve or do 'incorrectly'? The main issue is that you need to talk to someone who runs TSP or TIC. = So this wouldn't address the case where an ISP runs 6rd. Or you have an = account at a tunnel broker that doesn't use TSP or TIC (yes, I know, = hard to imagine). > Note that there is no magic "IPv6 Tunnel Broker Discovery". So let's invent it! >> * Would using plain text similar to HTTP headers to >> pass parameters be better? > Depends completely on what you are talking about. Examples would be = useful. Login: 02a9fb33ec0a@homegateways.org Password: ALLYOURBASE64AREBELONGTOUS Encap-Supported: proto41, rfc5969, net.sixxs.ayiya Negotiation-Supported: DHCPv6-PD, DHCPv6-IA, rfc4862, net.sixxs.tic Client-Address: 100.64.0.1 Client-Type: router From nobody Wed Nov 12 13:11:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029011AD2D9; Wed, 12 Nov 2014 13:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 WlqjQ_ra-Wta; Wed, 12 Nov 2014 13:11:36 -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 6AFB81AD272; Wed, 12 Nov 2014 13:11:35 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 6D5A23493BD; Wed, 12 Nov 2014 21:11:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DEAE716005D; Wed, 12 Nov 2014 21:14:51 +0000 (UTC) Received: from rock.dv.isc.org (dhcp-b712.meeting.ietf.org [31.133.183.18]) by zmx1.isc.org (Postfix) with ESMTPSA id CBF5B160030; Wed, 12 Nov 2014 21:14:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 734DF236A889; Thu, 13 Nov 2014 08:11:30 +1100 (EST) From: Mark Andrews References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <20141112170345.102AA2368F0B@rock.dv.isc.org> In-reply-to: Your message of "Thu, 13 Nov 2014 04:03:45 +1100." <20141112170345.102AA2368F0B@rock.dv.isc.org> Date: Thu, 13 Nov 2014 08:11:30 +1100 Message-Id: <20141112211130.734DF236A889@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ioxGS_5IEv8StmgRrI232f8C77I Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 21:11:44 -0000 If one has a load balancer that cannot look into the ICMPv6 packet. Take it out of the rack. Put it in the back of the pickup and take it to the recycler. It is garbage and need to be treated as such. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Nov 12 13:33:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909E51AD3D9 for ; Wed, 12 Nov 2014 13:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpHbQK-QoLlX for ; Wed, 12 Nov 2014 13:33:35 -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 6A6A11AD3B4 for ; Wed, 12 Nov 2014 13:33: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 CC8A9631B2 for ; Wed, 12 Nov 2014 22:33:33 +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 71CA5631B1 for ; Wed, 12 Nov 2014 22:33:33 +0100 (CET) Received: (qmail 4003 invoked by uid 1007); 12 Nov 2014 22:33:33 +0100 Date: Wed, 12 Nov 2014 22:33:33 +0100 From: Gert Doering To: Iljitsch van Beijnum Message-ID: <20141112213333.GQ31092@Space.Net> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.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: http://mailarchive.ietf.org/arch/msg/v6ops/FIDPy1uS0pPXKHcG3sUSxZCKYJA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 21:33:37 -0000 Hi, On Wed, Nov 12, 2014 at 10:12:17AM -1000, Iljitsch van Beijnum wrote: > I've been talking to a few people and I think there is potential > for a draft that lets home gateways (and any other system so inclined) > have IPv6 tunneling enabled out of the box (like 6to4) but in a way > that works pretty reliably (unlike 6to4). I'm not sure where the value of that is. 10 years ago, I would have agreed that "getting IPv6 out to the people" is a good goal - but when this draft gets to the stage that you'll see devices actually shipping, it's 2016, and we'll have 30-40% native IPv6 in many countries already - which should create enough momentum by it's own... So, call me sceptic :) 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 12 14:23:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606311AD500 for ; Wed, 12 Nov 2014 14:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVBqx9-c5W8i for ; Wed, 12 Nov 2014 14:23:39 -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 89A221AD4EF for ; Wed, 12 Nov 2014 14:23:39 -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 sACMNakv026964; Wed, 12 Nov 2014 22:23:36 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sACMNakv026964 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1415831017; bh=tTHXLZ/wVHRfHdysGYtcYLBVRwU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=xniihgPbp4fpsx3SuWdwZmNLgIX2WfKQHNpGoKsM7RZq2rMI/FhJEqWz0o6UAEQGD eZLjckf2C0+GQa/nMwCHaspNfYeavwcEK/+kZYTfrkZuXtdXPtfyrsi2oU19ePfzXx ZCdoRDYcCVnXLzp9aCf+WdBHMh9DDygZpyHH4PDE= 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 qABMNa04888111955p ret-id none; Wed, 12 Nov 2014 22:23:37 +0000 Received: from [192.168.1.68] (host86-134-38-56.range86-134.btcentralplus.com [86.134.38.56]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sACMMHCT012194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 22:22:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tim Chown X-Mailer: iPhone Mail (12B411) In-Reply-To: <20141112213333.GQ31092@Space.Net> Date: Wed, 12 Nov 2014 22:22:16 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <20141112213333.GQ31092@Space.Net> <7BB42E6C-698C-4430-AFDA-B725114F1083@ecs.soton.ac.uk> To: Gert Doering X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qABMNa048881119500; tid=qABMNa04888111955p; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: sACMNakv026964 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y-t-Q5PAleFbvN3Pd_Nvqd6I_Hc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 22:23:43 -0000 > On 12 Nov 2014, at 21:33, Gert Doering wrote: > > Hi, > >> On Wed, Nov 12, 2014 at 10:12:17AM -1000, Iljitsch van Beijnum wrote: >> I've been talking to a few people and I think there is potential >> for a draft that lets home gateways (and any other system so inclined) >> have IPv6 tunneling enabled out of the box (like 6to4) but in a way >> that works pretty reliably (unlike 6to4). > > I'm not sure where the value of that is. > > 10 years ago, I would have agreed that "getting IPv6 out to the people" > is a good goal - but when this draft gets to the stage that you'll see > devices actually shipping, it's 2016, and we'll have 30-40% native IPv6 > in many countries already - which should create enough momentum by it's > own... Indeed. Tim > > So, call me sceptic :) > > 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 From nobody Wed Nov 12 14:25:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3AC1AD519 for ; Wed, 12 Nov 2014 14:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=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 HnejXt-udKfa for ; Wed, 12 Nov 2014 14:25:16 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF371ACE78 for ; Wed, 12 Nov 2014 14:25:15 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 2071B10063F26; Wed, 12 Nov 2014 22:25:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415831113; bh=Ouy4BsKY3cFsOUbF+Cgy/R2hUeCFAEp+0HWTwepOYpU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=SQVsFEfxY1gebckUA56vZ8IDhIDYxSiGEU0aqKFCrRECbEovzqkHkVKU/k3qKL940 84j+Q8KSjQlIRc4dN6HKUXrk+cLBeanAI9ZG7w/mFkyUvCvF0x6ZrZsmq3WV/lu+Cv B167KxXDxL+klS0BxZ48NZnN0GDiXJH3YFntkGwcT/lnwFNGb8SEM224Kex2NNaEsS XvSZ2By7pmEc/DlX2/5DwlJlhVNftKgQw5MbvX3ADA4YMZiAPGmD7fxh5UdYFCbv7p Mgy3Y20JtixIYZIOtcTlCJEWUk1NJkkQz1Ul35e0TukWSLPVlZLj56w7AB209J0bus 9poQ5towt5Wrg== Message-ID: <5463DE47.3000307@massar.ch> Date: Wed, 12 Nov 2014 23:25:11 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <5463C52C.8060908@massar.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FUmpX3XebAypde6jAdLCHcPLlrE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2014 22:25:26 -0000 Btw +1 on Gert Doering's comment "when this draft gets to the stage that you'll see devices actually shipping, it's 2016, and we'll have 30-40% native IPv6". I see it the same way, by then IPv6 should be much better spread. The people who want IPv6 will get it using the available methods, no need to standardize further; the testing base is large enough for real deployments to move on. Folks who just want "internet" (typically the HTTP/S portion) won't care about it (IPv4 or IPv6) anyway. On 2014-11-12 22:06, Iljitsch van Beijnum wrote: > On 12 Nov 2014, at 10:38, Jeroen Massar wrote: [..] >> What does 6rd not resolve and what does this better? > > 6rd requires cooperation from your ISP. Now if your ISP offers 6rd, > you should use it. But a third-party home gateway doesn't necessarily > know how to configure itself to use 6rd for your ISP. In all cases that I am aware of where ISPs chose to use 6rd those ISPs provide the CPEs or upgraded the CPEs to support 6rd. Though, for instance Swisscom.ch made the details of their 6rd relay available before that so that people could also test it with other CPEs. >If your ISP > doesn't do 6rd but you have a SixXS account, you'll want to use that > account and set up an AYIYA tunnel - but only if your home gateway > supports AYIYA. But maybe you have a public IPv4 address so you could > use a proto 41 tunnel. > > Today, determining all of this, selecting the right tunnel and then > configuring at least some parameters are done manually. As one really nice example: https://www.sixxs.net/wiki/Fritz!Box_general - User creates an account (most difficult part) - Request a heartbeat tunnel - Fill in username/password + tunnel_id in Fritz!Box - press "go". Though, that is the most simple of them. Other vendors have similar configuration options. > Which is a > non-starter for most users. The draft aims not so much to come up > with a new tunneling mechanism but rather to allow devices to find > and configure existing tunneling options. Discovery is an over hard thing. Especially as the market provides a variety of providers and such a mechanism requires centralization which none of them will like and nobody will properly maintain. Currently most folks will check: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers or do a Google^WBing search. and based on the properties of the providers, who they like and not, just like the normal DSL/Cable market, select the provider of choice. Indeed, folks who do not care about IPv6 won't do that. They are not missing out, and will get IPv6 one day when their normal provider turns it on. > However, I do think it will be necessary to define an additional > tunneling option that's simple to implement that could be the > "mandatory to implement" default one. That would be protocol-41. Afaik every Tunnel Broker does that. (though with Gogo6/Freenet6 I recall it is a fallback in TSP) TSP or AYIYA would be reasonable (IMHO) alternatives. Note that even Fritz!Box does not do AYIYA, then again it is mostly configured to sit on the public IP address (till the providers stuffs you behind CGN and that breaks). Currently to change protocols in SixXS between proto-41/heartbeat/AYIYA one has to change it in the UI; I have plans for making it possible to switch those based on incoming (signed) packets though, but something with available time. >> And as below you are asking for HTTP things, what is it that TSP >> and TIC do not resolve or do 'incorrectly'? > > The main issue is that you need to talk to someone who runs TSP or > TIC. When a provider supports it you'll just have to select that option and provider the name of the server (next to username/pass/tunnel_id). Hence, no need to do an extra protocol there. > So this wouldn't address the case where an ISP runs 6rd. 6rd details get distributed by DHCPv4. No need to solve that. See http://tools.ietf.org/html/rfc5969#section-7.1.1 > Or you > have an account at a tunnel broker that doesn't use TSP or TIC (yes, > I know, hard to imagine). Not hard to imagine: Hurricane Electric does not provide either. All their users manually cut & paste the parameters into their devices. Which btw is an option in SixXS since the IPng.nl days; though it won't easily work for heartbeat/AYIYA that have a password for signing packets. >> Note that there is no magic "IPv6 Tunnel Broker Discovery". > > So let's invent it! There have been discussions about this in the past and the conclusion was that a centralized service is unmaintainable and other options just rely on DNS attributes that would have to be either configured or that the user would have to indicate the label to use; which is just akin to server selection. >>> * Would using plain text similar to HTTP headers to pass >>> parameters be better? > >> Depends completely on what you are talking about. Examples would be >> useful. > > Login: 02a9fb33ec0a@homegateways.org That line @homegateways.org means that you have a centralized registrar. That list will never be up to date, nor will anybody like it that something like that is out of their control, eg because of outages which would thus cause their service to fail. The portion behind the @ could just be the server provider, and voila, you are selecting the negotiation protocol, be that TIC or TSP. > Password: ALLYOURBASE64AREBELONGTOUS > Encap-Supported: proto41, rfc5969, net.sixxs.ayiya > Negotiation-Supported: DHCPv6-PD, DHCPv6-IA, rfc4862, net.sixxs.tic If you have DHCPv6 the local provider is already handling you and you do not care about tunnels. If you have TIC support, well, the user can change that "TIC Server" option quite easily (though most UIs don't expose it ;) as then you know what the TIC server address is. Same for TSP, there you just fill in the TSP server name + username/password and done. > Client-Address: 100.64.0.1 The client never knows it's address; especially when it is behind a CGN or multiple layers of that nonsense. > Client-Type: router In IPv6 everything is considered a router. Most Tunnel Brokers will per default route a /64 to the tunnel endpoint. In SixXS that is simply possible as it is the tunnel address with the 49th bit set to 1 (hence why one sees an '8' there) and as it is that simple, it is a direct jump table, hence no lookups required and thus very fast. (Before sixxsd it would have required an extra /64 entry in the kernel and the typical Free OS requires a big prefix tree for looking up 16k routes; while with this trick it is there directly ;) Greets, Jeroen From nobody Wed Nov 12 15:30:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537571A1B4B; Wed, 12 Nov 2014 15:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 JsfFwRRX2FTn; Wed, 12 Nov 2014 15:30:18 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F2E1A1B44; Wed, 12 Nov 2014 15:30:17 -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 sACNUHBE030119; Wed, 12 Nov 2014 15:30:17 -0800 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sACNUEEu030102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Nov 2014 15:30:15 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.192]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 15:30:13 -0800 From: "Templin, Fred L" To: Jeroen Massar , Brian E Carpenter Thread-Topic: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) Thread-Index: AQHP/lrXoiax4UBNqkesFhNd01Xe0JxdXFTggACX+ID//6h/UA== Date: Wed, 12 Nov 2014 23:30:11 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D84C50@XCH-BLV-504.nw.nos.boeing.com> References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> <2134F8430051B64F815C691A62D9831832D847EE@XCH-BLV-504.nw.nos.boeing.com> <5463BFF5.6000300@massar.ch> In-Reply-To: <5463BFF5.6000300@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/w8NUSvtYY-l9MvK-AzVGRsG57fo Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 23:30:24 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Wednesday, November 12, 2014 12:16 PM > To: Templin, Fred L; Brian E Carpenter > Cc: IPv6 Operations; 6man > Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtu= d-ecmp-problem-01) >=20 > On 2014-11-12 20:21, Templin, Fred L wrote: > > Hi, > > > >> http://www.ietf.org/id/draft-massar-v6man-mtu-label-00.txt > > > > This looks very similar to RFC1063, which was obsoleted by RFC1191. The= re > > was an analysis done that more or less concluded the RFC1063 was for al= l > > practical purposes not deployable. >=20 > Thanks for mentioning that RFC, I missed the "Obsoletes: 1063" at the > top of 1191, while 1063 has a lot more background, even though it is > from 1988. Will study that and related google-able documents to see if I > can gain some extra info out of it. Good luck. You might want to consider digging the TCP-IP mailing list archi= ves from the 1982-1991 timeframe: http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ I dug through this years and years ago, but have since lost track of my not= es. > >> Or we can keep living in a world where the MTU of IPv6 will defacto be= 1280. > >> > >> While in the proposal I made that MTU can be anything upwards from 128= 0. > > > > What you are proposing is not the only way forward to accomplish this. > > RFC4821 progressively grows the size of packets it sends to achieve a > > more optimal size even if no PTBs are received. >=20 > The major problem with that sending a lot of packets is RTT. It's not a lot of packets. And, who cares about RTT? A flow can start off s= ending smalls (1500 or less) and then gradually work its way up to sending bigs (b= igger than 1500). But, communications are continuous and not in any way held up waiting for an MTU probe reply. > The big content providers want to go to 0-RTT. Hence protocols like QUIC > coming into existence. >=20 > Also, at the scale of say a Google, Amazon, Akamai, you don't want to > start spraying more packets and doing probing around the world for such > a situation. It is by no means a lot of packets - only an occasional probe to see if you= can do better than 1280. > The proposed http://www.ietf.org/id/draft-massar-v6man-mtu-label-01.txt > avoids any need for that too. Check the RFC1063 because I think you are proposing roughly the same thing. > > Also, I do not see how what you are proposing applies to tunnels, >=20 > Tunnels typically have smaller MTUs than native links, hence lower MTU. Well, but how big is "lower"? Once the IPv6 packet is encapsulated in IPv4 = and shipped out across the Internet, that IPv6 flow label is no longer accessib= le and legacy IPv4 routers would not honor it even if it were. There are only two = ways of policing the tunnel MTU - "clamp" it to something smaller than 1500, or = set it to unlimited. In the latter case, make sure everything 1500 and smaller = gets through even if a small amount of fragmentation is necessary, but let every= thing 1501 and larger in unfragmented and let them sink or swim on their own. > But there are also other link technologies that are not tunnels that use > a non-1500 MTU. Hence why tunnels are not mentioned in the document as > it is a generic "lower MTU case" You don't know how low "lower" is without some kind of tunnel MTU assurance= , the problem is worse for tunnels-within-tunnels. > > or even more specifically > > tunnels-within-tunnels. Can you say more about that? >=20 > For the IP layer does it matter how many things are nested into it? >=20 > As long as the minimum MTU for a link technology is 1280 all is fine. If you start out with a 1300 MTU tunnel, then you can run another 1280 tunnel through that. But, the next tunnel in line would see only 1260 and recursion hits a brick wall. > If the link-technology has a lower MTU than 1280 it will have to make > sure that it can transport those packets by splitting them up in a > magical way. For native IPv6 links, link-specific adaptation yes (see: 6lowpan). For tun= nels, there's nothing magic about IPv6 fragmentation - it just works. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 From nobody Wed Nov 12 16:05:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EEC1A0062; Wed, 12 Nov 2014 15:59:54 -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 TZsXR8Ca5sTm; Wed, 12 Nov 2014 15:59:48 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0C81A0053; Wed, 12 Nov 2014 15:59:47 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id l18so15379766wgh.38 for ; Wed, 12 Nov 2014 15:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DfD/UybkyQlDWpS2byd+LH9pwrtIGF1cPgXBM67F7rg=; b=AYbCWIatOfq2gdCjpWqHfGpzDwDGWHuemMCratoQwzkUrIxpky273waNjBv3isCrYl e/HapBnnyeNqOx2YjHSFW/O6ywCwQR5gb+UdBpNrwF/DcdFfx1chG7WCLX7Kcpr1Fw23 dH6GxqMNpLzD3mErUuyE/58SsBS39a821dCopumWjsI9Li7dTir8uCSRrYdGcfaAAua4 LYww0SgrzWCwEXC+R7Lex0oMXtTzEm+zTUpfUPkO3Q7snCAMv5ssnOirF2EjO4dk27YJ dGj5bfChGuCY3+uGJ4hiSG788lq08VMZDzN3we0L/siarAr64UI083mKA42EfVQvS/kC 6lgQ== X-Received: by 10.194.172.234 with SMTP id bf10mr68823955wjc.81.1415836786781; Wed, 12 Nov 2014 15:59:46 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id s10sm27568921wjw.29.2014.11.12.15.59.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 15:59:46 -0800 (PST) Message-ID: <5463F477.3040701@gmail.com> Date: Thu, 13 Nov 2014 12:59:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> <5463B82F.1050704@gmail.com> <5463C306.5040306@massar.ch> In-Reply-To: <5463C306.5040306@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yzCko4F7IAyEQjjRHGsButyX9jE Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Wed, 12 Nov 2014 23:59:54 -0000 On 13/11/2014 09:28, Jeroen Massar wrote: > On 2014-11-12 20:42, Brian E Carpenter wrote: ... >> Also why >> RFC 6438 "Using the IPv6 Flow Label for Equal Cost Multipath Routing and >> Link Aggregation in Tunnels" was written (and my co-author on that was >> a real genuine operator). > > (https://tools.ietf.org/html/rfc6438) > > As draft-v6ops-pmtud-ecmp-problem-01 shows, there is a major oversight > called ICMP in that system. > > There is also no reference to ICMP or Packets Too Big in that doc. > > IMHO, that is a major Errata.... >From what I learned during that discussion, an ISP doing that kind of tunnel would simply configure MTU >>1500 and assume that nobody tries a PMTU >1500. Any PTBs from further downstream could return on any ECMP path, of course. > Note that it appears not many people thought/realized the > 'pmtud-ecmp-problem', hence why that is a majorly awesome draft that > definitely should become an RFC. > >> If vendors aren't implementing the most recent flow label RFCs, it's >> presumably because operators aren't asking for it. I think they're even >> less likely to ask for encoding MTU in the flow label to be suppported, >> even if the IETF changed the standard yet again. > > Possibly because they don't see the value of such a Flow Label as > nothing uses it. Well, yes, it's a chicken/egg problem of course. RFC 6437 is a SHOULD in RFC 6434 "IPv6 Node Requirements". But these things take years to get into products. Brian > > I am fairly confident that my "MTU Label" proposal though IS valuable to > solve a lot of real life problems AND as a bonus allows nodes to > negotiate a Internet wide high MTU. > > Google and likely Akamai (as we don't know their problem yet...) would > have likely not have an outage if we had this in place. > > > With all the Fiber deployments coming out, there is a major difference > between a 1500 MTU and a 9000 MTU.... even bigger as the 18% for > 1280->1500, 1500->9000 is a factor 5 less packets to send (and that is > while ignoring IP, TCP headers etc). > > Greets, > Jeroen > > From nobody Wed Nov 12 16:05:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933D81A0065 for ; Wed, 12 Nov 2014 16:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_NAIL=2.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 ZChrPYIjF2zl for ; Wed, 12 Nov 2014 16:04:53 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8D71A0062 for ; Wed, 12 Nov 2014 16:04:53 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id y19so66903wgg.15 for ; Wed, 12 Nov 2014 16:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mPbKIzQ67Sy07j0zZukLhAQb8DZYjmrWBiP5E3kYhJs=; b=Ln+nyLnWg0WUofSOpNOYC2oxrGzvEE5edMVHpzkvdybl2K5IWLGkzofBepL2iKlhMy cCssH+hUE5DqOHBxgpNzDV/16GWnRB8yAauDeSZwvNOuITme9sQtyEsGd9syvbIIJBtO L8zANudwpIDukx0lKKkHUGUT2OjvELO5vCz6qpFmvn15F6T4HXu+7Iq28OGMZWKUtjYB /hpXb7sSW8R7k72DBZ8PZC0z5aMZ79uLGE3Z2P43CvsB1zsDLamfG2CvCjTFIqqxaUgb +JFUy9Ic8ruuoC7ixQ2R7hyVGwpxrH5XpWTgDJof5sL1SK3ALqP2/dZxkb1fJcqdd/jw Pfiw== X-Received: by 10.194.85.116 with SMTP id g20mr41058855wjz.18.1415837091996; Wed, 12 Nov 2014 16:04:51 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id p1sm33327477wjy.22.2014.11.12.16.04.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 16:04:51 -0800 (PST) Message-ID: <5463F5A8.9020009@gmail.com> Date: Thu, 13 Nov 2014 13:04:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> In-Reply-To: <5463C716.1030805@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wKQ4s0NTK8AqIDGdAi7zytKWx5I Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 00:04:55 -0000 Yes, we should tweak the title. Your other points are noted, pending the WGLC. Thanks Brian On 13/11/2014 09:46, David Farmer wrote: > On my first pass I missed the current title "Deprecating Connection of > IPv6 Domains via IPv4 Clouds (6to4)", this implies more than is intended > by the current consensus. So, I'd suggest the title be changed to > reflect the new scope of the Draft, how about "Deprecating the Anycast > Prefix for 6to4 Relay Routers". > > More responses inline; > > On 11/11/14, 14:29 , Brian E Carpenter wrote: > ... >> On 12/11/2014 08:33, David Farmer wrote: > ... >>> But, I feel the Draft should also either update or replace RFC6343. >>> Minimally, I think it is important for there to be a metadata linkage >>> between RFC6343 and the Draft. I would suggest a formal update to >>> Section 4 of RFC6343 substituting the use of Router 6to4 in place of >>> Anycast 6to4. >> >> 6343 is non-normative, so I'm not sure that we need to formally >> update it. Also I don't agree that we should *encourage* people >> to apply the Router 6to4 scenario (which has been essentially >> ignored by the market for 13 years). But you are correct that some >> of the guidelines in 6343 might be taken as a positive recommendation >> to run an anycast relay, so how about adding this: >> >> "The guidelines in Section 4 of [RFC6343] remain valid only for >> those who choose to continue operating Anycast 6to4 despite its >> deprecation." > > OK, that is probably good enough, but I'd still like to see a metadata > linkage from RFC 6343 to the Draft such that an update provides even > though RFC 6343 is non-normative. > >>> Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as >>> the IPv4 source address for Return Relay traffic, this no longer seem >>> appropriate with the deprecation of 192.88.99.1, the prefix >>> 192.88.99.0/24, and Anycast 6to4 in general. The 6th paragraph of >>> Section 4 of the Draft discusses Return Relays and references Section >>> 4.5 of RFC6343, I believe the intent is that "content providers might >>> choose to continue operating such a relay", but I think the >>> recommendation regarding the use of 192.88.99.1 as the IPv4 source >>> address of such traffic, contained in Section 4.5 of RFC6343 could be >>> confusing and is no longer appropriate. >> >> Why? Setting 192.88.99.1 as a *source* address is orthogonal to whether >> it's filtered by the routing system as a destination. It's pretty much >> harmless. > > I guess my issue was that the recommendation that routes for 192.88.99.1 > be filtered will be taken by some operators to also filter traffic to or > from 192.88.99.1 as well. How about an explicit recommendation against > filtering traffic to or from 192.88.99.1, then the source address issue > is orthogonal. But, if traffic sourced from 192.88.99.1 gets filtered, > then the issue is not orthogonal. > > Also, I'd like to see the recommendation expanded beyond just "Internet > service providers", how about "All networks, but in particular Internet > service providers". I'd also like to see the recommendations regarding > Return Relays to include similar wording, focusing on, but not limited > to content providers. > > So how about replacing; > > Internet service providers SHOULD filter out routes to 192.88.99.1. > > With; > > All networks, but in particular Internet service providers, SHOULD > filter routes for 192.88.99.1 or the prefix 192.88.99.0/24, yet they > SHOULD NOT filter traffic sourced from or destine to 192.88.99.1. > >>> The draft says RFC6890 should be updated to remove "the 6to4 relay >>> anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be >>> updated. RFC68980 created "Special-Purpose IP Address Registries", no >>> update to the RFC is necessary, IANA only needs to update the >>> appropriate registry, which is already requested in section 5. You may >>> want to specifically call out the appropriate registry "IPv4 >>> Special-Purpose Address Registry" in section 5, but there is no need to >>> update RFC6890. >> >> Table 10 of 6890 explicitly mentions 192.88.99.0/24, so I think it >> does need to be updated. Actually we could do it right here in the >> draft by adding "Updates: 6890" and specifying that Table 10 is >> deleted. We do need to improve the IANA Considerations wording >> on that point, too. > > From RFC 6890; > 2.2.2. IPv4 Special-Purpose Address Registry Entries > > Tables 1 though 16, below, represent entries with which IANA has > initially populated the IPv4 Special-Purpose Address Registry. > > Table 10, along with tables 1 through 16, are only the initial data to > go in the registry, the whole point of creating the registry is not to > have publish summary RFCs or even update an RFC every time something > changes. With the execution of RFC 6890 and the creation of the > registries, then the registries themselves become the authoritative > references and sources for the information, the information in the > tables of RFC 6890 are essentially Historical once the registries are > created. So, unless the intent was to modify the policy for the > registry itself I don't see the need to update RFC 6890. > > I'll leave it to you, the WG Chairs, and the AD to consult with IANA on > the best solution, but below is what I was thinking for the IANA > Considerations section. There isn't a status field for an entry in the > registry, so I thought setting the name to "deprecated" with the > original name in parenthesis seemed a reasonable solution to communicate > the intended result. Would we want to add a Termination Date? Maybe > like December 2020? > > 5. IANA Considerations > > IANA is requested to update the "IPv4 Special-Purpose Address > Registry" [IANA.IPv4] for the prefix 192.88.99.0/24 as defined in > Table 1. Redelegation of this prefix for any usage requires > justification via an IETF Standards Action [RFC5226]. > > > +----------------------+-------------------------------------+ > | Attribute | Value | > +----------------------+-------------------------------------+ > | Address Block | 192.88.99.0/24 | > | Name | Deprecated (6to4 Relay Anycast) | > | RFC | [draft-ietf-v6ops-6to4-to-historic] | > | Allocation Date | June 2001 | > | Termination Date | N/A | > | Source | True | > | Destination | True | > | Forwardable | True | > | Global | True | > | Reserved-by-Protocol | False | > +----------------------+-------------------------------------+ > > Table 1: 6to4 Relay Anycast > > > [IANA.IPv4] IANA, "IPv4 Special-Purpose Address Registry", > > . > From nobody Wed Nov 12 21:04:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8BA1A1B8D for ; Wed, 12 Nov 2014 21:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 hLrN6es8GnkC for ; Wed, 12 Nov 2014 21:03:58 -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 C603C1A1B86 for ; Wed, 12 Nov 2014 21:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1415855038; x=1417064638; h=date:from:message-id:to:subject:cc; bh=aUH7e0FEwIBgJuWFS8OXcEZFNni28yYTaBMMcRRab0U=; b=MYAhtaHIgZbaYK0VDHdTjyXIQnSvdSFUkLk+71V/rD13pCjm6n5Z4iRa uFrQF8F4yJOT+q+DI9HPwom1r8eopk40PS+Wju84votM6ne+pDTE/mod0 4KJqCKMv1DHFaFMn7jI3B4//VcqOIK4BWvL2ScIEJ/DEDWgdLNXR2M0vR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4HABY7ZFStJA2E/2dsb2JhbABcgw5UWrxbAZAJh02BHxYBAQEBAX2Edws8NIkhAQ3PMgEBAQEBBQEBAQEBARyRFB2DF4EeBYwLiwKJFZR2hB2DFwEBAQ X-IronPort-AV: E=Sophos;i="5.07,374,1413244800"; d="scan'208";a="371844485" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2014 05:03:58 +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 sAD53vCr013254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 05:03:57 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 sAD53uQU019112; Wed, 12 Nov 2014 21:03:56 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id sAD53uOD019107; Wed, 12 Nov 2014 21:03:56 -0800 Date: Wed, 12 Nov 2014 21:03:56 -0800 From: fred@cisco.com Message-Id: <201411130503.sAD53uOD019107@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vX6h5Rc9Z1wAXFPQIYqeknaeqWQ Subject: [v6ops] Preparing an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:04:01 -0000 Permit me to point out that the IETF will be meeting in Dallas on March 22-27. It is now six weeks before that date. If you have a draft that you would like to discuss, we need for you to post the -00 version in enough time that the list has a chance to comment on it, as we put things on the agenda that are new or have been updated since the past meeting, and have had supportive discussion on the mailing list. Time to start typing... Draft status as of today is: IESG: Sep 26 draft-ietf-v6ops-mobile-device-profile Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis Nov 10 draft-ietf-v6ops-6to4-to-historic Exiting WGLC; on its way to IESG: Working Group Document NOT updated since IETF: Sep 18 draft-ietf-v6ops-design-choices Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem Oct 27 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Jul 20 draft-wang-v6ops-flow-label-refelction Aug 24 draft-v6ops-pmtud-ecmp-problem Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world Sep 15 draft-anderson-v6ops-siit-dc-2xlat Sep 18 draft-elkins-v6ops-multicast-virtual-nodes Sep 18 draft-wang-v6ops-xlat-prefix-discovery Sep 25 draft-ybai-v6ops-ipv6-for-openstack Oct 5 draft-anderson-v6ops-siit-dc Oct 11 draft-liu-v6ops-running-multiple-prefixes Oct 27 draft-chen-v6ops-nfv-ipv6 Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance Oct 27 draft-osamu-v6ops-ipv4-literal-in-url Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops From nobody Wed Nov 12 21:05:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA6F1A1BA7 for ; Wed, 12 Nov 2014 21:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 156kkTIarP4V for ; Wed, 12 Nov 2014 21:05:25 -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 9EFFF1A1BD7 for ; Wed, 12 Nov 2014 21:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1415855120; x=1417064720; h=date:from:message-id:to:subject:cc; bh=ZSQV3olfxtyByM9Ef/sFvWulL2tyAvDpV4NpUSN16IE=; b=FCxmx4xUUZBOh0/DMbtzi3jR2OiUCB1H1/OPytoDyas5YlMDfztyXmnV g1Q3VKhv7IhLCdiQyEOvgiBrSDLFsNukAhlajwngd3Gx+SfMhnPm6JWn6 UevAV9ypAKw6DRpFE3FXC2xPBT/rctOFleF/SB57+jzhLcBN+VMUVLVlZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4HAF07ZFStJV2U/2dsb2JhbABcgw5UWrxbAZAJh02BHxYBAQEBAX2Edws8NIkhAQ3PMwEBAQEBBQEBAQEBARyRFB2DF4EeBYwLiwKJFZR2hB2DFwEBAQ X-IronPort-AV: E=Sophos;i="5.07,374,1413244800"; d="scan'208";a="96152480" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 13 Nov 2014 05:05:19 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAD55IBU029042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 05:05:18 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 sAD55IDD019308; Wed, 12 Nov 2014 21:05:18 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id sAD55IB3019305; Wed, 12 Nov 2014 21:05:18 -0800 Date: Wed, 12 Nov 2014 21:05:18 -0800 From: fred@cisco.com Message-Id: <201411130505.sAD55IB3019305@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yYCDgAi_6KWxVljYvolwkAjBcIY Subject: [v6ops] Preparing an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:05:29 -0000 Permit me to point out that the IETF will be meeting in Prague on July 19-24. It is now six weeks before that date. If you have a draft that you would like to discuss, we need for you to post the -00 version in enough time that the list has a chance to comment on it, as we put things on the agenda that are new or have been updated since the past meeting, and have had supportive discussion on the mailing list. Time to start typing... Draft status as of today is: IESG: Sep 26 draft-ietf-v6ops-mobile-device-profile Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis Nov 10 draft-ietf-v6ops-6to4-to-historic Exiting WGLC; on its way to IESG: Working Group Document NOT updated since IETF: Sep 18 draft-ietf-v6ops-design-choices Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem Oct 27 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Jul 20 draft-wang-v6ops-flow-label-refelction Aug 24 draft-v6ops-pmtud-ecmp-problem Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world Sep 15 draft-anderson-v6ops-siit-dc-2xlat Sep 18 draft-elkins-v6ops-multicast-virtual-nodes Sep 18 draft-wang-v6ops-xlat-prefix-discovery Sep 25 draft-ybai-v6ops-ipv6-for-openstack Oct 5 draft-anderson-v6ops-siit-dc Oct 11 draft-liu-v6ops-running-multiple-prefixes Oct 27 draft-chen-v6ops-nfv-ipv6 Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance Oct 27 draft-osamu-v6ops-ipv4-literal-in-url Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops From nobody Wed Nov 12 21:08:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACE61A1B8E for ; Wed, 12 Nov 2014 21:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 2htsM4Yt2y1B for ; Wed, 12 Nov 2014 21:08:19 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A691A1B86 for ; Wed, 12 Nov 2014 21:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2881; q=dns/txt; s=iport; t=1415855299; x=1417064899; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Qjzjdcau/hYl45FbKHgvSODLpMlImeDioOh6HBjYWGo=; b=dh+suZYWjplBH3MZttFifpZMjNL1kJvSQ2wuyaAyp1AVBo81lqu1hzor CfVPhw38AY4ap0HSH+4NFs0Ly0wvkCyO+/i28B7NDKDwdkMv+Vd4DxZiN gpaw7R8pQ8PQQ2zqOAMPgxWJcN6Xqo7ynRei1BVXZOGDKAoiOKnSUhtaK I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAEc8ZFStJA2E/2dsb2JhbABcgw5UWQTMVgyHTQKBHRYBAQEBAX2EAwEBAwEBAQFrEAsCAQhGJwslAgQTDogqCQ3PMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReRG4MtgR4FkjqCGIFSaYckgXGUdoN8bYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,374,1413244800"; d="asc'?scan'208";a="96140015" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 13 Nov 2014 05:08:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAD58INm015494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Nov 2014 05:08:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 23:08:18 -0600 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: [v6ops] Preparing an agenda Thread-Index: AQHP/v/W7E6IKRmCiE+NpzoxBahXeg== Date: Thu, 13 Nov 2014 05:08:18 +0000 Message-ID: <314EC709-3716-4DC5-BDA1-B2904624B999@cisco.com> References: <201411130505.sAD55IB3019305@irp-lnx1.cisco.com> In-Reply-To: <201411130505.sAD55IB3019305@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.88] Content-Type: multipart/signed; boundary="Apple-Mail=_B28A6604-65FF-48C4-B90E-C2F396BB10FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cGNjVVyIUBShqutw25BDaBcR1G0 Subject: Re: [v6ops] Preparing an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:08:21 -0000 --Apple-Mail=_B28A6604-65FF-48C4-B90E-C2F396BB10FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Apologies for these two messages. I=92m scheduling a message, and it = misfired. Oops, operational problem on my part. On Nov 12, 2014, at 7:05 PM, fred@cisco.com wrote: > Permit me to point out that the IETF will be meeting in Prague on = July > 19-24. It is now six weeks before that date. If you have a draft that = you > would like to discuss, we need for you to post the -00 version in = enough > time that the list has a chance to comment on it, as we put things on = the > agenda that are new or have been updated since the past meeting, and = have > had supportive discussion on the mailing list. Time to start typing... >=20 > Draft status as of today is: >=20 > IESG: >=20 > Sep 26 draft-ietf-v6ops-mobile-device-profile > Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis > Nov 10 draft-ietf-v6ops-6to4-to-historic >=20 > Exiting WGLC; on its way to IESG: >=20 > Working Group Document NOT updated since IETF: >=20 > Sep 18 draft-ietf-v6ops-design-choices > Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem > Oct 27 draft-ietf-v6ops-ula-usage-recommendations >=20 > Individual Submission NOT updated since IETF: >=20 > Jul 4 draft-sun-v6ops-xlat-multi > Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x > Jul 20 draft-wang-v6ops-flow-label-refelction > Aug 24 draft-v6ops-pmtud-ecmp-problem > Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world > Sep 15 draft-anderson-v6ops-siit-dc-2xlat > Sep 18 draft-elkins-v6ops-multicast-virtual-nodes > Sep 18 draft-wang-v6ops-xlat-prefix-discovery > Sep 25 draft-ybai-v6ops-ipv6-for-openstack > Oct 5 draft-anderson-v6ops-siit-dc > Oct 11 draft-liu-v6ops-running-multiple-prefixes > Oct 27 draft-chen-v6ops-nfv-ipv6 > Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance > Oct 27 draft-osamu-v6ops-ipv4-literal-in-url > Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie >=20 > more data at = http://datatracker.ietf.org/doc/search/?sort=3Dstatus&activedrafts=3Don&na= me=3Dv6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_B28A6604-65FF-48C4-B90E-C2F396BB10FA 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 iD8DBQFUZDy9bjEdbHIsm0MRAtQrAKCpwFiU7BfEIaPqefzFSKq3PMQCGACgqstA c6dOWiAe+pT5bNX8ShnKkdM= =aqkR -----END PGP SIGNATURE----- --Apple-Mail=_B28A6604-65FF-48C4-B90E-C2F396BB10FA-- From nobody Wed Nov 12 21:09:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067501A1B75 for ; Wed, 12 Nov 2014 21:09:54 -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 eOWlBg1az-yR for ; Wed, 12 Nov 2014 21:09:51 -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 EFA7A1A1B5E for ; Wed, 12 Nov 2014 21:09:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAD59mLd005902; Thu, 13 Nov 2014 06:09:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 085B2201558; Thu, 13 Nov 2014 06:10:08 +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 F041020148B; Thu, 13 Nov 2014 06:10:07 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.13]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAD59VYe023547; Thu, 13 Nov 2014 06:09:47 +0100 Message-ID: <54643D0B.4070208@gmail.com> Date: Thu, 13 Nov 2014 06:09:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum , "v6ops@ietf.org WG" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/m-RE-_GuyUthahjKnv9EAT15vhg Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 05:09:54 -0000 Le 12/11/2014 21:12, Iljitsch van Beijnum a écrit : > > I've been talking to a few people and I think there is potential for > a draft that lets home gateways (and any other system so inclined) > have IPv6 tunneling enabled out of the box (like 6to4) but in a way > that works pretty reliably (unlike 6to4). > > My question to (potential) implementers: > > - Is requiring HTTP digest authentication problematic? Something I can foresee as a problem is sharing the keys, or do any encrypted or authenticated exchange, with someone who is on the other side of the globe, someone non-accountable in any particular way. A matter of trust. > - Is requiring HTTPS problematic? > - Is requiring JSON parsing problematic? > * Would using plain text similar to HTTP headers to pass parameters be better? > - Is requiring DHCPv6 (the prefix delegation client role) problematic? I guess it is problematic. I am not aware of any operator of DSL or cellular links that offers DHCPv6 Prefix Delegation service (a Server that replies positively to requests for prefixes). On another hand, if we talk DHCPv6 Prefix Delegation over a tunnel (like running it over the tunnel already established by e.g. HE), then there should be no problem in using it. FWIW. Alex > > Thanks, > > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 12 23:10:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2C1A1BE1 for ; Wed, 12 Nov 2014 23:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nQ7bd4xPed8 for ; Wed, 12 Nov 2014 23:10:37 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D591A1BE9 for ; Wed, 12 Nov 2014 23:10:07 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 05954645.2ab70c833940.1725000.00-2493.4892084.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Nov 2014 07:10:08 +0000 (UTC) X-MXL-Hash: 546459507693eafd-6dbaf1c069c2aafdb25649f89fd03e1d3cf26f6e Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d4954645.0.1724986.00-2301.4892047.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Nov 2014 07:10:05 +0000 (UTC) X-MXL-Hash: 5464594d163978d3-5753cc01cea8dc792f0e67e61d840a94bf0c3856 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 sAD7A4RX013448; Thu, 13 Nov 2014 02:10:04 -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 sAD79rk9013344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Nov 2014 02:09:57 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 13 Nov 2014 07:09:38 GMT Received: from GAALPA1MSGUSRBA.ITServices.sbc.com ([169.254.1.6]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 02:09:38 -0500 From: "STARK, BARBARA H" To: Alexandru Petrescu , Iljitsch van Beijnum , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/rVUYlQxZvbsFUWUCrgjwm6mSJxeVmqA///MNEA= Date: Thu, 13 Nov 2014 07:09:37 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EB5E22@GAALPA1MSGUSRBA.ITServices.sbc.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> In-Reply-To: <54643D0B.4070208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.148.74] 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-AnalysisOut: [v=2.0 cv=NoBmhbhJ c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ArVtUgu26iUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=mYPrF8hoAAAA:8 a=wUnMHfqODD] X-AnalysisOut: [Tf_gtpCncA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lU1pMwbQV93eTX5WTL1uARP9eUY Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 07:10:41 -0000 > > - Is requiring DHCPv6 (the prefix delegation client role) problematic? >=20 > I guess it is problematic. I am not aware of any operator of DSL or cell= ular > links that offers DHCPv6 Prefix Delegation service (a Server that replies > positively to requests for prefixes). I am absolutely aware of at least one DSL operator who does this. It's definitely a part of the Broadband Forum architecture that many such o= perators helped write. http://www.broadband-forum.org/technical/download/TR-177.pdf=20 There exists no native IPv6 architecture from BBF that does not make use of= DHCPv6 IA_PD. Barbara From nobody Wed Nov 12 23:46:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAAC1A1BFB for ; Wed, 12 Nov 2014 23:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 sXYhresF2Tiv for ; Wed, 12 Nov 2014 23:45:53 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0691A1BFE for ; Wed, 12 Nov 2014 23:45:53 -0800 (PST) Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:54c1:a492:84b1:e223]) by dougbarton.us (Postfix) with ESMTPSA id 5D2C022B0D for ; Thu, 13 Nov 2014 07:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415864752; bh=+tK62g0XXzUtOF/hz4YwR8c9rTaDY+Z5EmWwARE+6UM=; h=Date:From:To:Subject:References:In-Reply-To; b=qx7JrKgdY+el747ncNA3QmRUCzztsWz+q+6pc9NsmTcQ4Vjfm9tet0ZbT8+WwKQEM XkshzI9gRWZ+Gmat3vpi+n9BhkuXCpd5ZaWjF6lpW2e6/xnAQAmHjQpI1qNpCewh7Z VEx8Lxq/8t6n0Fp4gkdwZQBs9ew88ltP7UPNN0xU= Message-ID: <546461AB.7060707@dougbarton.us> Date: Wed, 12 Nov 2014 23:45:47 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <20141112213333.GQ31092@Space.Net> In-Reply-To: <20141112213333.GQ31092@Space.Net> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fwOACSRTc-4uFmmqz9sTLwzRSG8 Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 07:46:00 -0000 On 11/12/14 1:33 PM, Gert Doering wrote: > Hi, > > On Wed, Nov 12, 2014 at 10:12:17AM -1000, Iljitsch van Beijnum wrote: >> I've been talking to a few people and I think there is potential >> for a draft that lets home gateways (and any other system so inclined) >> have IPv6 tunneling enabled out of the box (like 6to4) but in a way >> that works pretty reliably (unlike 6to4). > > I'm not sure where the value of that is. > > 10 years ago, I would have agreed that "getting IPv6 out to the people" > is a good goal - but when this draft gets to the stage that you'll see > devices actually shipping, it's 2016, and we'll have 30-40% native IPv6 > in many countries already - which should create enough momentum by it's > own... > > So, call me sceptic :) +1 We don't need this, shouldn't develop it, and definitely shouldn't deploy it. Doug From nobody Thu Nov 13 00:15:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD91A3B9E for ; Thu, 13 Nov 2014 00:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajUYiuvEorBl for ; Thu, 13 Nov 2014 00:15:51 -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 881891A1B8B for ; Thu, 13 Nov 2014 00:15:50 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6B470631B8 for ; Thu, 13 Nov 2014 09:15:49 +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 2B74B631A1 for ; Thu, 13 Nov 2014 09:15:49 +0100 (CET) Received: (qmail 7464 invoked by uid 1007); 13 Nov 2014 09:15:49 +0100 Date: Thu, 13 Nov 2014 09:15:49 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20141113081549.GR31092@Space.Net> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54643D0B.4070208@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/O9A_8LgC3LZSDj43Eq7Tu-mL99c Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 08:15:53 -0000 Hi, On Thu, Nov 13, 2014 at 06:09:31AM +0100, Alexandru Petrescu wrote: > > - Is requiring DHCPv6 (the prefix delegation client role) problematic? > > I guess it is problematic. I am not aware of any operator of DSL or > cellular links that offers DHCPv6 Prefix Delegation service (a Server > that replies positively to requests for prefixes). DHCPv6-PD is the standard method to hand out prefixes on DSL lines here in DE. ("What else could you use?"). So, now you are aware of DSL operators that do this, like "Deutsche Telekom". 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 13 00:30:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578A11A1A32 for ; Thu, 13 Nov 2014 00:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 3J4Z_tpnczdg for ; Thu, 13 Nov 2014 00:30:55 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6272E1A002B for ; Thu, 13 Nov 2014 00:30:55 -0800 (PST) Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:54c1:a492:84b1:e223]) by dougbarton.us (Postfix) with ESMTPSA id DF98822B0D for ; Thu, 13 Nov 2014 08:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415867455; bh=RH54BWLwkTHgXkKZzawKZdUDiCB6m5K5W8/HDa/lbUk=; h=Date:From:To:Subject:References:In-Reply-To; b=eX/2whxNQh/lCTORLZftJ3uDypm56zLw/6OZSnioFvs3xBizhsiwp1W01GEH8RzlB n6rss0yUD52i2Aa2G++SLBJ9fF7SNkLqeQf6N/1FukeuXWHXcxTSVVrGY/19cMNRHf Sz/JtOrKo275RzBb3VvKKO4oJiVzLO6P+NThrRvE= Message-ID: <54646C3E.5040508@dougbarton.us> Date: Thu, 13 Nov 2014 00:30:54 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <20141113081549.GR31092@Space.Net> In-Reply-To: <20141113081549.GR31092@Space.Net> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rwBE6cyGJakpkddfzLfe0AbNMmg Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 08:30:56 -0000 On 11/13/14 12:15 AM, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 06:09:31AM +0100, Alexandru Petrescu wrote: >>> - Is requiring DHCPv6 (the prefix delegation client role) problematic? >> >> I guess it is problematic. I am not aware of any operator of DSL or >> cellular links that offers DHCPv6 Prefix Delegation service (a Server >> that replies positively to requests for prefixes). > > DHCPv6-PD is the standard method to hand out prefixes on DSL lines here > in DE. ("What else could you use?"). > > So, now you are aware of DSL operators that do this, like "Deutsche Telekom". FWIW, support for this is also built into OpenWRT. Doug From nobody Thu Nov 13 00:37:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3195D1A6F5B for ; Thu, 13 Nov 2014 00:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 SqC3SWW-cZDE for ; Thu, 13 Nov 2014 00:37:19 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32FB1A1A8C for ; Thu, 13 Nov 2014 00:37:19 -0800 (PST) Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:54c1:a492:84b1:e223]) by dougbarton.us (Postfix) with ESMTPSA id 7F26122B0D for ; Thu, 13 Nov 2014 08:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415867839; bh=JZEaEM42sEbky/YlR8ZudioHgvsJNw5nZmUh55fX3WY=; h=Date:From:To:Subject:References:In-Reply-To; b=OBlQHptl8VMiwiccuNPxdDkVqvEfi73JdvcOUWsSqJtdypeMdHzZdKG4DHx8TqjCn Shmehi2iIpE+J+PxyxnsGFI//mo9W4NqRJEnjsHe8IZ7HA4j3+D2oj8rwcgHdBsjw3 zxaxIrdWjxKgCyGCLVutbssi3iAlvGSfbp5isXBY= Message-ID: <54646DBE.9060800@dougbarton.us> Date: Thu, 13 Nov 2014 00:37:18 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> In-Reply-To: <5463C716.1030805@umn.edu> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k94HHDHMI86ao3ib_E6sej1QxRw Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 08:37:21 -0000 On 11/12/14 12:46 PM, David Farmer wrote: > On my first pass I missed the current title "Deprecating Connection of > IPv6 Domains via IPv4 Clouds (6to4)", this implies more than is intended > by the current consensus. So, I'd suggest the title be changed to > reflect the new scope of the Draft, how about "Deprecating the Anycast > Prefix for 6to4 Relay Routers". Am I the only one who thinks that we should chuck the whole thing? Doug From nobody Thu Nov 13 00:40:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB191A6FA9 for ; Thu, 13 Nov 2014 00:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe70SD64MM7O for ; Thu, 13 Nov 2014 00:40:31 -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 BD9A61A6FA6 for ; Thu, 13 Nov 2014 00:40:31 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0C223631B7 for ; Thu, 13 Nov 2014 09:40: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 C9206631A7 for ; Thu, 13 Nov 2014 09:40:29 +0100 (CET) Received: (qmail 11553 invoked by uid 1007); 13 Nov 2014 09:40:29 +0100 Date: Thu, 13 Nov 2014 09:40:29 +0100 From: Gert Doering To: Doug Barton Message-ID: <20141113084029.GT31092@Space.Net> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54646DBE.9060800@dougbarton.us> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tT39HosdaU1RV8tFjIZnGerNrqY Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 08:40:33 -0000 Hi, On Thu, Nov 13, 2014 at 12:37:18AM -0800, Doug Barton wrote: > Am I the only one who thinks that we should chuck the whole thing? Seems like it. 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 13 09:07:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA361A8AF2 for ; Thu, 13 Nov 2014 09:07:04 -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 r0wlPjWHCvBP for ; Thu, 13 Nov 2014 09:06:59 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6421A8ADE for ; Thu, 13 Nov 2014 09:06:02 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so53501wiv.6 for ; Thu, 13 Nov 2014 09:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NNza5xEKJftqUyAKJHfDGf2fXXTtLWbWMZIcA4RDfwM=; b=U0Z+Ccwc8l92k2SYQRtftEa1Q1KvJ1y5bQjLqC7hZm9ulkjUJ3spM9amXSHm1VdMzR 4gI2oS5PP01Upu16jV+voBmIIBc4yGFSA9BJywJeKgvQumDkkxNqVxTV8Fn/IGbE69/r lbVnIb85gkDbMYnlltXXncHJ+e7vfzu48CxrQkL+wPNXIEE9XdQMcz+pn6HarBUh9Hra ZA885RPdSFcreNFtQ0f4d/HOXUxHFJMLNMOyV+qS8XIUEDLLTQTFb1hBIDklLrHBFOYF I+zmKfQOU55i4aAhff/qY/p7d7paNS/gQyJkyBiFaGGe35n3ujQspljAaL9+O9UkGIFs pn5g== X-Received: by 10.194.222.162 with SMTP id qn2mr5983945wjc.74.1415898361275; Thu, 13 Nov 2014 09:06:01 -0800 (PST) Received: from [31.133.151.176] (dhcp-97b0.meeting.ietf.org. [31.133.151.176]) by mx.google.com with ESMTPSA id cv7sm36269781wjc.3.2014.11.13.09.05.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 09:06:00 -0800 (PST) Message-ID: <5464E4F6.9070401@gmail.com> Date: Fri, 14 Nov 2014 06:05:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> In-Reply-To: <20141113084029.GT31092@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ef7BK0N2c2RN-7KM_Hzy8akfeoo Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 17:07:05 -0000 On 13/11/2014 21:40, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 12:37:18AM -0800, Doug Barton wrote: >> Am I the only one who thinks that we should chuck the whole thing? > > Seems like it. The message in the v6ops meeting was pretty clear and that is the reason for the diffs between -06 and -07. I understand there will be a WGLC soon so that the chairs can verify consensus on this. (The comments made so far on -07 are being held until after the WGLC.) Brian From nobody Thu Nov 13 09:39:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082BA1A8AE9 for ; Thu, 13 Nov 2014 09:39:52 -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 tsmZXdN6i72h for ; Thu, 13 Nov 2014 09:39:50 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id DD86A1A8F42 for ; Thu, 13 Nov 2014 09:39:49 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id sADHdm7a011110 for ; Thu, 13 Nov 2014 12:39:48 -0500 Received: (qmail 18426 invoked by uid 0); 13 Nov 2014 17:39:48 -0000 X-TCPREMOTEIP: 64.129.1.8 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.20.1.37?) (lee@asgard.org@64.129.1.8) by 0 with ESMTPA; 13 Nov 2014 17:39:47 -0000 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Thu, 13 Nov 2014 07:39:46 -1000 From: Lee Howard To: , Message-ID: Thread-Topic: Preparing an agenda References: <201411130505.sAD55IB3019305@irp-lnx1.cisco.com> In-Reply-To: <201411130505.sAD55IB3019305@irp-lnx1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LidjTujWpZwFlRELBVQkz2BSSNI Subject: Re: [v6ops] Preparing an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:39:52 -0000 In response to the endless agenda planning discussion at the Plenary? Lee On 11/12/14 7:05 PM, "fred@cisco.com" wrote: >Permit me to point out that the IETF will be meeting in Prague on July >19-24. It is now six weeks before that date. If you have a draft that you >would like to discuss, we need for you to post the -00 version in enough >time that the list has a chance to comment on it, as we put things on the >agenda that are new or have been updated since the past meeting, and have >had supportive discussion on the mailing list. Time to start typing... > >Draft status as of today is: > >IESG: > > Sep 26 draft-ietf-v6ops-mobile-device-profile > Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis > Nov 10 draft-ietf-v6ops-6to4-to-historic > >Exiting WGLC; on its way to IESG: > >Working Group Document NOT updated since IETF: > > Sep 18 draft-ietf-v6ops-design-choices > Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem > Oct 27 draft-ietf-v6ops-ula-usage-recommendations > >Individual Submission NOT updated since IETF: > > Jul 4 draft-sun-v6ops-xlat-multi > Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x > Jul 20 draft-wang-v6ops-flow-label-refelction > Aug 24 draft-v6ops-pmtud-ecmp-problem > Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world > Sep 15 draft-anderson-v6ops-siit-dc-2xlat > Sep 18 draft-elkins-v6ops-multicast-virtual-nodes > Sep 18 draft-wang-v6ops-xlat-prefix-discovery > Sep 25 draft-ybai-v6ops-ipv6-for-openstack > Oct 5 draft-anderson-v6ops-siit-dc > Oct 11 draft-liu-v6ops-running-multiple-prefixes > Oct 27 draft-chen-v6ops-nfv-ipv6 > Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance > Oct 27 draft-osamu-v6ops-ipv4-literal-in-url > Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie > >more data at >http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v >6ops > From nobody Thu Nov 13 09:46:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9701A8BBE for ; Thu, 13 Nov 2014 09:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 T0P27VZyRG23 for ; Thu, 13 Nov 2014 09:45:57 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F411A8AE0 for ; Thu, 13 Nov 2014 09:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2774; q=dns/txt; s=iport; t=1415900758; x=1417110358; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+f33bi6UYszyz0EwMnaOzr6GGFsFhj42AQrJrDevxoA=; b=QGCYa40f00I7yCywJ0okXOqphsNM1moD+52fDCl/OXeGq7rFpNWm2Tgx FgMvVib4vAykSsFFSnIyZmdjwbUmw5JKlmtJ4/QlYDJZlKi4Ptxm38aXK WRpspcDeun8cnRjw97Viwkufr7Aq/IV55LivU7uNA6NXs4Yakt2xisxFj s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAHztZFStJV2R/2dsb2JhbABbgw5UWQTMc4dNAoEfFgEBAQEBfYQCAQEBAwFuCwULAgEIGC4yJQIEDgUOiCoJDdB9AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5EUB4MtgR4FkjqCGIFSaYckgXGUdoN8bYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,379,1413244800"; d="asc'?scan'208";a="96340539" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 13 Nov 2014 17:45:57 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sADHjrWc026598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 17:45:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 11:45:55 -0600 From: "Fred Baker (fred)" To: Lee Howard Thread-Topic: Preparing an agenda Thread-Index: AQHP/2msaj/2xKjPc0yhxpr/kwDyjQ== Date: Thu, 13 Nov 2014 17:45:54 +0000 Message-ID: <9FC76E4F-DF47-42CA-8316-D5EC596E56F3@cisco.com> References: <201411130505.sAD55IB3019305@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-originating-ip: [10.21.91.88] Content-Type: multipart/signed; boundary="Apple-Mail=_0D5A4203-AE7A-43ED-9C5A-F1D72E212E84"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zi67pri6oi3qpLrcDS-dHFJAvRw Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Preparing an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:45:59 -0000 --Apple-Mail=_0D5A4203-AE7A-43ED-9C5A-F1D72E212E84 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 13, 2014, at 7:39 AM, Lee Howard wrote: > In response to the endless agenda planning discussion at the Plenary? Yes > Lee > > On 11/12/14 7:05 PM, "fred@cisco.com" wrote: > >> Permit me to point out that the IETF will be meeting in Prague on July >> 19-24. It is now six weeks before that date. If you have a draft that you >> would like to discuss, we need for you to post the -00 version in enough >> time that the list has a chance to comment on it, as we put things on the >> agenda that are new or have been updated since the past meeting, and have >> had supportive discussion on the mailing list. Time to start typing... >> >> Draft status as of today is: >> >> IESG: >> >> Sep 26 draft-ietf-v6ops-mobile-device-profile >> Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis >> Nov 10 draft-ietf-v6ops-6to4-to-historic >> >> Exiting WGLC; on its way to IESG: >> >> Working Group Document NOT updated since IETF: >> >> Sep 18 draft-ietf-v6ops-design-choices >> Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem >> Oct 27 draft-ietf-v6ops-ula-usage-recommendations >> >> Individual Submission NOT updated since IETF: >> >> Jul 4 draft-sun-v6ops-xlat-multi >> Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x >> Jul 20 draft-wang-v6ops-flow-label-refelction >> Aug 24 draft-v6ops-pmtud-ecmp-problem >> Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world >> Sep 15 draft-anderson-v6ops-siit-dc-2xlat >> Sep 18 draft-elkins-v6ops-multicast-virtual-nodes >> Sep 18 draft-wang-v6ops-xlat-prefix-discovery >> Sep 25 draft-ybai-v6ops-ipv6-for-openstack >> Oct 5 draft-anderson-v6ops-siit-dc >> Oct 11 draft-liu-v6ops-running-multiple-prefixes >> Oct 27 draft-chen-v6ops-nfv-ipv6 >> Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance >> Oct 27 draft-osamu-v6ops-ipv4-literal-in-url >> Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie >> >> more data at >> http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v >> 6ops >> > > --Apple-Mail=_0D5A4203-AE7A-43ED-9C5A-F1D72E212E84 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 iD8DBQFUZO5UbjEdbHIsm0MRAvgEAKDP5HivXy5srN9lpacsRSGpVKWAbACdFqpW grda3kLYS0P9BMxLafZ+QEI= =ZzQu -----END PGP SIGNATURE----- --Apple-Mail=_0D5A4203-AE7A-43ED-9C5A-F1D72E212E84-- From nobody Thu Nov 13 11:08:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD71ACDA2; Thu, 13 Nov 2014 11:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkLCsAWhbG4X; Thu, 13 Nov 2014 11:08:12 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8D21AC413; Thu, 13 Nov 2014 11:05:36 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 923C510063F2B; Thu, 13 Nov 2014 19:05:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415905532; bh=ekdOHgWzxdXqoc+GR+j7XBaeT9wEIEhqjZr2jmcrc1I=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=JOvICQsPtjr9pbCTqTodL2qkrplKKylXbOmqIarodXU1i/4B7G9tqCt0KMkAaZvzx K7KRWwlHV9lWwM+TF42YaMn/ykJYZln5VTpl0rm4Rt1tag9tT+V/M/TXnAwJQyNhLQ TEKij70AAuL0rfhHwridpbKCLMZ6FT53nkGSJ6VHHb3CPJukVjnjOQDWldw64BdKpF TBkfkwWUsclJK9eKURSwWBwpEUbo6lQtsn3jFnGP8LA+jpFkIuWujNv8OA4qRdNTKf Ah47SCamwqPG2HBM39s8dGL81UZJFa4fG+H5BlwEr5N6e4w87Fc8EtsVsTkztEjBlr pdGj+Qp75xKGg== Message-ID: <546500FA.1020104@massar.ch> Date: Thu, 13 Nov 2014 20:05:30 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <546117F0.8070800@gmail.com> <5461DC70.1090303@massar.ch> <54625975.70604@gmail.com> <546327F2.7040901@massar.ch> <5463B82F.1050704@gmail.com> <5463C306.5040306@massar.ch> <5463F477.3040701@gmail.com> In-Reply-To: <5463F477.3040701@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/31m2KYsJNlerldXh0vuImJ7ln9k Cc: IPv6 Operations , 6man Subject: [v6ops] MTU Label (Was: IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Thu, 13 Nov 2014 19:08:22 -0000 Hola, Or hmmm this week likely Aloha for most readers ;) A new -02 version of the draft is available: http://datatracker.ietf.org/doc/draft-massar-v6man-mtu-label/ More comments/arguments/etc are of course very welcome. some comments to the thread inline. On 2014-11-13 00:59, Brian E Carpenter wrote: > On 13/11/2014 09:28, Jeroen Massar wrote: >> On 2014-11-12 20:42, Brian E Carpenter wrote: > > ... >>> Also why >>> RFC 6438 "Using the IPv6 Flow Label for Equal Cost Multipath Routing and >>> Link Aggregation in Tunnels" was written (and my co-author on that was >>> a real genuine operator). >> >> (https://tools.ietf.org/html/rfc6438) >> >> As draft-v6ops-pmtud-ecmp-problem-01 shows, there is a major oversight >> called ICMP in that system. >> >> There is also no reference to ICMP or Packets Too Big in that doc. >> >> IMHO, that is a major Errata.... > > From what I learned during that discussion, an ISP doing that kind > of tunnel would simply configure MTU >>1500 and assume that nobody tries > a PMTU >1500. Any PTBs from further downstream could return on any > ECMP path, of course. The ICMPv6 PTB would not be on the internet network but come from this magic out of control part called the Internet: where the users are. Indeed in their own network the ISP can mostly solve this problem with a variety of tricks like using larger local MTUs. >> Note that it appears not many people thought/realized the >> 'pmtud-ecmp-problem', hence why that is a majorly awesome draft that >> definitely should become an RFC. >> >>> If vendors aren't implementing the most recent flow label RFCs, it's >>> presumably because operators aren't asking for it. I think they're even >>> less likely to ask for encoding MTU in the flow label to be suppported, >>> even if the IETF changed the standard yet again. >> >> Possibly because they don't see the value of such a Flow Label as >> nothing uses it. > > Well, yes, it's a chicken/egg problem of course. RFC 6437 is > a SHOULD in RFC 6434 "IPv6 Node Requirements". But these things > take years to get into products. Which is exactly why we should push this through while we still can. Unless somebody comes up with an argument why the idea is totally flawed of course. Greets, Jeroen From nobody Thu Nov 13 11:18:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9361ACD25 for ; Thu, 13 Nov 2014 11:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 4olfRQXsQTf6 for ; Thu, 13 Nov 2014 11:18:37 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28601ACD36 for ; Thu, 13 Nov 2014 11:10:20 -0800 (PST) Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id 629DD22B1C for ; Thu, 13 Nov 2014 19:10:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415905820; bh=fGBeSufEYyok+AHnXty6HW+e9DDeTigevoVzwkX4uQY=; h=Date:From:To:Subject:References:In-Reply-To; b=MvSQ2jvexRvJd507yHQgzRRtBQMTwC/fk0oaarbYNdf588yS+h6Szst97LHfTn9lM 8w80/sUTb/ZX2Wb4l+xcjc62HuaTYx0Vqveca3vpAgpZbfipifrfK145xP2zYy6/t7 nVEJBQ1lzwn9DzNp+miRnntmilBSlmVY1Fhy+gzA= Message-ID: <5465021A.2080305@dougbarton.us> Date: Thu, 13 Nov 2014 11:10:18 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> In-Reply-To: <5464E4F6.9070401@gmail.com> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZMrvbZMUOjH4sUFHk0Jet6tpXNE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 19:18:39 -0000 On 11/13/14 9:05 AM, Brian E Carpenter wrote: > On 13/11/2014 21:40, Gert Doering wrote: >> Hi, >> >> On Thu, Nov 13, 2014 at 12:37:18AM -0800, Doug Barton wrote: >>> Am I the only one who thinks that we should chuck the whole thing? >> >> Seems like it. > > The message in the v6ops meeting was pretty clear ... and yet, the select few who were in that room are not the WG, which is why I asked. :) I would hate for even a significant minority opinion to get bulldozed here because "We decided this in HI." OTOH, if the consensus of the entire WG is truly to create this new hybrid thing, I won't object too loudly. I think it's a mistake of course ... > and that is the > reason for the diffs between -06 and -07. I understand there will > be a WGLC soon so that the chairs can verify consensus on this. > > (The comments made so far on -07 are being held until after the > WGLC.) As a process step that gives an air of finality to the decision that I don't think is fair. "We decided this in HI, now we're having a WGLC, you agree, right?" Given that AFAICS the consensus was pretty strong to chuck the whole thing going into HI, it's not clear to me what changed, or why it changed, or even that the majority of the WG agrees with the new plan. Not having any of that discussion until WGLC feels like stacking the deck to me, but I'd be happy to be proven wrong on that. Doug From nobody Thu Nov 13 11:26:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38A1ACD54 for ; Thu, 13 Nov 2014 11:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Z0Xs7CS8W4 for ; Thu, 13 Nov 2014 11:25:39 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77C71ACDD4 for ; Thu, 13 Nov 2014 11:21:56 -0800 (PST) Received: from t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org (t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:f5cf:87ab:f6fb:af48] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sADJLfpo000593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 20:21:43 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <54643D0B.4070208@gmail.com> Date: Thu, 13 Nov 2014 09:21:42 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QFAX7Bf93Q4TI8C98ujisjWJZBo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:25:42 -0000 On 12 Nov 2014, at 19:09, Alexandru Petrescu = wrote: >> - Is requiring HTTP digest authentication problematic? > Something I can foresee as a problem is sharing the keys, or do any = encrypted or authenticated exchange, with someone who is on the other = side of the globe, someone non-accountable in any particular way. A = matter of trust. Yes, it would be somewhat risky to put the cloud credentials that give = access to your entire digital life inside a $50 home gateway. So it = would be good to require OAuth (RFC 6749). On the other hand, that could = be quite a barrier for implementers. However, I'd say that HTTP digest authentication is secure enough to = protect an account that is only used to set up a tunnel. >> - Is requiring DHCPv6 (the prefix delegation client role) = problematic? > I guess it is problematic. I am not aware of any operator of DSL or = cellular links that offers DHCPv6 Prefix Delegation service (a Server = that replies positively to requests for prefixes). It doesn't matter what the network operators do. If they provide native = IPv6, then the whole effort is moot. What counts is what we can = reasonably ask home gateway vendors to implement. Iljitsch= From nobody Thu Nov 13 11:34:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBA31ACC92 for ; Thu, 13 Nov 2014 11:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 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, RP_MATCHES_RCVD=-0.594, 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 LsCO18nb7UJM for ; Thu, 13 Nov 2014 11:34:19 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E13A1ACD0F for ; Thu, 13 Nov 2014 11:34:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B15B7A2; Thu, 13 Nov 2014 20:34:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1415907256; bh=A1qwZXQn1UuUa5jEWH1Tgc3LU1qNaoDMkvCln7TDnC4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zGQbzUmRPGA64rjWcEwjyQvVUvJfZYCOssXqj9I+RLmBBe1Hxyi4ONknM6sRkNqVE IU4WuxrD9OmOKiQwVj8xy5qclD1ZDHZrHxp1tuLE3Bp0RINLR8pTBzRGDO6Y7HS8c4 p9oNJtym6CUu6G6omuG8d0rdGntv0uBKH9E7UstM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AE129A1; Thu, 13 Nov 2014 20:34:16 +0100 (CET) Date: Thu, 13 Nov 2014 20:34:16 +0100 (CET) From: Mikael Abrahamsson To: Iljitsch van Beijnum In-Reply-To: <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> Message-ID: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.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: http://mailarchive.ietf.org/arch/msg/v6ops/kgY0nWXLbFTFrqLPUlg4QxSC5Lw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:34:27 -0000 On Thu, 13 Nov 2014, Iljitsch van Beijnum wrote: > It doesn't matter what the network operators do. If they provide native > IPv6, then the whole effort is moot. What counts is what we can > reasonably ask home gateway vendors to implement. I am of the opinion that we shouldn't have any more "let's create some automatic IPv6 tunneling thingie that might work". 6to4 was nice to get a way for people to try out IPv6. There are now tens of millions of households with native IPv6 connectivity in the world without much ill effects. It's now up to the operators to roll out to the rest of the mass market with proper reliability and quality, and this is happening. I would rather people had good IPv4 connectivity and no IPv6 connectivity, than them having good IPv4 connectivity, so-so IPv6 connectivity, people learning that and turning off IPv6 to fix their problem, and then when their operator rolls out proper IPv6, the end user system still has IPv6 turned off. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Nov 13 11:39:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308E61ACE1B for ; Thu, 13 Nov 2014 11:39:31 -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 YPsqaBUmzmOs for ; Thu, 13 Nov 2014 11:39:28 -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 51DAE1ACE12 for ; Thu, 13 Nov 2014 11:39:28 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id sADJd1iF082869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 19:39:21 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <546508D5.7040108@foobar.org> Date: Thu, 13 Nov 2014 19:39:01 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L68O2RGS93cW4UpGR7RSY9QLIew Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:39:31 -0000 On 13/11/2014 19:34, Mikael Abrahamsson wrote: > I would rather people had good IPv4 connectivity and no IPv6 connectivity, > than them having good IPv4 connectivity, so-so IPv6 connectivity, people > learning that and turning off IPv6 to fix their problem, and then when > their operator rolls out proper IPv6, the end user system still has IPv6 > turned off. Part of that problem is making ipv6 simple enough for CPE vendors to create products which are reliable enough to stop eyeballs from thinking that disabling ipv6 will be a net gain for them. Creating more protocol soup will not help with this aim. Nick From nobody Thu Nov 13 11:44:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA81ACE76 for ; Thu, 13 Nov 2014 11:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSOuSzmCLIII for ; Thu, 13 Nov 2014 11:44:08 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EE51ACE63 for ; Thu, 13 Nov 2014 11:43:50 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 913EC10063F24; Thu, 13 Nov 2014 19:43:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415907826; bh=zbeR+iJlpcEymlHAszXvy9xAq9HpOPoONEvO5JXODpU=; h=Date:From:To:Subject:References:In-Reply-To; b=bgqbBcpp2hBSBEiUP9kF/P1aGYLlnWdYHnaQqFwGMbhwejqV6v/ujYQJ4y8JPvds+ +t+qyomBZJPEdqILSGVA9qG7LoJ5UcPzYcGdPM69bVG8KgcDGgPLS2ZckiCqgJF89T QIwB6AbGV5lLhjMb4kFjC+41061zHuoxJs9x4u882X9opYG2U2A784+KIhbeWZAn1a TwJciOtdsh35DDSHdJp/8655B34bxYQI10eqxOF7a4Rggj2LN25uiTM3/qtZuHYjHp 1Dz0+T9kmuHG6cSIV63bfgDEGvP9EkkKH27aiEgMZRoiggqpmGx8WLvrspZfcq/e3K 0hx6qOjscxBow== Message-ID: <546509F1.5060508@massar.ch> Date: Thu, 13 Nov 2014 20:43:45 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Doug Barton , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> In-Reply-To: <5465021A.2080305@dougbarton.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vAb-is0af12zk4v2A3oFVFb6RtI Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 19:44:15 -0000 On 2014-11-13 20:10, Doug Barton wrote: [..] >> and that is the >> reason for the diffs between -06 and -07. I understand there will >> be a WGLC soon so that the chairs can verify consensus on this. >> >> (The comments made so far on -07 are being held until after the >> WGLC.) > > As a process step that gives an air of finality to the decision that I > don't think is fair. "We decided this in HI, now we're having a WGLC, > you agree, right?" Given that AFAICS the consensus was pretty strong to > chuck the whole thing going into HI, it's not clear to me what changed, > or why it changed, or even that the majority of the WG agrees with the > new plan. Not having any of that discussion until WGLC feels like > stacking the deck to me, but I'd be happy to be proven wrong on that. Checking the changes, that are between the -06 the -07 doc: http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-6to4-to-historic-06&url2=draft-ietf-v6ops-6to4-to-historic-07 This just makes the document deprecate the anycast 6to4 relay. The addition: 8<---------------------- Peer-to-peer usage of the 6to4 mechanism, not depending on the anycast mechanism, might exist in the Internet, largely unknown to operators. This is harmless to third parties and the current document is not intended to prevent such traffic continuing. ---------------------->8 That sounds sane to me. That allows 6to4 nodes to keep talking to each other directly, but it stops the burden of the issues that the anycast relays give. Getting 6to4 out of products will be horrible anyway, anything from very old Solaris's support it, that effort won't solve anything. This is also what has been discussed on the list: - deprecate anycast 6to4 - keep direct 6to4 Hence, in the form of -07, I am in favor of making it so. But, as Doug notes, if there are any changes that need to be added, it would be great to see those in the document before doing a WGLC, especially for the people not sitting in a conference room on a tropical island (I do hope the folks there got a few days before and after to enjoy that apparently amazing island!) Although from reading what Brian Carpenter says those changes are likely minor editing notes. It would be great to see the final form though. Greets, Jeroen From nobody Thu Nov 13 11:50:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4221ACEA5 for ; Thu, 13 Nov 2014 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVz2VaPEd1zQ for ; Thu, 13 Nov 2014 11:50:43 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D1E1ACEAC for ; Thu, 13 Nov 2014 11:50:42 -0800 (PST) Received: from t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org (t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:f5cf:87ab:f6fb:af48]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sADJoTD0000806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 20:50:32 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 13 Nov 2014 09:50:31 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/av0U5cmj_KajVSxPnd3_QbLHecU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:50:45 -0000 On 13 Nov 2014, at 9:34, Mikael Abrahamsson wrote: >> It doesn't matter what the network operators do. If they provide = native IPv6, then the whole effort is moot. What counts is what we can = reasonably ask home gateway vendors to implement. (For the record, many DSL operators that provide native IPv6 do support = DHCPv6-PD.) > I am of the opinion that we shouldn't have any more "let's create some = automatic IPv6 tunneling thingie that might work". 6to4 was nice to get = a way for people to try out IPv6. There are now tens of millions of = households with native IPv6 connectivity in the world without much ill = effects. It's now up to the operators to roll out to the rest of the = mass market with proper reliability and quality, and this is happening. I wouldn't declare victory quite yet. According to Google we're now = pushing 5% (native) IPv6 during the weekends, although it drops below 4% = during weekdays. But that still leaves 90+ % of all internet users on = just IPv4. Within a few years that number will very likely be much = lower, but there's still going to be significant numbers of people stuck = on IPv4 while network operators have to start using more and more = problematic mechanisms to keep IPv4 running without access to new = address space. 6to4 was all about getting the first IPv6 users connected. Within some = years, we'll be looking at getting the last IPv4-only users connected to = IPv6, which is a different challenge. > I would rather people had good IPv4 connectivity and no IPv6 = connectivity, than them having good IPv4 connectivity, so-so IPv6 = connectivity, people learning that and turning off IPv6 to fix their = problem, and then when their operator rolls out proper IPv6, the end = user system still has IPv6 turned off. But it's not a choice between those two. Obviously many people will = continue to enjoy good IPv4, and at this time and in the immediate = future you can get by quite well without IPv6. (Although I can only log = into my computer at home over IPv6 currently.) However, IPv4 is going to get worse as CGN gets rolled out and = especially as the number of users behind an IPv4 address increases. At = some point, lack of port numbers is going to become problematic for some = users. There's no reason tunnels have to be so-so. A tunnel discovery mechanism = would be helpful in finding the best tunneling option that a user can = use at a given time using a given connection to the network, and of = course if no good options are available, the system can say so and no = IPv6 tunnel is set up. By having the smarts inside a limited number of = servers rather than in millions of individual home gateways, it's easy = to react to changing circumstances.= From nobody Thu Nov 13 11:51:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9D41ACE1B for ; Thu, 13 Nov 2014 11:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ9f8kl2EsyA for ; Thu, 13 Nov 2014 11:51:05 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D311ACEB3 for ; Thu, 13 Nov 2014 11:50:57 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 0ab05645.0.2092407.00-2282.5948781.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 13 Nov 2014 19:50:57 +0000 (UTC) X-MXL-Hash: 54650ba1456a992c-d9d3d0d0ed3f3404896cecf16c898cf6bbae3890 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 sADJotR5030061; Thu, 13 Nov 2014 14:50:56 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sADJopLP029998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Nov 2014 14:50:52 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 13 Nov 2014 19:50:43 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.164]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 14:50:42 -0500 From: "STARK, BARBARA H" To: Mikael Abrahamsson , Iljitsch van Beijnum Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/rVUYlQxZvbsFUWUCrgjwm6mSJxeVmqAgADuGQCAAAODAP//rrhA Date: Thu, 13 Nov 2014 19:50:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EBC43F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.37.181] 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-AnalysisOut: [v=2.0 cv=KZplR3kD c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=3X7V6L_yObIA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=5s9j72ePawyHtVvT7wgA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dO1SkT9HiiWQdYtlQQ7k1UYSKuE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:51:07 -0000 > I am of the opinion that we shouldn't have any more "let's create some > automatic IPv6 tunneling thingie that might work". 6to4 was nice to get a= way > for people to try out IPv6. There are now tens of millions of households = with > native IPv6 connectivity in the world without much ill effects. It's now = up to > the operators to roll out to the rest of the mass market with proper reli= ability > and quality, and this is happening. >=20 > I would rather people had good IPv4 connectivity and no IPv6 connectivity= , > than them having good IPv4 connectivity, so-so IPv6 connectivity, people > learning that and turning off IPv6 to fix their problem, and then when th= eir > operator rolls out proper IPv6, the end user system still has IPv6 turned= off.=20 +1 We're only now getting to a point where many (but nowhere near all) CE rout= ers being put on retail shelves today properly support requirements for nat= ive IPv6 (RFC 7084, and IPv6 CE Router certification from IPv6 Forum). I'd = really, really love for the CE router vendors to focus on getting that numb= er up to "all CE routers on retail shelves". Anything else is an unnecessar= y and likely-to-delay-things distraction at this point, IMO. It would be ye= t another indicator that IPv6 requirements aren't finished and the vendors = should continue to wait until the requirements really, really aren't a movi= ng target. Barbara From nobody Thu Nov 13 11:53:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502101ACE12 for ; Thu, 13 Nov 2014 11:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 Xs3CZxhSF47Q for ; Thu, 13 Nov 2014 11:52:50 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E0A1ACE8B for ; Thu, 13 Nov 2014 11:52:50 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id BC46A6164; Thu, 13 Nov 2014 11:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=9Nv/HRrUS2QI98yKpanYYBYmBQ8=; b=iVnxpM08GI+iu/9Sz1 MA6zYKks4hizMY60a4c6erCc5RKllgQ+1nUFvsgRFa1UAPc2fIiUZk5ZDR8K+SWm bU3xJInI9am/DheTrhcKbt7WKpJF6OsvkzZP1nRiuKUlGj8uq8H0qS2Fh60qbNr1 3IM7XRoVryOC2feuynrMbJt24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=MPZNwnBrpTnhya2/0A9mhx6KvEEXL8Bsl65m1GowFST3nJS1k+c 4o3xxaR+TJWnLhnGfWMrJUiPS9dv71Lrm9ehbCUHDWzoOPp/wVFrUCeYN8zBMb5B aWzfnrnbI7oEQsYYWg/ukv9wyHZs2RpiCVk97mrsIJdr/RThPAyjUHfU= Received: from gomlefisk.localdomain (dhcp-a16d.meeting.ietf.org [31.133.161.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id AACEF612B; Thu, 13 Nov 2014 11:52:48 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 299223905A41; Thu, 13 Nov 2014 09:52:48 -1000 (HST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: <5465021A.2080305@dougbarton.us> Date: Thu, 13 Nov 2014 09:52:48 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P2EOEHYxZDDN4tAnNLkpaGry9Sc Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 19:52:54 -0000 >>> On Thu, Nov 13, 2014 at 12:37:18AM -0800, Doug Barton wrote: >>>> Am I the only one who thinks that we should chuck the whole thing? >>>=20 >>> Seems like it. >>=20 >> The message in the v6ops meeting was pretty clear >=20 > ... and yet, the select few who were in that room are not the WG, = which is why I asked. :) >=20 > I would hate for even a significant minority opinion to get bulldozed = here because "We decided this in HI." OTOH, if the consensus of the = entire WG is truly to create this new hybrid thing, I won't object too = loudly. I think it's a mistake of course ... >=20 >> and that is the >> reason for the diffs between -06 and -07. I understand there will >> be a WGLC soon so that the chairs can verify consensus on this. >>=20 >> (The comments made so far on -07 are being held until after the >> WGLC.) >=20 > As a process step that gives an air of finality to the decision that I = don't think is fair. "We decided this in HI, now we're having a WGLC, = you agree, right?" Given that AFAICS the consensus was pretty strong to = chuck the whole thing going into HI, it's not clear to me what changed, = or why it changed, or even that the majority of the WG agrees with the = new plan. Not having any of that discussion until WGLC feels like = stacking the deck to me, but I'd be happy to be proven wrong on that. it certainly would be interesting to hear what existing use cases there = are for peer to peer mode 6to4 (as in without relays). I also have a = hard time understanding the usefulness of keeping any of it. cheers, Ole= From nobody Thu Nov 13 11:56:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EAC1ACEF5 for ; Thu, 13 Nov 2014 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VDRFFrO3Nm8 for ; Thu, 13 Nov 2014 11:56:38 -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 8BFEF1ACE96 for ; Thu, 13 Nov 2014 11:56:37 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 69F0A631B5 for ; Thu, 13 Nov 2014 20:56:36 +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 3BB3E631AE for ; Thu, 13 Nov 2014 20:56:36 +0100 (CET) Received: (qmail 36733 invoked by uid 1007); 13 Nov 2014 20:56:36 +0100 Date: Thu, 13 Nov 2014 20:56:36 +0100 From: Gert Doering To: Iljitsch van Beijnum Message-ID: <20141113195636.GY31092@Space.Net> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.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: http://mailarchive.ietf.org/arch/msg/v6ops/7X5iF8N6IyVgx5HOrdOR_vznsh0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:56:42 -0000 Hi, On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: > There's no reason tunnels have to be so-so. I'm wondering who would provide these tunnels in the future, and what would their business model be. This is a real question. Today, you can get tunnels from Sixxs nodes (enthusiasts, which might eventually consider the IPv6 deployment issue to be "solved" and stop running tunnel nodes), HE.NET (it's good marketing, but eventually the costs involved might win over the marketing gain?), and others that run tunnels for various reasons that might not be there in 2-3 years... 6rd is a very specific tunnel technology that has answers to that question ("I want to roll out IPv6 to my customers but part of my infrastructure cannot do it. So I provision my CPEs to do 6rd, and take responsibility to run the 6rd relay") - but as with 6to4 relays, what is the incentive to run a tunnel broker in 2-3 years from now? You won't get paid (users do not pay for IPv6, otherwise they would go and choose ISPs that provide v6)... 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 13 11:59:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342EE1ACF11 for ; Thu, 13 Nov 2014 11:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPuI_Lou8CrJ for ; Thu, 13 Nov 2014 11:59:40 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043611ACF08 for ; Thu, 13 Nov 2014 11:59:40 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id p10so15046982pdj.5 for ; Thu, 13 Nov 2014 11:59:39 -0800 (PST) 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=tjHiIg9Rd7pMLWVelBebADICv0UQHjLRLyk9iyISD2Q=; b=Q/1X3nLVBkfUZKGH16OlM5a08D3IEE8OoutWqdhrv/0l/czBkr5Z72z9GW/jSiakk4 0h3O/IhGKX+p+HV7DglIdvMKCK7+rhL3nrjnrGCf06KgPKfa583pMxElZqDe1Vvd08QB ZsfBvue1j3kAq7J4HNrRFwqiY0LBigB0A2MOahMIlSJYxSgW23+/zTg2i77JN6lyr7wW zZOcUgAAVyp3M0b3zxkkiLl3fPueQGKp8utojjjpdKvldbGu9Zf8XDijzL6ebqM7415i C25cj52nkqMrqZqcrC9tf/aPxpqe4ZZCSQlo/BC7fQxvc5/0rBYgQOJJbGWN64MbaW3/ hqPw== X-Gm-Message-State: ALoCoQkkPlBXRC4erm+KOnbDNox4RDIQbwgJ7JLMkEXZ2J1UQo/eCtcG18TAu7syY3GoAUbg8Zug MIME-Version: 1.0 X-Received: by 10.66.237.145 with SMTP id vc17mr5208973pac.34.1415908779651; Thu, 13 Nov 2014 11:59:39 -0800 (PST) Received: by 10.70.34.145 with HTTP; Thu, 13 Nov 2014 11:59:39 -0800 (PST) X-Originating-IP: [31.133.172.4] In-Reply-To: <20141113195636.GY31092@Space.Net> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> Date: Thu, 13 Nov 2014 09:59:39 -1000 Message-ID: From: George Michaelson To: Gert Doering Content-Type: multipart/alternative; boundary=047d7b15a399d88b7c0507c2f39a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yuMeUa1EwbYay3bqJkUkrQau5IY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:59:44 -0000 --047d7b15a399d88b7c0507c2f39a Content-Type: text/plain; charset=UTF-8 HE.net tunnels cause severe distortion of RTT. They are anything but local termination for much of the world, and whilst I applaud their role in promoting V6 adoption, its a poor fit to the money flow of IPv4 relationships for many people. I should know: I have one in Australia, and my nearest terminations are SG/HK (which is via the US and trombones) or the US (which is 200+ms delay from me) I cannot speak to SIXX but I suspect it too distorts the packetflow and causes a disparate RTT compared to native. 6rd is homed in your own ISP. its almost 1:1 congruent with your normal RTT for native IPv6 endpoints. When we say 'tunnels are bad' its not because GRE randomly corrupts bits: its because the effects on the end-to-end model are bad. The badness varies, but the consequence of a tunnel is usually not what you wanted in reality, unless the sole consideration was connectivity per se, not its quality, compared to V4 -G On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: > > There's no reason tunnels have to be so-so. > > I'm wondering who would provide these tunnels in the future, and what would > their business model be. > > This is a real question. Today, you can get tunnels from Sixxs nodes > (enthusiasts, which might eventually consider the IPv6 deployment issue > to be "solved" and stop running tunnel nodes), HE.NET (it's good > marketing, > but eventually the costs involved might win over the marketing gain?), > and others that run tunnels for various reasons that might not be there > in 2-3 years... > > 6rd is a very specific tunnel technology that has answers to that question > ("I want to roll out IPv6 to my customers but part of my infrastructure > cannot do it. So I provision my CPEs to do 6rd, and take responsibility > to run the 6rd relay") - but as with 6to4 relays, what is the incentive to > run a tunnel broker in 2-3 years from now? You won't get paid (users do > not pay for IPv6, otherwise they would go and choose ISPs that provide > v6)... > > 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 > --047d7b15a399d88b7c0507c2f39a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HE.net tunnels cause severe distortion of RTT. They are an= ything but local termination for much of the world, and whilst I applaud th= eir role in promoting V6 adoption, its a poor fit to the money flow of IPv4= relationships for many people. I should know: I have one in Australia, and= my nearest terminations are SG/HK (which is via the US and trombones) or t= he US (which is 200+ms delay from me)

I cannot speak to = SIXX but I suspect it too distorts the packetflow and causes a disparate RT= T compared to native.

6rd is homed in your own ISP= . its almost 1:1 congruent with your normal RTT for native IPv6 endpoints.<= /div>

When we say 'tunnels are bad' its not beca= use GRE randomly corrupts bits: its because the effects on the end-to-end m= odel are bad. The badness varies, but the consequence of a tunnel is usuall= y not what you wanted in reality, unless the sole consideration was connect= ivity per se, not its quality, compared to V4

-G

On Thu,= Nov 13, 2014 at 9:56 AM, Gert Doering <gert@space.net> wrote:<= br>
Hi,

On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote:
> There's no reason tunnels have to be so-so.

I'm wondering who would provide these tunnels in the future, and= what would
their business model be.

This is a real question.=C2=A0 Today, you can get tunnels from Sixxs nodes<= br> (enthusiasts, which might eventually consider the IPv6 deployment issue
to be "solved" and stop running tunnel nodes), HE.NET (it's good marketing,
but eventually the costs involved might win over the marketing gain?),
and others that run tunnels for various reasons that might not be there
in 2-3 years...

6rd is a very specific tunnel technology that has answers to that question<= br> ("I want to roll out IPv6 to my customers but part of my infrastructur= e
cannot do it.=C2=A0 So I provision my CPEs to do 6rd, and take responsibili= ty
to run the 6rd relay") - but as with 6to4 relays, what is the incentiv= e to
run a tunnel broker in 2-3 years from now?=C2=A0 You won't get paid (us= ers do
not pay for IPv6, otherwise they would go and choose ISPs that provide
v6)...

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 Aufsichtsratsvo= rs.: 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-IdNr.: = DE813185279

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

--047d7b15a399d88b7c0507c2f39a-- From nobody Thu Nov 13 12:00:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A0F1ACF19 for ; Thu, 13 Nov 2014 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjQwd-hITgWu for ; Thu, 13 Nov 2014 12:00:00 -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 16B0E1ACF08 for ; Thu, 13 Nov 2014 12:00:00 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BB6E9631B2 for ; Thu, 13 Nov 2014 20:59:58 +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 874456094A for ; Thu, 13 Nov 2014 20:59:58 +0100 (CET) Received: (qmail 36938 invoked by uid 1007); 13 Nov 2014 20:59:58 +0100 Date: Thu, 13 Nov 2014 20:59:58 +0100 From: Gert Doering To: Ole Troan Message-ID: <20141113195958.GZ31092@Space.Net> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> 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: http://mailarchive.ietf.org/arch/msg/v6ops/KGp1n6j92Ue5tDJXF8ZDtEB6_xM Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 20:00:03 -0000 Hi, On Thu, Nov 13, 2014 at 09:52:48AM -1000, Ole Troan wrote: > it certainly would be interesting to hear what existing use cases there are for peer to peer mode 6to4 (as in without relays). I also have a hard time understanding the usefulness of keeping any of it. Well, access to hosts behind a router with one global IPv4 address and a 6to4 gateway in it comes to mind - without having to configure explicit NAT mappings on the router. I think this is Keith's scenario. (Client has working global IPv4, Router has working global IPv4, neither has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: addresses derived from Router's v4 address) 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 13 12:04:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25671ACF99 for ; Thu, 13 Nov 2014 12:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 YPsR3lsSmmdG for ; Thu, 13 Nov 2014 12:03:52 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964121ACFC3 for ; Thu, 13 Nov 2014 12:03:20 -0800 (PST) Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id 17A5F22B1C; Thu, 13 Nov 2014 20:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415909000; bh=vMzN82zaiYAyEfc2z/w6SADYLCcdtgIhKCF7ImFJ6T8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=tIJTLdc/pRFcNXAFhECUav7vnDKDeqsnM1kVdnG2nt3dKNZEQIpUe0+AGeyoZkvUz sWQTfq78Lq3XQZpa8WaWGjBwecYaL6GNCjgtQ5oaQd9rni7MQuGdt+t+WBEPZOQQUb iZ8NjD2kEG50ngZCu1dKHQjcGdmLMbMSHsmij/NE= Message-ID: <54650E87.5050407@dougbarton.us> Date: Thu, 13 Nov 2014 12:03:19 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering , Ole Troan References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <20141113195958.GZ31092@Space.Net> In-Reply-To: <20141113195958.GZ31092@Space.Net> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LHvtQ5tlfyv61aBbeVNYpv8M_H0 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 20:03:57 -0000 On 11/13/14 11:59 AM, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 09:52:48AM -1000, Ole Troan wrote: >> it certainly would be interesting to hear what existing use cases there are for peer to peer mode 6to4 (as in without relays). I also have a hard time understanding the usefulness of keeping any of it. > > Well, access to hosts behind a router with one global IPv4 address and > a 6to4 gateway in it comes to mind - without having to configure explicit > NAT mappings on the router. I think this is Keith's scenario. > > (Client has working global IPv4, Router has working global IPv4, neither > has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: > addresses derived from Router's v4 address) Isn't that the use case that ULAs are meant to cover? Or am I missing something here? I made the point earlier that (for example) OpenWRT already has support for PD, it also creates a ULA network on the LAN side, whether you have a public prefix (or tunnel) or not. So all of that is doable today, with running code. Doug From nobody Thu Nov 13 12:04:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A9F1ACF5A for ; Thu, 13 Nov 2014 12:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 9Fjb6avrtbcD for ; Thu, 13 Nov 2014 12:04:26 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58841ACFB3 for ; Thu, 13 Nov 2014 12:03:51 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so669842wiv.12 for ; Thu, 13 Nov 2014 12:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=84TproBoZM+iuVz62nNahx1GIxqRwhlcDh5GdM8pHdA=; b=v5XIAuQZZ9pBWtfrAFq52raxPFwhmPnDUwHSGPz+r9Y8Gx8EvFhsiTtAMyTUnHqVPX K25gYhhThbcCqwkOJkJnMf0S8Fq248Mz6WEcvaL9TVmfAq8et6bcrW3WGmi90Qh2vMdH /xNkxctEERohtfBKq66c75bdFA4WQ9Nlf0khgo5NfrujdWtBIdsU+nRZQD0KFupbC3rJ D2I7H8e1BB8W8hcJPAWVq71xIOFAAwQ6VL332mL2AS3eHGpItAOLy4qLGHqKF3dLLO/z MbzqPyPqqSbDTPVQnqckIP0v32igtPhJ9TOWVVJTHXn3Cuaytjl/oxbWdhC9z6UuWnyp 1z+A== X-Received: by 10.194.23.10 with SMTP id i10mr7027637wjf.11.1415909030407; Thu, 13 Nov 2014 12:03:50 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:7091:d93d:616a:50d6? (t2001067c037001607091d93d616a50d6.wireless.v6.meeting.ietf.org. [2001:67c:370:160:7091:d93d:616a:50d6]) by mx.google.com with ESMTPSA id j2sm5620785wjs.28.2014.11.13.12.03.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 12:03:49 -0800 (PST) Message-ID: <54650EA2.1030800@gmail.com> Date: Thu, 13 Nov 2014 10:03:46 -1000 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: George Michaelson , Gert Doering References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MwvPwr2WvcoXsLzvsnTDVl3DOtQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:04:28 -0000 I agree, the problem is not with the tunnels per-se, but rather with the traffic flows they help create. 6rd is a good stepping stone, homed locally performs at almost native speeds and the added delay is negligible (as perceived from a residential DSL service) regards Carlos On 11/13/14 9:59 AM, George Michaelson wrote: > HE.net tunnels cause severe distortion of RTT. They are anything but > local termination for much of the world, and whilst I applaud their role > in promoting V6 adoption, its a poor fit to the money flow of IPv4 > relationships for many people. I should know: I have one in Australia, > and my nearest terminations are SG/HK (which is via the US and > trombones) or the US (which is 200+ms delay from me) > > I cannot speak to SIXX but I suspect it too distorts the packetflow and > causes a disparate RTT compared to native. > > 6rd is homed in your own ISP. its almost 1:1 congruent with your normal > RTT for native IPv6 endpoints. > > When we say 'tunnels are bad' its not because GRE randomly corrupts > bits: its because the effects on the end-to-end model are bad. The > badness varies, but the consequence of a tunnel is usually not what you > wanted in reality, unless the sole consideration was connectivity per > se, not its quality, compared to V4 > > -G > > On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering > wrote: > > Hi, > > On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: > > There's no reason tunnels have to be so-so. > > I'm wondering who would provide these tunnels in the future, and > what would > their business model be. > > This is a real question. Today, you can get tunnels from Sixxs nodes > (enthusiasts, which might eventually consider the IPv6 deployment issue > to be "solved" and stop running tunnel nodes), HE.NET > (it's good marketing, > but eventually the costs involved might win over the marketing gain?), > and others that run tunnels for various reasons that might not be there > in 2-3 years... > > 6rd is a very specific tunnel technology that has answers to that > question > ("I want to roll out IPv6 to my customers but part of my infrastructure > cannot do it. So I provision my CPEs to do 6rd, and take responsibility > to run the 6rd relay") - but as with 6to4 relays, what is the > incentive to > run a tunnel broker in 2-3 years from now? You won't get paid (users do > not pay for IPv6, otherwise they would go and choose ISPs that provide > v6)... > > 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 Thu Nov 13 12:12:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FAA1ACEDA for ; Thu, 13 Nov 2014 12:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: 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_zWqXbWENbY for ; Thu, 13 Nov 2014 12:12:04 -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 C0B491ACEB7 for ; Thu, 13 Nov 2014 12:12: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 33FD6631B2 for ; Thu, 13 Nov 2014 21:12: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 08EFE631AF for ; Thu, 13 Nov 2014 21:12:01 +0100 (CET) Received: (qmail 39348 invoked by uid 1007); 13 Nov 2014 21:12:01 +0100 Date: Thu, 13 Nov 2014 21:12:01 +0100 From: Gert Doering To: Doug Barton Message-ID: <20141113201201.GB31092@Space.Net> References: <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <20141113195958.GZ31092@Space.Net> <54650E87.5050407@dougbarton.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yejLM8tSvcioqZN0" Content-Disposition: inline In-Reply-To: <54650E87.5050407@dougbarton.us> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4bqR9CKW7Q8I8lq1F30IVfR3k54 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 20:12:11 -0000 --yejLM8tSvcioqZN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 13, 2014 at 12:03:19PM -0800, Doug Barton wrote: > > (Client has working global IPv4, Router has working global IPv4, neither > > has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: > > addresses derived from Router's v4 address) >=20 > Isn't that the use case that ULAs are meant to cover? Or am I missing=20 > something here? So how exactly do ULAs help connect to your home network from abroad, when all you have is IPv4 at the client? "client" is obviously *outside* "home network" > I made the point earlier that (for example) OpenWRT already has support= =20 > for PD, it also creates a ULA network on the LAN side, whether you have= =20 > a public prefix (or tunnel) or not. So all of that is doable today, with= =20 > running code. That wasn't the question. Ole was asking "what are use cases for=20 peer-to-peer 6to4" (RFC 3056 without 3068). 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 --yejLM8tSvcioqZN0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVGUQkd9WwGXkzn/FAQKH9hAArlBP4yCoTKZCTOXIPSZ2KS/mYh+ur8be tGof0kqsIngmICruk+yWndaQ86hE3C0NqXMhL+AKIttPZDnyENPkUwdscBRZyx2C vHTJsJAQjztnXWXVsU+u+7GZKH+4p8HnKNCUIYLEZGXWF7gZ9JtQjX9OMvBq2xAo r+LNcIvjzh5iRzeGbDVA2c0iZ75UspacT4iLyrAy1OU0bUu4M81btqmpb9Oke5k+ SiZKvg1W0jkroVlZHISjYtBTLBFizxyFdYfw9ztpfHQkay4kyoeiJqSAcElvMBvE 6TpJBXUYFW7yFCsSnnItYVWoXUzG5PGnWoWq71HdHkRQ8SFc47qWp/g4Xmc/GSxF JGQ4R2IgNKRJ9WWt9P6gocgRrtwpCeIXXgKG6p5K5a0LC4bvfAQY2wIxL9uWb4OC XlRQgmtlpL55SViwEtAKbmRuWepDZa5LMJIIT1WwIBq3uK2hGfvyD6YLfIv+ihhW Fyxhly2de8Sx2nE4InR0Esy+XoGSXrSKik4d2OTVwIfMLN4ZE9mARmQJxXdv/s/z 2xeeCGcYdmSu7nzTJaBXOhoX9gXp6i6bqKW5rDML5+2KKcdioNJwYsJQ6uYirw1D xG/AylXt+hbD1u7sYMpjjbcRXwkl7fbbZvt4RV3zYDvdAltkGXGFuC9YllkCc8VP AoOCe7nC6rk= =FaW6 -----END PGP SIGNATURE----- --yejLM8tSvcioqZN0-- From nobody Thu Nov 13 12:25:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001C41AD03A for ; Thu, 13 Nov 2014 12:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 tDEPu8sIrCUf for ; Thu, 13 Nov 2014 12:24:56 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867EB1AD00D for ; Thu, 13 Nov 2014 12:24:56 -0800 (PST) Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id 4F94922B1C; Thu, 13 Nov 2014 20:24:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415910296; bh=/ULF2BZ69bCaEcIM4cl+ApnNViB/MhrlKaUb8nDXA10=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=JmQlae6E2esfRWckXe1LBHK0yME/HmWuaCkbkTnHLs3Vyef6kwer64GVjmokzz99n zjH3IBnHEqCc08RzapGo78Mb9BkYlgRxWzspm40Q6phrpNos8OdinGPezu/u3Vql2M skTwm+Ee49hYkax9GQbUi0WmoMG37sbFCQQ+Lvs4= Message-ID: <54651396.4020103@dougbarton.us> Date: Thu, 13 Nov 2014 12:24:54 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering References: <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <20141113195958.GZ31092@Space.Net> <54650E87.5050407@dougbarton.us> <20141113201201.GB31092@Space.Net> In-Reply-To: <20141113201201.GB31092@Space.Net> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DQ72540L3X3-8_Voe39lwnJ8eRo Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 20:25:02 -0000 On 11/13/14 12:12 PM, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 12:03:19PM -0800, Doug Barton wrote: >>> (Client has working global IPv4, Router has working global IPv4, neither >>> has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: >>> addresses derived from Router's v4 address) >> >> Isn't that the use case that ULAs are meant to cover? Or am I missing >> something here? > > So how exactly do ULAs help connect to your home network from abroad, > when all you have is IPv4 at the client? > > "client" is obviously *outside* "home network" Ok, then I misunderstood your point, thanks for clarifying. >> I made the point earlier that (for example) OpenWRT already has support >> for PD, it also creates a ULA network on the LAN side, whether you have >> a public prefix (or tunnel) or not. So all of that is doable today, with >> running code. > > That wasn't the question. Ole was asking "what are use cases for > peer-to-peer 6to4" (RFC 3056 without 3068). Yeah, I have the same question. :) If users are stuck on an IPv4-only ISP, and want IPv6, they have proven alternatives already. IMO it's going to be very hard to send a clear message to implementers and operators, "Deprecate *this* kind of 6to4, but *not* this other kind." Doug From nobody Thu Nov 13 12:44:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9B1AD3A0 for ; Thu, 13 Nov 2014 12:44:17 -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 he_jmGw-YRgX for ; Thu, 13 Nov 2014 12:44:16 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F701AD3A5 for ; Thu, 13 Nov 2014 12:44:10 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so17767692wgh.34 for ; Thu, 13 Nov 2014 12:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mA+Ry5ZhobZCGansaVCKSwQzyIKuWEfxR1g+U3LgYSw=; b=U5PLFhZFQ3/l8eoPBh28b121TCL33RBQrl9ZM7f7P8DHsGmz6t3n8toZnGLexOeYtS g1cDd1SqxU5/tzx3bJ8y3w9LK9JwNtCFlC9kwCPvW20tuemnxtR39GmbfZPE0x/dNhgC omX1MKDumHP8235VNLDnJfEMjk/r8jEjmsH9u2KLWy95CenPnE2Lgb/E01kCqde6vYR2 535qPIoeXFjTAykad8vQWxbWbUzG5NPq/115cdtnvp69Eqi9mkv9YQlf4/kn7Hre70vL CHjahw8wrbdekdOjFfrTZ4nRMeMCzxWrfCNAP9XlKVdtv8z8oQBMm3ok14jnF3fi9JWm zdSg== X-Received: by 10.194.184.12 with SMTP id eq12mr7722259wjc.100.1415911449077; Thu, 13 Nov 2014 12:44:09 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id fm10sm6402008wjc.43.2014.11.13.12.44.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 12:44:08 -0800 (PST) Message-ID: <54651820.4090008@gmail.com> Date: Fri, 14 Nov 2014 09:44:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Barton References: <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <20141113195958.GZ31092@Space.Net> <54650E87.5050407@dougbarton.us> <20141113201201.GB31092@Space.Net> <54651396.4020103@dougbarton.us> In-Reply-To: <54651396.4020103@dougbarton.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mqYDGGvJ6ynfRgEtVRCrOaVYYtk Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 20:44:18 -0000 On 14/11/2014 09:24, Doug Barton wrote: > On 11/13/14 12:12 PM, Gert Doering wrote: >> Hi, >> >> On Thu, Nov 13, 2014 at 12:03:19PM -0800, Doug Barton wrote: >>>> (Client has working global IPv4, Router has working global IPv4, >>>> neither >>>> has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: >>>> addresses derived from Router's v4 address) >>> >>> Isn't that the use case that ULAs are meant to cover? Or am I missing >>> something here? >> >> So how exactly do ULAs help connect to your home network from abroad, >> when all you have is IPv4 at the client? >> >> "client" is obviously *outside* "home network" > > Ok, then I misunderstood your point, thanks for clarifying. > >>> I made the point earlier that (for example) OpenWRT already has support >>> for PD, it also creates a ULA network on the LAN side, whether you have >>> a public prefix (or tunnel) or not. So all of that is doable today, with >>> running code. >> >> That wasn't the question. Ole was asking "what are use cases for >> peer-to-peer 6to4" (RFC 3056 without 3068). > > Yeah, I have the same question. :) If users are stuck on an IPv4-only > ISP, and want IPv6, they have proven alternatives already. IMO it's > going to be very hard to send a clear message to implementers and > operators, "Deprecate *this* kind of 6to4, but *not* this other kind." Well, yes, it is hard to be clear, because of all the complexities. Some of them were discussed at length in RFC 3056 and others in RFC 6343. However, I maintain that the *current* draft is not particularly complex in what it recommends. I don't understand what you meant by "create this new hybrid thing". IMHO the draft *removes* the hybrid thing created by RFC 3068, apart from a few operational dregs, and leaves the thing created by RFC 3056 untouched. To your other earlier comment, a WGLC is not generally an up/down choice. The authors will do what the WG wants, and a WGLC is a way to find out what that is. Brian From nobody Thu Nov 13 12:56:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECA41AD46F for ; Thu, 13 Nov 2014 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYYMdw2gM-Aw for ; Thu, 13 Nov 2014 12:56:16 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44811AD46D for ; Thu, 13 Nov 2014 12:55:39 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id CEE7710063F4C; Thu, 13 Nov 2014 20:55:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415912136; bh=g6AZCCb3EkmzGGVPsq7BTjBInUGx9z/kNkD9tbJxRBI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=0rSfNZqLT2uV1AVa8TWPGZQurOq8QDKnFrgCQ24uThbT33/gp+PPLek3NGfj6XH5z JIRLxKXguqnMjZKPF7xjkjLnWwy+2DeLzh+F9toWU0MZR0nwaFY0A8SiUciPwby5DT NfROt2ppJVF2sOCZafJz+2Smad1XldU12Nu+1VLYeAmDn+BYfGJ0KRcdT5BT9RyfpC 8EYV/kBuLYwXcklBTnxrtEj2WFI+bpIvoI7oyh0MwULx838tis8PvBc8cBjsZG+/st 26fIN90lQgpoo0Wbcn3kVdevO4Af37Tujw98kQeGfk0q/mMhFpQexq0scJgcGeM/VY dt/pdvnbEDziQ== Message-ID: <54651AC6.5080704@massar.ch> Date: Thu, 13 Nov 2014 21:55:34 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: George Michaelson References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jTYyhN8pi8pLoVoY54qI-rUny0E Cc: "v6ops@ietf.org WG" Subject: [v6ops] "Severe distortion in RTT" (Was: Bar BoF on a 6to4 replacement?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 20:56:19 -0000 On 2014-11-13 20:59, George Michaelson wrote: > HE.net tunnels cause severe distortion of RTT. They are anything but > local termination for much of the world, and whilst I applaud their role > in promoting V6 adoption, its a poor fit to the money flow of IPv4 > relationships for many people. I should know: I have one in Australia, > and my nearest terminations are SG/HK (which is via the US and > trombones) or the US (which is 200+ms delay from me) > > I cannot speak to SIXX but I suspect it too distorts the packetflow and > causes a disparate RTT compared to native. Hence why having a large variety of PoPs in disjunct networks is important and then terminating the tunnel as close as possible to the point of origin keeping network paths short and latency low. Note that OCCAID provides 2 PoPs in Australia through SixXS: https://www.sixxs.net/pops/occaid/ And AARNet still apparently runs a GogoServer based broker there too. I wonder what you exactly mean with "severe distortion in RTT" (hence the subject change) any more details? > 6rd is homed in your own ISP. its almost 1:1 congruent with your normal > RTT for native IPv6 endpoints. 6rd are just proto-41 tunnels that are locally terminated. XS4all.nl still runs a tunnel broker that is based on the IPng.nl scripts that Pim van Pelt wrote back then (and likely majorily overhauled and likely ported to some Juniper or so by now. Their tunnels where thus also 'local' to the ISP and had the same properties. Unfortunately not every ISP has the expertise or the willingness to set up a system like that. We made the SixXS model therefor "white label" on request by a lot of folks in the RIPE community back then. That way, they just connected the box and got a local PoP that matches these properties. > When we say 'tunnels are bad' its not because GRE randomly corrupts > bits: its because the effects on the end-to-end model are bad. The > badness varies, but the consequence of a tunnel is usually not what you > wanted in reality, unless the sole consideration was connectivity per > se, not its quality, compared to V4 Over the 15+ years that I have been using IPv6 tunnels I rarely had big issues with them, but this because there are a lot of well connected PoPs in the area. Latency increase over IPv4 is minimal most of the time too. The only major problem that pops up once in a while is broken PMTUD at some site or another. Typically a misconfig or a broken device (as currently is happening). Work on that is underway... Greets, Jeroen From nobody Thu Nov 13 13:04:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0481C1AD52E for ; Thu, 13 Nov 2014 13:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 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, RP_MATCHES_RCVD=-0.594, 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 Z_Lyrm97Q7oY for ; Thu, 13 Nov 2014 13:03:56 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74BA1AD525 for ; Thu, 13 Nov 2014 13:03:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 13699A2; Thu, 13 Nov 2014 22:03:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1415912631; bh=ee7Rwsq6IZ9nqcWH0dD0nKvwMWgU1Yx3PxgDCC2G1TA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FbtzAgSXx4LP4w+nBqVWpxqNuYIug1P0mKgdMb8q+pIDCisYb2x4sEPVW/hag26zi 6NcwXthvMEhuklL+QncGuwZlqTPSmkYc3tdF/7sM97/jbHDiU4URGB6JcehWnOc893 qdLY61Rl2RGDC5+kCsQcv3rRJybw/hw3HnTXwQ/U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A0ADA1; Thu, 13 Nov 2014 22:03:51 +0100 (CET) Date: Thu, 13 Nov 2014 22:03:51 +0100 (CET) From: Mikael Abrahamsson To: Iljitsch van Beijnum In-Reply-To: Message-ID: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.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: http://mailarchive.ietf.org/arch/msg/v6ops/cXU3MxjzPtJ5YcS1KNbWfk6jEHw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:04:02 -0000 On Thu, 13 Nov 2014, Iljitsch van Beijnum wrote: > There's no reason tunnels have to be so-so. Sure, and there is no reason 6to4 wouldn't work either. Now, history has proven that it doesn't work very well in reality and I'd rather learn from history instead of trying again something we know didn't work very well and there is little reason to believe that something new we come up with along similar lines would work a lot better. I have a HE tunnel home until my ISP gets me native IPv6. I tried managed IPv6 tunnels in the 2000:s until we could get native IPv6. Native IPv6 is superior to any of this, and I venture to say that even HE tunnel, being run by professionals, work even close to as well as native IPv6. Tunnels are an increased complexity and they introduce more mechanisms that can break, often in hard to diagnose ways. Let's not throw brain cycles on this that could be spent better on deploying native IPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Nov 13 13:19:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF6D1ACD3A for ; Thu, 13 Nov 2014 13:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9wLTD3jjI_z for ; Thu, 13 Nov 2014 13:18:48 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0E51AD1BA for ; Thu, 13 Nov 2014 13:16:10 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so2459971pab.21 for ; Thu, 13 Nov 2014 13:16:10 -0800 (PST) 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=9/jcQUOkloyq7P+pnZ4z1Sb46WHiHA3pt4b/59fOaBI=; b=hnjQBQ1AVly1NFhJLr+b+TEl1hLuUb8r4ulQyuCkmWg+L+2d/y7iSFk+GqWN6/lO3s kfe3v0TECl11GU+j+1D6Wi8Iuopx3XbwMb75NPTwkk4L53j1Lqvqwde/fd+dVYLixxmp HBTqE+AAFWUYQ6OqjU63TQ6ikiVVNmEh5xwQIjAes3Sh6ILjWWLQWjLk1SVzVNUJTzTJ SKJb84SAWaU/2yxae5D4HCkquG3gtRHcY565h1VuDDycAmxDZA5WTCrHuPGI/b1Ksl5q Yv9C2nqbB4bH4a0eRZnpS/RzYjyBWoIr/Zgue7XexVEM3YEVjw1RnsmZ6Tmt7YdNXGL1 Hxwg== X-Gm-Message-State: ALoCoQm+TmSSHP3B73YpknFUaz3TPTVknEsMvV6M3okC1CXomBnfzLCfIPau8tWRnwA8B8JN6+Jo MIME-Version: 1.0 X-Received: by 10.66.246.196 with SMTP id xy4mr5560273pac.29.1415913370368; Thu, 13 Nov 2014 13:16:10 -0800 (PST) Received: by 10.70.34.145 with HTTP; Thu, 13 Nov 2014 13:16:10 -0800 (PST) X-Originating-IP: [2001:67c:370:168:35a1:330c:1c21:dd99] In-Reply-To: <54651AC6.5080704@massar.ch> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54651AC6.5080704@massar.ch> Date: Thu, 13 Nov 2014 11:16:10 -1000 Message-ID: From: George Michaelson To: Jeroen Massar Content-Type: multipart/alternative; boundary=047d7b15ad717954ac0507c405d0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Kd6_CX1Cmu6NnO5rsBj9Xbffdnw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] "Severe distortion in RTT" (Was: Bar BoF on a 6to4 replacement?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:18:52 -0000 --047d7b15ad717954ac0507c405d0 Content-Type: text/plain; charset=UTF-8 Sure. ping6 algebras.org and ping algebras.org. I just did this from Dallas, and the effective difference in RTT was 50ms, and about 1/3 of the RTT extra compared to V4. 33% is a heavy penalty. I did the same from Hetzner in Germany, the effect was reversed. Why? because HE peers directly with the transit behind my Hetzner node, so its a good path embedded in HE. So the initial look from one asset I have is "wow: v6 is great" but from another asset outside that family.. its 100% inverse. Thats what I mean by RTT distortions. The effect of the tunnel is highly variable RTT depending on where you are, compared to V4. the 6 is an HE tunnel, whose endpoint is the US west coast. Had I chosen their SG or HK presentation, I'd be even worse because of the trombone of the path from AU to SG being via the USA. I entirely understand your retort will be "so use gogo" or "so use sixx in AU via AARNET" but thats the thing: the reason I took HE is because when I searched google for IPv6 tunnel FreeBSD (I can't remember the exact search) the top hit was HE and it was simple to configure. shooting yourself in the foot is very easy with hand-install tunnels. --047d7b15ad717954ac0507c405d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure. ping6 algebras.= org and ping algebras.org. I just d= id this from Dallas, and the effective difference in RTT was 50ms, and abou= t 1/3 of the RTT extra compared to V4. 33% is a heavy penalty.
I did the same from Hetzner in Germany, the effect was reverse= d. Why? because HE peers directly with the transit behind my Hetzner node, = so its a good path embedded in HE. So the initial look from one asset I hav= e is "wow: v6 is great" but from another asset outside that famil= y.. its 100% inverse.

Thats what I mean by RTT distortions. T= he effect of the tunnel is highly variable RTT depending on where you are, = compared to V4.

the 6 is an HE tunnel, whose endpo= int is the US west coast. Had I chosen their SG or HK presentation, I'd= be even worse because of the trombone of the path from AU to SG being via = the USA.

I entirely understand your retort will be= "so use gogo" or "so use sixx in AU via AARNET" but th= ats the thing: the reason I took HE is because when I searched google for I= Pv6 tunnel FreeBSD (I can't remember the exact search) the top hit was = HE and it was simple to configure.

shooting yo= urself in the foot is very easy with hand-install tunnels.=C2=A0
--047d7b15ad717954ac0507c405d0-- From nobody Thu Nov 13 13:20:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4491AD542 for ; Thu, 13 Nov 2014 13:20:50 -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 S8zui42URH-N for ; Thu, 13 Nov 2014 13:20:45 -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 B71301AD54C for ; Thu, 13 Nov 2014 13:20:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADLK5wo031293; Thu, 13 Nov 2014 22:20:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8FA702047E4; Thu, 13 Nov 2014 22:20: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 81B9320465A; Thu, 13 Nov 2014 22:20:25 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.166]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADLJcRH020685; Thu, 13 Nov 2014 22:20:03 +0100 Message-ID: <54652069.30805@gmail.com> Date: Thu, 13 Nov 2014 22:19:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , Doug Barton , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> In-Reply-To: <546509F1.5060508@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zr0oiUtFj773eF9Qe986tKzv-wQ Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:20:50 -0000 Le 13/11/2014 20:43, Jeroen Massar a écrit : [...] > This is also what has been discussed on the list: > - deprecate anycast 6to4 > - keep direct 6to4 YEs, I agree, and I would like to re-mention the point about software bugs. There is one particular 6to4 implementation in the wild which has two different means to put up a 6to4 tunnel. One is to just say '6to4' in the cli, the other is to be specific and type that IPv4 anycast address. With the first means - it does not work. Worse, it gets into a mode where packets are output destined to random IPv4 addresses. Fix the bug. What does this mean with respect to the deprecation effort? Do not deprecate the IPv4 anycast address because if so then the entire 6to4 software on that platform will no longer work. Do not deprecate until you offer a solution satisfying a number of requirements (currently unsatisfied by eg tunnel brokers). That's my oppinion. Alex > > > Hence, in the form of -07, I am in favor of making it so. > > > But, as Doug notes, if there are any changes that need to be added, it > would be great to see those in the document before doing a WGLC, > especially for the people not sitting in a conference room on a tropical > island (I do hope the folks there got a few days before and after to > enjoy that apparently amazing island!) > > Although from reading what Brian Carpenter says those changes are likely > minor editing notes. It would be great to see the final form though. > > Greets, > Jeroen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 13 13:24:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60341AD5D0 for ; Thu, 13 Nov 2014 13:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeoCLCsqNYhe for ; Thu, 13 Nov 2014 13:23:40 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5824A1AD5AB for ; Thu, 13 Nov 2014 13:23:39 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id sADLNRVr020678 for ; Thu, 13 Nov 2014 16:23:27 -0500 Received: (qmail 5935 invoked by uid 0); 13 Nov 2014 21:23:27 -0000 X-TCPREMOTEIP: 31.133.167.98 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.167.98?) (lee@asgard.org@31.133.167.98) by 0 with ESMTPA; 13 Nov 2014 21:23:26 -0000 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Thu, 13 Nov 2014 11:23:25 -1000 From: Lee Howard To: "'IPv6 Operations'" Message-ID: Thread-Topic: draft IETF91-v6ops minutes Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3498722607_12781117" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W1fkUK4O3m9rYSwteILRvUnu-A8 Subject: [v6ops] draft IETF91-v6ops minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:23:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3498722607_12781117 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Below, my notes from this week's meetings. I'd like some review before I post them as meeting minutes. Lee IPv6 Operations =AD IETF91 Monday, 10 November 2014 =20 Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) Brian Carpenter=20 Proposed as BCP, 6to4 NOT RECOMMENDED in product support, MUST disable by default, SHOULD consider dropping 6to4 relay servers, p2p 6to4 (not depending on anycast) might still be okay Dave Thaler: If we deprecate 6to4, Teredo is next in line in preference table. Opposite of what we want. Thus, do not deprecate rfc3056 (p2p mode= ) without also deprecating Teredo. But Xbox uses Teredo for p2p, so can=B9t deprecate it yet. Lorenzo Collitti: We must show harm to deprecate p2p mode (3056). We can=B9t show harm, so we shouldn=B9t deprecate. Cameron: I null route 6to4 prefixes, especially 192.88.99.0/24 so it doesn=B9= t create half-open CGN state. Maybe need a sunset4 draft saying weird IPv4 brokenness like this will pop up. Michael Richardson: deprecate rfc3068 only, too much risk in deprecating p2= p James Woodyatt: agree. Also agree that content providers should (instead of may) keep return relays running. Maybe also NAT64 ops should do. Yourtchenko: Yes, filter 192.88.99.0/24 Abramsson: Don=B9t spend brain cycles on new relays Hums: Should we deprecate 3068? YES: Strong hum. Should we deprecate 3056? YES: Hum, NO: slightly stronger hum Should we recommend filtering 192.88.99.0/24? YES: Weak hum. NO: Very wea= k hum=20 Should we recommend filtering 2002::/16? YES: One hum Outcome: Revise draft accordingly, then WGLC =20 SIIT-DC Tore Anderson, remote Needs a better name than =B3SIIT-DC=B2 Needs co-authors Yourtchenko: Could also do CLAT function as bump in the API Cameron would use this, may review but couldn=B9t co-author Thaler: This isn=B9t a new protocol, just good use cases. Prefer the name =B3Stateless NAT64=B2. Clarify rationale for static mapping. Still need a better name. Adopt both SIIT drafts as WG? YES: Strong hum Call it stateless NAT64? Weak hum SIIT-DC? Quiet Other? Quiet Outcome: repost as draft-ietf-v6ops-siit-dc and draft-ietf-v6ops-siit-dc-2xlat. Cameron Byrne to review DHCPV6/SLAAC Interaction Bing Liu Bernie Volz: DHC WG is working on 3315-bis. (Revising dhcpv6) Lorenzo Collitti: There is no problem, just different implementations. The problem statement draft can just document what implementations do. Documen= t undocumented-unspecified behaviors. Don=B9t call it a problem statement; add more testing and give it to operators documenting these corner cases. Don=B9= t think we should adopt =ADGuidance, until/unless we see real operational problems. Fred: So should the Guidance draft go to DHC to inform their update? Brian Carpenter: Disagree with everything Lorenzo said. 6renum noted that changing mechanisms really breaks stuff. Stall on =ADGuidance doc. DHC should look at it, to make sure they don=B9t make anything worse, need 6man t= o fix what exists now. Yourtchenko: For some of the inconsistent behaviors, we don=B9t know what the =B3right=B2 behavior is. Lorenzo Collitti: If we do what Brian says, 6man will say, =B3We deprecated M and O.=B2 Ole Troan: If someone proposed a solution, we would listen to it. Barbara Stark: The ambiguity exists; document the ambiguous behavior. If yo= u want to make it less ambiguous, go to 6man. Suresh Ramasubramanian: See rfc4861 and rfc4862 Summary: DHCPv6/SLAAC problem statement: Focus on behaviors in real implementations (and maybe rename it). Outcome: Adopt =ADGuidance as WG doc? YES: Silence, NO: weak hum =20 =20 Considerations For Using Unique Local Addresses Bing Liu Brian Carpenter: Is this consistent with what Homenet is saying? Bing: Yes, currently compatible =20 =20 Considerations for Running Multiple IPv6 Prefixes Sheng Jiang Erik Kline: Strike all text about IPv6 NAT Mikael Abrahamsson: work in progress at MIF, but not sure we need to say it Lorenzo Collitti: Security isn=B9t unique to multiple prefixes. Specifically, let=B9s not put a lot of text saying =B3multiple prefixes will exhaust ND cache,=B2 when hosts give multiple addresses anyway. Take the text out, and put it in a new document. Maybe not call attention to LLA as multiple prefixes. But if you take that out, you=B9re only left with stuff MIF is still doing, and ULA. Brian: Targeted at enterprises, so it=B9s different and useful. Summary: wait =20 =20 Introducing IPv6 vulnerability test program in Japan Ruri Hiromi=20 Vyncke: all in Japanese? Yes. DOS to router or host? Outcome: not a WG document =20 =20 Discovery of the IPv6 Prefix in 464XLAT No presentation =20 IPv6 Extension Headers in the Real World Fernando Gont Packets with EH are often dropped. 20% drop rate for fragments 10% drops for Destination Options 40% drops for Hop-by-Hop options 25% for fragmented traffic 20-60% of drops occur at an AS other than Destination AS Thus, if you design stuff relying on EH that uses the Internet, you need a fallback mechanism Several comments about how terrible it is that people are dropping packets with EH. In a network that filters EH, there=B9s a vulnerability: an attacker could send Packet Too Big, resulting in atomic fragments, which require EHs, so traffic gets dropped. Dave Thaler: dropping IPv6 EHs =B3for security reasons=B2 (to avoid DOS attacks= ) simply creates an alternate vulnerability (for DOS attacks) Tony Hain offers to host measurement tools, too Draft authors Jen Linkova used Atlas probes, Fernando used his own tools Eric Vyncke: can we identify the problem ASNs? Would also test on his p2p network Mike Ackerman: what can we do about it? Nalini Elkins: Is it that 90% on one network and 1% on another network are getting dropped which totals out to the percentages above? Joel Jaeggli: I have to find the L4 header, so I make edge decisions about what to drop, but they only affect me Merike Kaeo: need data on mobility and IPSec Would you like to see a data development study as a WG item? YES: hum, NO: slightly weaker hum Do we want a draft that would work through recommendation on how to configure? YES: Very weak hum, NO: even weaker Outcome: Split the document into problem measurements and recommendations =20 =20 Design Choices for IPv6 Networks Victor Kuarsingh presenting =E0 This needs usefulness review on NOG Dave Thaler: Right now, content doesn=B9t match scope of title and abstract. It=B9s okay to identify =B3future work=B2 or other documents. ULA, DHCPv6 vs SLAAC; at least say, =B3Here are some design choices discussed in other documents.=B2 Security Considerations section is TBD, do not go to WGLC SeND, SAVI, etc. etc. Jen Linkova: Say ISIS multi-topology. Saying LLA doesn=B9t go beyond link turns out to be untrue. Eric Vyncke: Go to WGLC quick, before scope increases. Tighten title and abstract and go. Don=B9t forget to mention EH. To do: Change title and abstract Add ULA, DHCPv6 vs SLAAC references Add Security considerations Outcome: Make those revisions, then solicit review (maybe via WGLC) =20 A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments=20 Hiroaki Hazeyama=20 Dan Wing: Yes, there are still problems with IPv4 literals Andrew Sullivan: I think NAT64/DNS64 is a kludge, and we=B9ve always known this was going to break. Strongly opposed to creating a special purpose TLD= . If you must, use v4only.arpa Joel Jaeggli: I know of a company that embeds v4 literals in HTTP. Surprisingly often a problem in apps other than web browsers. Also may break SSL. Dave Thaler: yes, doesn=B9t cover cookies. Doesn=B9t mention that DNSSEC doesn=B9t work. Doesn=B9t mention 464xlat as an alternative. Erik Nygren: cookie problem should also be in security consideration section. If we need to do this for IPv4, consider whether we should do it for IPv6 literals. If that=B9s bad, it may also be bad in IPv4. Cameron Byrne: have you tested this? I did something similar, and Apache virtual host expects name in header to be the same as the name. Maybe we should say =B3IPv4 literals should go away.=B2 As in rfc1958. Joel Jaeggli: Referring URL case where it breaks is when you expect to see the IPv4 literal. Outcome: update, and take to DNSOP =20 Considerations on IPv6-only DNS Development Lianjing Song Mark Andrews: Android isn=B9t an IPv6-compliant node because it doesn=B9t support EDNS0. 512bytes isn=B9t an effective limit anyway. Erik Kline: How do you know EDNS0 works everywhere? Mark Andrews: Yes, I have been measuring EDNS0. I=B9ve found exactly one server (.is) that blocks on 512bytes. Cameron Byrne: Not so much the auth servers, but it=B9s the endpoint support for EDNS0. We just heard from an Android developer asking if it works. Dea= r DNSOP: please develop EDNS0 Happy Eyeballs. Mark Andrews: Can=B9t we just get IPv6 hosts to do the right thing? Andrew Sullivan: I know there are endpoints (and proxies) that can=B9t do EDNS0. Frankly, message sizes are getting bigger and people are counting on that. We can=B9t come up with another kludge. If Android is broken, it=B9s broken. If middleboxes are broken, they=B9re also broken. Erik Kline: I would love to see EDNS0 support in Android. How many home CPEs will do bad things with this kludge, and the implied performance problem. Outcome: Take to DNSOP and SUNSET4. IPv6 Considerations for NFV Hui Deng =B3Floating IP=B2 means NAT John Brzozowski: OpenStack networking isn=B9t networking, it=B9s bridging large domains. Fred: See other drafts with =B3openstack=B2 in the title Outcome: Discuss on mailing list =20 =20 --B_3498722607_12781117 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Below, my notes from this week's meetings.  I'd l= ike some review before I post them as meeting minutes.


Lee





<= /p>

IPv6 Operations – IETF91

Monday, 10 November 2014

 

Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)

Brian Carpenter

Proposed as BCP, 6to4 NOT RECOMMENDED in product suppo= rt, MUST disable by default, SHOULD consider dropping 6to4 relay servers, p2p 6= to4 (not depending on anycast) might still be okay

Dave Thaler: If we deprecate 6to4, Teredo is next in l= ine in preference table.  Opposite of what we want.  Thus, do not deprecate rfc3056 (p2p mode) without also deprecating Teredo. But Xbox uses Teredo for p2p, s= o can’t deprecate it yet.

Lorenzo Collitti: We must show harm to deprecate p2p m= ode (3056). We can’t show harm, so we shouldn’t deprecate.

Cameron: I null route 6to4 prefixes, especially 192.88.99.0/24 so it doesn’t create half-open CGN state.  Maybe = need a sunset4 draft saying weird IPv4 brokenness like this will pop up.

Michael Richardson: deprecate rfc3068 only, too much r= isk in deprecating p2p

James Woodyatt: agree.  Also agree that content providers should (instead of may) keep return relays running. Maybe also NAT64 ops should do.

Yourtchenko: Yes, filter 192.88.99.0/24

=

Abramsson: Don’t spend brain cycles on new relay= s

Hums:

Should we deprecate 3068?  YES: Strong hum. 

Should we deprecate 3056?  YES: Hum, NO: slightly stronger hum

Should we recommend filtering 192.88.99.0/24?  YE= S: Weak hum.  NO: Very weak hum

Should we recommend filtering 2002::/16?  YES: On= e hum 

Outcome: Revise draft accordingly, then WGLC

 

SIIT-DC

Tore Anderson, remote

Needs a better name than “SIIT-DC”

Needs co-authors

Yourtchenko: Could also do CLAT function as bump in th= e API

Cameron would use this, may review but couldn’t = co-author

Thaler: This isn’t a new protocol, just good use= cases.  Prefer the name “Stateless NAT64”.  &nbs= p; Clarify rationale for static mapping.  Still need a better name.

Adopt both SIIT drafts as WG? YES: Strong hum

Call it stateless NAT64? Weak hum

SIIT-DC?  Quiet

         =    Other? Quiet

Outcome: repost as draft-ietf-v6ops-siit-dc and draft-ietf-v6ops-siit-dc-2xlat.

         =    Cameron Byrne to review

DHCPV6/SLAAC Interaction

Bing Liu

Bernie Volz: DHC WG is working on 3315-bis. (Revising dhcpv6)

Lorenzo Collitti: There is no problem, just different implementations.  The problem statement draft can just document what implementations do.  Document undocumente= d-unspecified behaviors.  Don’t call it a problem statement; add more testing and give it to operators documenting these corn= er cases.  Don’t think we should adopt –Guidance, until/unless we see real operational problems.<= /p>

Fred: So should the Guidance draft go to DHC to inform= their update?

Brian Carpenter: Disagree with everything Lorenzo said= .  6renum noted that changing mechanisms really breaks stuff.  Stall on –Guidance doc.  DHC should look at it, to make sure they don’t make anything worse, need 6man to fix what exists now.

Yourtchenko: For some of the inconsistent behaviors, w= e don’t know what the “right” behavior is. 

Lorenzo Collitti: If we do what Brian says, 6man will = say, “We deprecated M and O.”

Ole Troan: If someone proposed a solution, we would li= sten to it.

Barbara Stark: The ambiguity exists; document the ambi= guous behavior. If you want to make it less ambiguous, go to 6man.

=

Suresh Ramasubramanian: See rfc4861 and rfc4862

Summary: DHCPv6/SLAAC problem statement: Focus on beha= viors in real implementations (and maybe rename it). 

Outcome:  Adopt –Guidance as WG doc?  YES: Silence, NO: weak hum

 

 

Considerations For Using Unique Local Addresses

Bing Liu

Brian Carpenter: Is this consistent with what Homenet is saying?

Bing: Yes, currently compatible

 

 

Considerations for Running Multiple IPv6 Prefixes

Sheng Jiang

Erik Kline: Strike all text about IPv6 NAT<= /p>

Mikael Abrahamsson: work in progress at MIF, but not s= ure we need to say it

Lorenzo Collitti: Security isn’t unique to multi= ple prefixes. Specifically, let’s not put a lot of text saying “mul= tiple prefixes will exhaust ND cache,” when hosts give multiple addresses anyway.&nb= sp; Take the text out, and put it in a new document.  Maybe not call attention to LLA as multiple prefixes.  But if you take that out, you’re only left with stuff MIF is still doing, and UL= A.

Brian: Targeted at enterprises, so it’s differen= t and useful.

Summary:  wait

 

 

Introducing IPv6 vulnerability test program in Japan

Ruri Hiromi

Vyncke: all in Japanese?  Yes.  DOS to router or host?

Outcome: not a WG document

 

 

Discovery of the IPv6 Prefix in 464XLAT

No presentation

 

IPv6 Extension Headers in the Real World

Fernando Gont

Packets with EH are often dropped.

20% drop rate for fragments

10% drops for Destination Options

40% drops for Hop-by-Hop options

25% for fragmented traffic

20-60% of drops occur at an AS other than Destination = AS

Thus, if you design stuff relying on EH that uses the Internet, you need a fallback mechanism

Several comments about how terrible it is that people = are dropping packets with EH.

In a network that filters EH, there’s a vulnerab= ility: an attacker could send Packet Too Big, resulting in atomic fragments, which require EHs, so traffic gets dropped.

Dave Thaler: dropping IPv6 EHs “for security rea= sons” (to avoid DOS attacks) simply creates an alternate vulnerability (for DOS attac= ks)

Tony Hain offers to host measurement tools, too

Draft authors Jen Linkova used Atlas probes, Fernando = used his own tools

Eric Vyncke: can we identify the problem ASNs?

         =    Would also test on his p2p network

Mike Ackerman: what can we do about it?

=

Nalini Elkins: Is it that 90% on one network and 1% on= another network are getting dropped which totals out to the percentages abo= ve?

Joel Jaeggli: I have to find the L4 header, so I make = edge decisions about what to drop, but they only affect me

Merike Kaeo: need data on mobility and IPSec

Would you like to see a data development study as a WG= item? YES: hum, NO: slightly weaker hum

Do we want a draft that would work through recommendat= ion on how to configure? YES: Very weak hum, NO: even weaker

Outcome: Split the document into problem measurements = and recommendations

 

 

D= esign Choices for IPv6 Networks

Victor Kuarsingh presenting

=E0 This needs usefulness review on NOG

Dave Thaler: Right now, content doesn’t match sc= ope of title and abstract. It’s okay to identify “future work” or othe= r documents.  ULA, DHCPv6 vs SLAAC; at least say, “Here are some design choices discussed in other documents.”

Security Considerations section is TBD, do not go to W= GLC

         =    SeND, SAVI, etc. etc.

Jen Linkova: Say ISIS multi-topology.  Saying LLA= doesn’t go beyond link turns out to be untrue.

Eric Vyncke:  Go to WGLC quick, before scope increases.  Tighten title and abstract and go.  Don’t forget to mention EH.

To do:

Change title and abstract

Add ULA, DHCPv6 vs SLAAC references

Add Security considerations

Outcome: Make those revisions, then solicit review (ma= ybe via WGLC)

 

A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environm= ents

Hiroaki Hazeyama

Dan Wing: Yes, there are still problems with IPv4 lite= rals

Andrew Sullivan: I think NAT64/DNS64 is a kludge, and = we’ve always known this was going to break. Strongly opposed to creating a specia= l purpose TLD. If you must, use v4only.arpa

Joel Jaeggli: I know of a company that embeds v4 liter= als in HTTP. Surprisingly often a problem in apps other than web browsers.  A= lso may break SSL.

Dave Thaler: yes, doesn’t cover cookies.  D= oesn’t mention that DNSSEC doesn’t work. Doesn’t mention 464xlat as an alternative.

Erik Nygren: cookie problem should also be in security= consideration section. If we need to do this for IPv4, consider whether we should do it for IPv6 literals. If that’s bad, it may also be bad in = IPv4.

Cameron Byrne: have you tested this?  I did somet= hing similar, and Apache virtual host expects name in header to be the same as the name.

         =    Maybe we should say “IPv4 literals should go away.”  As in rfc1958.

Joel Jaeggli: Referring URL case where it breaks is wh= en you expect to see the IPv4 literal.

Outcome: update, and take to DNSOP

 

Considerations on IPv6-only DNS Development

Lianjing Song

Mark Andrews: Android isn’t an IPv6-compliant node because it doesn’t support EDNS0.  512bytes = isn’t an effective limit anyway.

Erik Kline: How do you know EDNS0 works everywhere?

Mark Andrews: Yes, I have been measuring EDNS0. I’ve found exactly one server (.is) that blocks on 5= 12bytes.

Cameron Byrne: Not so much the auth servers, but it’s the endpoint support for EDNS0. We just heard from = an Android developer asking if it works.  Dear DNSOP: please develop EDNS0 Happy Eyeballs.

Mark Andrews: Can’t we just get IPv6 hosts to do the right thing?

Andrew Sullivan: I know there are endpoints (and proxies) that can’t do EDNS0. Frankly, message sizes a= re getting bigger and people are counting on that. We can’t come up with another= kludge. If Android is broken, it’s broken. If middleboxes are broken, they= 217;re also broken.

Erik Kline: I would love to see EDNS0 support in Android.  How many home CPEs will do bad things with this kludge, and the implied performance problem.

Outcome: Take to DNSOP and SUNSET4.

IPv6 Considerations for NFV

Hui Deng

“Floating IP” means NAT

John Brzozowski: OpenStack networking isn’t networking, it’s bridging large domains.

Fred: See other drafts with “openstack” in the title

Outcome: Discuss on mailing list

 

 

--B_3498722607_12781117-- From nobody Thu Nov 13 13:39:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69A1AD6EC for ; Thu, 13 Nov 2014 13:39:40 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf2bLaC-GOKs for ; Thu, 13 Nov 2014 13:39:38 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6481AD6EA for ; Thu, 13 Nov 2014 13:39:38 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id AEAB810063F24; Thu, 13 Nov 2014 21:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415914773; bh=VkBYXu8jx5v4zMWjxFCUMsGVxRiQHQqfPXy+XFnL3eU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=UvD1IR1RUUkFopf16TLFtgZa/edmdc+Fi7tFApc/WIatcWGDRkcHDcDRpxP4FkLFZ jX0vJDC6xswPm2gmxUL69JF/lo5cZ/bID5+/5VwwAC3651jtvqZH+mln7yL74/RJQI SrQxgtC1Dynyxsb59/eLDzGkRi2HVdSUFz6HBSuTXMdSh9fKo7BYedFBM37/ei0Ff3 Xii5cI7gbtwm6bTskQWuv6CZ39Y34t4zNKu4iOGoCdmP/57WriU4/agJFq/4Vu5W/H UC22j/yH5FwvbutM7o0NFcc/CjLktrjNbbUfDLGmCiq8vEiE24ca8xqfQQuH9dWNjd +TrNkECVDEq5A== Message-ID: <54652514.6050905@massar.ch> Date: Thu, 13 Nov 2014 22:39:32 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: George Michaelson References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54651AC6.5080704@massar.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/M3k2E-u2tfIjkDzczu4TyVIy2vc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] "Severe distortion in RTT" (Was: Bar BoF on a 6to4 replacement?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:39:40 -0000 On 2014-11-13 22:16, George Michaelson wrote: > Sure. ping6 algebras.org and ping algebras.org > . I just did this from Dallas, and the effective > difference in RTT was 50ms, and about 1/3 of the RTT extra compared to > V4. 33% is a heavy penalty. 64 bytes from geeohgeegeeoh-1-pt.tunnel.tserv15.lax1.ipv6.he.net: icmp_seq=3 ttl=52 time=317 ms 64 bytes from ec2-54-79-110-87.ap-southeast-2.compute.amazonaws.com (54.79.110.87): icmp_seq=1 ttl=49 time=368 ms Yeah, I see those 50ms in the wrong direction ;) > I did the same from Hetzner in Germany, the effect was reversed. Why? > because HE peers directly with the transit behind my Hetzner node, so > its a good path embedded in HE. So the initial look from one asset I > have is "wow: v6 is great" but from another asset outside that family.. > its 100% inverse. Yep. But that is purely a peering policy and or just BGP bad/good luck. Can even happen with an ISP's IPv4 and IPv6 prefixes. Though because of likely getting upstream/transit from the same place there is a higher chance for it being the same. > Thats what I mean by RTT distortions. The effect of the tunnel is highly > variable RTT depending on where you are, compared to V4. Understood. > the 6 is an HE tunnel, whose endpoint is the US west coast. Had I chosen > their SG or HK presentation, I'd be even worse because of the trombone > of the path from AU to SG being via the USA. > > I entirely understand your retort will be "so use gogo" or "so use sixx > in AU via AARNET" but thats the thing Note that there is no SixXS PoP in AARnet. AARnet does have a GogoServer though, which is not Freenet6. But for the SixXS nodes in Australia (provided by OCCAID): aubne01:~$ ping 54.79.110.87 PING 54.79.110.87 (54.79.110.87) 56(84) bytes of data. 64 bytes from 54.79.110.87: icmp_req=1 ttl=56 time=17.8 ms That is quite close to there... ausyd01:~$ ping 54.79.110.87 PING 54.79.110.87 (54.79.110.87) 56(84) bytes of data. 64 bytes from 54.79.110.87: icmp_req=1 ttl=56 time=2.89 ms That is likely in the same datacenter.... ;) Though that is just the first hop, the rest of the circuit might be completely different from what you have currently. YMMV etc. > the reason I took HE is because > when I searched google for IPv6 tunnel FreeBSD (I can't remember the > exact search) the top hit was HE and it was simple to configure. As HE provides 'normal proto-41 tunnels' any provider doing proto-41 config is the same btw. (See the list on wikipedia for a full overview) That said: use the best endpoint and get great connectivity. Indeed, I won't say "use SixXS, it is awesome" (even though it is) but I do say to use the best connectivity one can get, if that is native great, if it is something other than SixXS also excellent. (And as Gert mentioned, one day those PoPs will disappear too, or I just get tired of approving tunnels and fixing things all the time) Since having bashed Hurricane a lot years ago when they had a lot of broken and bad connectivity with very bad peering setups they have improved a lot (clearly the bashing helped :) thus likely the connectivity is just fine. > shooting yourself in the foot is very easy with hand-install tunnels. That rarely happens if you have been configuring thousands of them ;) Greets, Jeroen From nobody Thu Nov 13 13:43:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997091AD72A for ; Thu, 13 Nov 2014 13:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWLoh8hU4bVO for ; Thu, 13 Nov 2014 13:43:07 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDCC1AD73E for ; Thu, 13 Nov 2014 13:43:06 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 568FE10063F24; Thu, 13 Nov 2014 21:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415914984; bh=/0oI9Lw8K0SJ0WlHGIw48QaVB468cVWI7FeE5daTmyg=; h=Date:From:To:Subject:References:In-Reply-To; b=yaEDkS/EI8yfs99yr7w+uNKhe/MmzFD1v2DnhlnSnZEn8GTwMPBUPnJS7tPYT5WCZ NBD6fpaP3yPFxeleg+4nLmhBMD/ZjH0vgs7f+G6Np8QkjszuFLLHfwY/O95qX2ZgxX SkPaaawpqtc+TMVFXWWxoYS4rokkgTttdCFP9FwLoD/u95OmRNItyVpThiW5HA5a09 +mzBIIhSRYcfEPP7PJgdX+ByYFs1xygbKg1kDm1v71U0ulmTGo4blW88tYMW/+3Van mMiKyTY4zx+0MyR1wv0QFNkWHPG17M0zq1TeTQep5enZjwoDrEcFUDkRNmUqg1OSDi dJ3r0VicUV9Cg== Message-ID: <546525E7.7050006@massar.ch> Date: Thu, 13 Nov 2014 22:43:03 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> In-Reply-To: <54652069.30805@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0bK35K9Ol5-okkQo7FOokivdqgM Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:43:08 -0000 On 2014-11-13 22:19, Alexandru Petrescu wrote: > Le 13/11/2014 20:43, Jeroen Massar a écrit : > [...] >> This is also what has been discussed on the list: >> - deprecate anycast 6to4 >> - keep direct 6to4 > > YEs, I agree, and I would like to re-mention the point about software bugs. > > There is one particular 6to4 implementation in the wild which has two > different means to put up a 6to4 tunnel. One is to just say '6to4' in > the cli, the other is to be specific and type that IPv4 anycast address. > > With the first means - it does not work. Worse, it gets into a mode > where packets are output destined to random IPv4 addresses. > > Fix the bug. That is a vendor issue. Nothing the IETF can do about. > What does this mean with respect to the deprecation effort? That because of the bug that platform already is useless anyway, thus effectively it is already deprecated... ;) > Do not deprecate the IPv4 anycast address because if so then the entire > 6to4 software on that platform will no longer work. If that platform (which one btw) is so broken, then they currently have a broken setup anyway. Hence, nothing to be fixed there. > Do not deprecate until you offer a solution satisfying a number of > requirements (currently unsatisfied by eg tunnel brokers). Which requirements are these? Greets, Jeroen From nobody Thu Nov 13 13:46:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7C1AD8DA for ; Thu, 13 Nov 2014 13:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 94Q61-e5I6Bm for ; Thu, 13 Nov 2014 13:46:32 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E391AD6FD for ; Thu, 13 Nov 2014 13:46:32 -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 sADLkVhq014859; Thu, 13 Nov 2014 13:46:31 -0800 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sADLkPih014824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Nov 2014 13:46:26 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.192]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 13:46:25 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , Iljitsch van Beijnum , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/4tFHDHGKfCB0EmftwA7nxJPVQ== Date: Thu, 13 Nov 2014 21:46:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D85FD3@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> In-Reply-To: <54643D0B.4070208@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: http://mailarchive.ietf.org/arch/msg/v6ops/zSRAag9yXwAOa9GInlUi_gcjydc Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:46:33 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Wednesday, November 12, 2014 9:10 PM > To: Iljitsch van Beijnum; v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? >=20 > Le 12/11/2014 21:12, Iljitsch van Beijnum a =E9crit : > > > > I've been talking to a few people and I think there is potential for > > a draft that lets home gateways (and any other system so inclined) > > have IPv6 tunneling enabled out of the box (like 6to4) but in a way > > that works pretty reliably (unlike 6to4). > > >=20 > > My question to (potential) implementers: > > > > - Is requiring HTTP digest authentication problematic? >=20 > Something I can foresee as a problem is sharing the keys, or do any > encrypted or authenticated exchange, with someone who is on the other > side of the globe, someone non-accountable in any particular way. A > matter of trust. >=20 > > - Is requiring HTTPS problematic? > > - Is requiring JSON parsing problematic? > > * Would using plain text similar to HTTP headers to pass parameters= be better? >=20 > > - Is requiring DHCPv6 (the prefix delegation client role) problematic? >=20 > I guess it is problematic. I am not aware of any operator of DSL or > cellular links that offers DHCPv6 Prefix Delegation service (a Server > that replies positively to requests for prefixes). Others have correctly commented that DHCPv6 PD is widely used by service providers over access links to provide their customers' service. > On another hand, if we talk DHCPv6 Prefix Delegation over a tunnel (like > running it over the tunnel already established by e.g. HE), then there > should be no problem in using it. DHCPv6 PD over a tunnel is exactly the case for AERO, yes. Thanks - Fred fred.l.templin@boeing.com > FWIW. >=20 > Alex >=20 > > > > Thanks, > > > > Iljitsch > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 13 13:48:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6C1ADBD5 for ; Thu, 13 Nov 2014 13:48: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7cKc-7Owpdr for ; Thu, 13 Nov 2014 13:48:28 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9E41ADBD2 for ; Thu, 13 Nov 2014 13:48:28 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 311C410063F24; Thu, 13 Nov 2014 21:48:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415915306; bh=/q+zCjZAr+EHdWy9eH4kWHuaD4hXJm7XYmXmp/MmsvE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=cuRC4K8c3yC4NO62T++Gzxaa0/+siXp1AJTq59buIy65m5b5avvNQH8a2E8gxZJJh h/WcMJd/02SDjMyi9DhXiyTKc3irZv52+DdvlKa21AgZEttIpBZOq8KQSE9FH3k2WU 18K+W0bKB30JQyrcSdnrtMhsLIMJINJ6ETH4l3/VtCgfYgEUMtYEvcjOlgA7maT3PC XinlegRDweDK/N4iNgruKVs34rKoCSSa+MVQG5qd2fQAteHgHlOiwqohNP2PGlktst 17VKswlNcxjn70TPCjWlI7vlTmtm5B64GYkofCP68HdUHJidat02NXXqq7ZZuODMM3 eIFNiHjH4oqhA== Message-ID: <54652728.9040901@massar.ch> Date: Thu, 13 Nov 2014 22:48:24 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Gert Doering , Iljitsch van Beijnum References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> In-Reply-To: <20141113195636.GY31092@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FGDt-6fb3yxWQ-e6iVguuM7iYCY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:48:30 -0000 On 2014-11-13 20:56, Gert Doering wrote: > Hi, > > On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >> There's no reason tunnels have to be so-so. > > I'm wondering who would provide these tunnels in the future, and what would > their business model be. These services already exists, they are called "VPN Providers". Typically used for the more shady reasons, but they can in more professional forms be used for what most people tend to use IPv6 for: getting connectivity with a public IP address. > This is a real question. Today, you can get tunnels from Sixxs nodes > (enthusiasts, which might eventually consider the IPv6 deployment issue > to be "solved" and stop running tunnel nodes) That is the end goal indeed :) [..] > but as with 6to4 relays, what is the incentive to > run a tunnel broker in 2-3 years from now? Getting IPv6 out there, learning from the problems, letting people use it. But as when closing down the 6bone: we are today already long past the point where these experiences are needed. We know what is broken and we know how to approach it. Tunnel Brokers, 6rd etc are transition tech. Hopefully everybody will have native at one point or another. > You won't get paid (users do > not pay for IPv6, otherwise they would go and choose ISPs that provide > v6)... VPN providers are proof that people pay for tunneled connectivity. Heck, most of those are stuffing users behind NAT and not even giving public IP addresses away to "protect the anonymity of the user"... And there are tunnel brokers doing it for fun and free ;) It is all magic :) Greets, Jeroen From nobody Thu Nov 13 13:56:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FCD1ADF2A for ; Thu, 13 Nov 2014 13:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJmzCSfsltgx for ; Thu, 13 Nov 2014 13:56:47 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA181ADEBA for ; Thu, 13 Nov 2014 13:56:46 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 5B67210063F52; Thu, 13 Nov 2014 21:56:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415915804; bh=TmzJ8U+XXmm7Lw3tPM8egM2Np9uOHQTaCoBSsg8dHdQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fMX4fuTzWuLJnMLj+yMabrz1OIHfq5JQIGq62djj+s7f2V+34dfWb+wCyw8VTYzZo QYOOd1w/PDT3AT8Co3+EkxypD2fzkANxpMRDaBl7rHXD41UcXzxWDdZeKlR3dtBb9J vR2vsPTDsJZ5AtzWv/6NEMp1M+MtWjoA6lB26Glih+WNml36JQlWU4LrPvKw3jtLSg 1ha2Qcqb9kS8LWTfbbvSa0J3eHUDWS+hTXl1tea6+XnXybJcxKaXWJHoiZu8iKg7B1 /ZonRBbgwaDW/A1qPn8/frxBXETihPozG4KxdFgagUruxPyBsYzv0HydRshMLIDtwZ A9Sp0rPsA2knw== Message-ID: <54652919.40507@massar.ch> Date: Thu, 13 Nov 2014 22:56:41 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VlDk7euDdQLr_0RhvB3fUPB5juI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 21:56:49 -0000 On 2014-11-13 20:50, Iljitsch van Beijnum wrote: [..big snip..] > However, IPv4 is going to get worse as CGN gets rolled out and > especially as the number of users behind an IPv4 address increases. > At some point, lack of port numbers is going to become problematic > for some users. Tunnels will not fix this problem. Actually: there are German providers doing DSLite/AFTR kind of setups. Their IPv6 at one point was so broken that various folks started doing AYIYA tunnels over the CGN to get working IPv6... Another effect that was seen that apparently some of the CGN boxes would give a public IP to a user when doing non-TCP/UDP "to maintain compatibility with VPNs", and thus people would use a proto-41 tunnel and just keep it pinging so that they got a public IPv4 address ;) > There's no reason tunnels have to be so-so. A tunnel discovery > mechanism would be helpful in finding the best tunneling option that > a user can use at a given time using a given connection to the > network, and of course if no good options are available, the system > can say so and no IPv6 tunnel is set up. By having the smarts inside > a limited number of servers rather than in millions of individual > home gateways, it's easy to react to changing circumstances. Such a system need to be cooperative. Not going to happen. Also note that latencies and throughputs change. Thus the moment you would do a measurement the properties would be X and moments later Y. Are you going to move the user or just keep them on the same box? Too many issues that even I don't want to bother solving... As a anecdote: SixXS used to ping all the tunnel endpoints for selecting the 'best' PoP. Hence a user providing an IPv4 address when requesting a tunnel would suddenly get a stream of pings from 50+ sources (and firewall alarms suddenly went off ;). The result though is that the user would only be eligible to get 1 PoP as there was only 1 PoP serving their area. Or that PoP had the best ping but actually was shoveling a lot of traffic already, thus it was better to pick another one etc. Hence why we just manually approve the tunnels and allow the users to prefer a PoP that they are eligle for. This approval process is a big scaling issue but it does also allow people from making mistakes, eg "I have a Fritz!Box" and then requesting an AYIYA tunnel... (The TIC server fixes up that mistake when it sees a Fritz!Box client requesting a tunnel though ;) Greets, Jeroen From nobody Thu Nov 13 14:02:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA101ADF8E for ; Thu, 13 Nov 2014 14:02: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 QWxomoGb0nW9 for ; Thu, 13 Nov 2014 14:02:44 -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 8D4C71ADF61 for ; Thu, 13 Nov 2014 14:02:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADM2gIC010505; Thu, 13 Nov 2014 23:02:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6AB1F20484B; Thu, 13 Nov 2014 23:03: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 5E25E20425F; Thu, 13 Nov 2014 23:03:02 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADM2MWx001228; Thu, 13 Nov 2014 23:02:41 +0100 Message-ID: <54652A69.8010008@gmail.com> Date: Thu, 13 Nov 2014 23:02:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> In-Reply-To: <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j88T8uOWw-AOXGtbM2RNdyFi-L8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:02:46 -0000 Hi Iljitsch, just some clarification. Le 13/11/2014 20:21, Iljitsch van Beijnum a écrit : > On 12 Nov 2014, at 19:09, Alexandru Petrescu > wrote: > >>> - Is requiring HTTP digest authentication problematic? > >> Something I can foresee as a problem is sharing the keys, or do any >> encrypted or authenticated exchange, with someone who is on the >> other side of the globe, someone non-accountable in any particular >> way. A matter of trust. > > Yes, it would be somewhat risky to put the cloud credentials that > give access to your entire digital life inside a $50 home gateway. So > it would be good to require OAuth (RFC 6749). On the other hand, that > could be quite a barrier for implementers. > > However, I'd say that HTTP digest authentication is secure enough to > protect an account that is only used to set up a tunnel. Sorry, I didnt mean to challenge the strength of such and such security protocol. I meant to say that a new mechanism involving two endpoints (e.g. DSL box, and tunnel endpoint on the other side) should offer enough confidence to the DSL box about the legitimacy and goodwill of the tunnel endpoint. Something like what the 3rd party CAs offer, but not that. >>> - Is requiring DHCPv6 (the prefix delegation client role) >>> problematic? > >> I guess it is problematic. I am not aware of any operator of DSL >> or cellular links that offers DHCPv6 Prefix Delegation service (a >> Server that replies positively to requests for prefixes). > > It doesn't matter what the network operators do. If they provide > native IPv6, then the whole effort is moot. What counts is what we > can reasonably ask home gateway vendors to implement. Then I think it is reasonable to think that a home gateway includes a DHCPv6 Client able to issue Prefix Delegation requests and treat replies accordingly. Alex > > Iljitsch > From nobody Thu Nov 13 14:14:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CDD1ADFE1 for ; Thu, 13 Nov 2014 14:14:25 -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 t1rlXkJbV2Ja for ; Thu, 13 Nov 2014 14:14:20 -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 3119E1ADFD5 for ; Thu, 13 Nov 2014 14:14:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMB0xY011996; Thu, 13 Nov 2014 23:11:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B71492047E4; Thu, 13 Nov 2014 23:11:20 +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 A776D20473E; Thu, 13 Nov 2014 23:11:20 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMAppQ003991; Thu, 13 Nov 2014 23:10:59 +0100 Message-ID: <54652C6A.7060606@gmail.com> Date: Thu, 13 Nov 2014 23:10:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Doug Barton , Gert Doering , Ole Troan References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <20141113195958.GZ31092@Space.Net> <54650E87.5050407@dougbarton.us> In-Reply-To: <54650E87.5050407@dougbarton.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H4ckpLDG2yglQNZzq0frCZ9gDU8 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 22:14:26 -0000 Le 13/11/2014 21:03, Doug Barton a écrit : > On 11/13/14 11:59 AM, Gert Doering wrote: >> Hi, >> >> On Thu, Nov 13, 2014 at 09:52:48AM -1000, Ole Troan wrote: >>> it certainly would be interesting to hear what existing use cases >>> there are for peer to peer mode 6to4 (as in without relays). I also >>> have a hard time understanding the usefulness of keeping any of it. >> >> Well, access to hosts behind a router with one global IPv4 address and >> a 6to4 gateway in it comes to mind - without having to configure explicit >> NAT mappings on the router. I think this is Keith's scenario. >> >> (Client has working global IPv4, Router has working global IPv4, neither >> has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: >> addresses derived from Router's v4 address) > > Isn't that the use case that ULAs are meant to cover? Or am I missing > something here? I agree. But when confronted to a similar situation I missed a description in the ULA RFC which tells how to form an IPv6 prefix out of an IPv4 address. (section 3.2.2 code for pseudo-rqndmo globql ID). Alex > > I made the point earlier that (for example) OpenWRT already has support > for PD, it also creates a ULA network on the LAN side, whether you have > a public prefix (or tunnel) or not. So all of that is doable today, with > running code. > > Doug > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 13 14:17:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA23E1AD554 for ; Thu, 13 Nov 2014 14:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 GFK8hhGV8Owm for ; Thu, 13 Nov 2014 14:17:42 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756E91ACE99 for ; Thu, 13 Nov 2014 14:17:42 -0800 (PST) Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:d573:809e:ee75:c727]) by dougbarton.us (Postfix) with ESMTPSA id 0866D22B1C; Thu, 13 Nov 2014 22:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415917062; bh=NpqD/X5WCFe/qIn0pdZs2cTxYfct7BfMulgnwqwib48=; h=Date:From:To:Subject:References:In-Reply-To; b=iwYXCPmyAeteMFD4Js2BhexUNkjJz7WQs2Ssj9SpE2/jh/i+8zi37ZIi+TOSt/dgG FHKIWG2Ole1dZf8UrINpqQPxVsjOnS/e8Jo0UAKPS40Gft24Dc8tKUJw0fGMKrXx8y S1sZOARxBWet/NnAWAUVBZpurgTJjUCeG9oW4drw= Message-ID: <54652E05.1020402@dougbarton.us> Date: Thu, 13 Nov 2014 14:17:41 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alexandru Petrescu , Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> In-Reply-To: <54652069.30805@gmail.com> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CX3_zMRGyDcocfu9CmR_Tr5w61k Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:17:44 -0000 On 11/13/14 1:19 PM, Alexandru Petrescu wrote: > YEs, I agree, and I would like to re-mention the point about software bugs. > > There is one particular 6to4 implementation in the wild which has two > different means to put up a 6to4 tunnel. One is to just say '6to4' in > the cli, the other is to be specific and type that IPv4 anycast address. > > With the first means - it does not work. Worse, it gets into a mode > where packets are output destined to random IPv4 addresses. Alexandru, This is merely a special case of the general proposition, "6to4 does not work well, and needs to go away." I think your analysis is correct, but your conclusion is the exact opposite of what I think the facts dictate. Meanwhile, I'm interested in learning more about "a solution satisfying a number of requirements (currently unsatisfied by eg tunnel brokers)." What are those requirements, and why don't the tunnel brokers meet them? Doug From nobody Thu Nov 13 14:18:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C511AD6EA for ; Thu, 13 Nov 2014 14:18:12 -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 cVLYIJuNMJoS for ; Thu, 13 Nov 2014 14:18:06 -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 EC3DF1AD6F5 for ; Thu, 13 Nov 2014 14:17:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMHwiq007741; Thu, 13 Nov 2014 23:17:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 397DD2047E4; Thu, 13 Nov 2014 23:18:18 +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 2E1352046F4; Thu, 13 Nov 2014 23:18:18 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMHn59006029; Thu, 13 Nov 2014 23:17:57 +0100 Message-ID: <54652E0C.7050901@gmail.com> Date: Thu, 13 Nov 2014 23:17:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> In-Reply-To: <546525E7.7050006@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5jQ19SbS7hMIxwNFnrzZ83yYxhc Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:18:13 -0000 Le 13/11/2014 22:43, Jeroen Massar a écrit : > On 2014-11-13 22:19, Alexandru Petrescu wrote: >> Le 13/11/2014 20:43, Jeroen Massar a écrit : >> [...] >>> This is also what has been discussed on the list: >>> - deprecate anycast 6to4 >>> - keep direct 6to4 >> >> YEs, I agree, and I would like to re-mention the point about software bugs. >> >> There is one particular 6to4 implementation in the wild which has two >> different means to put up a 6to4 tunnel. One is to just say '6to4' in >> the cli, the other is to be specific and type that IPv4 anycast address. >> >> With the first means - it does not work. Worse, it gets into a mode >> where packets are output destined to random IPv4 addresses. >> >> Fix the bug. > > That is a vendor issue. Nothing the IETF can do about. I agree. > >> What does this mean with respect to the deprecation effort? > > That because of the bug that platform already is useless anyway, thus > effectively it is already deprecated... ;) > >> Do not deprecate the IPv4 anycast address because if so then the entire >> 6to4 software on that platform will no longer work. > > If that platform (which one btw - sponsor) is so broken, then they currently have > a broken setup anyway. Hence, nothing to be fixed there. > >> Do not deprecate until you offer a solution satisfying a number of >> requirements (currently unsatisfied by eg tunnel brokers). > > Which requirements are these? Ones one would have to lay down and agree on before engaging in new work. For example -1- must allow for reverse DNS ok, -2- must be secureable by existing e2e IPsec, -3- to the extent of possible be easy to set up for Clients and not involve intervention of another party (like when requesting an IPv6 address from an administrator, delayed paper forms, etc). Alex > > Greets, > Jeroen > > > From nobody Thu Nov 13 14:23:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811D11AE020 for ; Thu, 13 Nov 2014 14:23:04 -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 Oji2nNFqotgI for ; Thu, 13 Nov 2014 14:23:02 -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 78BDB1AE011 for ; Thu, 13 Nov 2014 14:23:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMN05g024131; Thu, 13 Nov 2014 23:23:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5BE922047E4; Thu, 13 Nov 2014 23:23:20 +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 4C4E920453C; Thu, 13 Nov 2014 23:23:20 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMMurV007599; Thu, 13 Nov 2014 23:22:58 +0100 Message-ID: <54652F3F.2090006@gmail.com> Date: Thu, 13 Nov 2014 23:22:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , Gert Doering , Iljitsch van Beijnum References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> In-Reply-To: <54652728.9040901@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qvAiuho_SCPrydISghucpWyaONc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:23:04 -0000 Le 13/11/2014 22:48, Jeroen Massar a écrit : > On 2014-11-13 20:56, Gert Doering wrote: >> Hi, >> >> On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >>> There's no reason tunnels have to be so-so. >> >> I'm wondering who would provide these tunnels in the future, and what would >> their business model be. > > These services already exists, they are called "VPN Providers". > > Typically used for the more shady reasons, but they can in more > professional forms be used for what most people tend to use IPv6 for: > getting connectivity with a public IP address. > > >> This is a real question. Today, you can get tunnels from Sixxs nodes >> (enthusiasts, which might eventually consider the IPv6 deployment issue >> to be "solved" and stop running tunnel nodes) > > That is the end goal indeed :) > > > [..] >> but as with 6to4 relays, what is the incentive to >> run a tunnel broker in 2-3 years from now? > > Getting IPv6 out there, learning from the problems, letting people use it. > > But as when closing down the 6bone: we are today already long past the > point where these experiences are needed. > > We know what is broken and we know how to approach it. > > Tunnel Brokers, 6rd etc are transition tech. Hopefully everybody will > have native at one point or another. Goal - any new replacement of 6to4 must be future proof: avoid renumbering when 6to4-replacement dies out. (this is what current tunnel brokers dont offer, they force one into a lockin going away from tunnel broker to native IPv6 one has renumber). Alex > >> You won't get paid (users do >> not pay for IPv6, otherwise they would go and choose ISPs that provide >> v6)... > > VPN providers are proof that people pay for tunneled connectivity. > > Heck, most of those are stuffing users behind NAT and not even giving > public IP addresses away to "protect the anonymity of the user"... > > > And there are tunnel brokers doing it for fun and free ;) > It is all magic :) > > Greets, > Jeroen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 13 14:26:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF81AE02F for ; Thu, 13 Nov 2014 14:26:31 -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 HcER5hh0NG6D for ; Thu, 13 Nov 2014 14:26:29 -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 9750A1AE034 for ; Thu, 13 Nov 2014 14:26:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMQPvi008880; Thu, 13 Nov 2014 23:26:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 67CBE2047E4; Thu, 13 Nov 2014 23:26:45 +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 5A6D8204082; Thu, 13 Nov 2014 23:26:45 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMQKq5008486; Thu, 13 Nov 2014 23:26:24 +0100 Message-ID: <5465300C.8050206@gmail.com> Date: Thu, 13 Nov 2014 23:26:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Doug Barton , Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> In-Reply-To: <54652E05.1020402@dougbarton.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wGegNmXKzQP9T8mc-HW2-SQMqrU Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:26:31 -0000 Le 13/11/2014 23:17, Doug Barton a écrit : > On 11/13/14 1:19 PM, Alexandru Petrescu wrote: >> YEs, I agree, and I would like to re-mention the point about software >> bugs. >> >> There is one particular 6to4 implementation in the wild which has two >> different means to put up a 6to4 tunnel. One is to just say '6to4' in >> the cli, the other is to be specific and type that IPv4 anycast address. >> >> With the first means - it does not work. Worse, it gets into a mode >> where packets are output destined to random IPv4 addresses. > > Alexandru, > > This is merely a special case of the general proposition, "6to4 does not > work well, and needs to go away." I think your analysis is correct, but > your conclusion is the exact opposite of what I think the facts dictate. > > Meanwhile, I'm interested in learning more about "a solution satisfying > a number of requirements (currently unsatisfied by eg tunnel brokers)." > What are those requirements, and why don't the tunnel brokers meet them? Requirements or goals whatever one calls them, should be agreed before embarking on new work. What do you think the goals would be? For example, the current tunnel brokers are very good but (1) are not trustful, (2) force into later efforts to renumber when going native, (3) require filling in forms. 6to4 has the advantage of not requiring 3. Alex > > Doug > > > From nobody Thu Nov 13 14:30:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB061AE040 for ; Thu, 13 Nov 2014 14:30:41 -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 yC7d0dJ_5jtv for ; Thu, 13 Nov 2014 14:30:38 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900B01AE041 for ; Thu, 13 Nov 2014 14:30:38 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so17737556wgg.23 for ; Thu, 13 Nov 2014 14:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tSE0edcjUK/BGuywrX0dqOLyLQCi0Hm42pkbvIcbS5M=; b=v4nkzZxjVZ/+YRSnKo7uLxgFKS+an+G551BsILKPjfd4JdbFD6Msx0HVoR3oe8KkF2 GynyZsaRgLZuZk0Up+91uyvtXo7fOlHE5w3/mwDWfTRz/Y3t/xxSxW8oSvBfifACr24n njf4hHAj8g4Z+pub9lY06JBBLly+1d8sVJKnSLh+cHXZRuvrsv+z9iKpygy6F8y13HKz T/0869A/+Zz3bNRnVi9LPWxYbJGg+Ru+zBDZTcuaoi6l0ebbjW3JbER4lHx7oIMMPhaW p7CPY2KpjrKRnAdsT2jBWZivrrIKDnHxYSAmlTqngYm6rX6FNTEaEQmQ0k/SU9vA+48/ XGkg== X-Received: by 10.180.101.200 with SMTP id fi8mr1965868wib.77.1415917837388; Thu, 13 Nov 2014 14:30:37 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id s10sm31487753wjw.29.2014.11.13.14.30.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 14:30:37 -0800 (PST) Message-ID: <54653114.1040801@gmail.com> Date: Fri, 14 Nov 2014 11:30:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> In-Reply-To: <546525E7.7050006@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/drWvAno2nL-ve5U_oWCFaaY1xis Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:30:41 -0000 On 14/11/2014 10:43, Jeroen Massar wrote: > On 2014-11-13 22:19, Alexandru Petrescu wrote: >> Le 13/11/2014 20:43, Jeroen Massar a =C3=A9crit : >> [...] >>> This is also what has been discussed on the list: >>> - deprecate anycast 6to4 >>> - keep direct 6to4 >> YEs, I agree, and I would like to re-mention the point about software = bugs. >> >> There is one particular 6to4 implementation in the wild which has two >> different means to put up a 6to4 tunnel. One is to just say '6to4' in= >> the cli, the other is to be specific and type that IPv4 anycast addres= s. >> >> With the first means - it does not work. Worse, it gets into a mode >> where packets are output destined to random IPv4 addresses. >> >> Fix the bug. >=20 > That is a vendor issue. Nothing the IETF can do about. No, but naming and shaming the implementation might be useful. >=20 >> What does this mean with respect to the deprecation effort? >=20 > That because of the bug that platform already is useless anyway, thus > effectively it is already deprecated... ;) >=20 >> Do not deprecate the IPv4 anycast address because if so then the entir= e >> 6to4 software on that platform will no longer work. >=20 > If that platform (which one btw) is so broken, then they currently have= > a broken setup anyway. Hence, nothing to be fixed there. I agree. Definitely not the IETF's problem. >=20 >> Do not deprecate until you offer a solution satisfying a number of >> requirements (currently unsatisfied by eg tunnel brokers). >=20 > Which requirements are these? If anycast 6to4 worked correctly, we wouldn't be deprecating it at all. But it's broken, we tried to fix it 3 years ago (RFC 6343), and it's still broken. The idea of deprecating it is to help users avoid a broken solution. Those ~100k users that Google sees would be better off with IPv4-only. Brian From nobody Thu Nov 13 14:32:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F941AE04B for ; Thu, 13 Nov 2014 14:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoGaEGx-i-Jr for ; Thu, 13 Nov 2014 14:32:10 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1161AE046 for ; Thu, 13 Nov 2014 14:32:08 -0800 (PST) Received: from dhcp-b324.meeting.ietf.org (dhcp-b324.meeting.ietf.org [31.133.179.36]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sADMVrpK002479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 23:31:55 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <54652F3F.2090006@gmail.com> Date: Thu, 13 Nov 2014 12:31:54 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qcQREeOvbneTM5G_hdUAe80eyV0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:32:11 -0000 On 13 Nov 2014, at 12:22, Alexandru Petrescu = wrote: > Goal - any new replacement of 6to4 must be future proof: avoid = renumbering when 6to4-replacement dies out. (this is what current = tunnel brokers dont offer, they force one into a lockin going away from = tunnel broker to native IPv6 one has renumber). Are you saying that you want to be able to move from a tunnel to native = without renumbering? I don't think that's even a minor goal; renumbering is not a big deal in = a home environment.= From nobody Thu Nov 13 14:33:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56AF1AE04B for ; Thu, 13 Nov 2014 14:33: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 l4HqrZ4uBAD7 for ; Thu, 13 Nov 2014 14:33:56 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129781AE085 for ; Thu, 13 Nov 2014 14:33:13 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so1022189wiw.14 for ; Thu, 13 Nov 2014 14:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1rPohUrtE+mGLYA4oMyy1pNAExGH4lZ/lACMO2RliaA=; b=yADaQ4uKS1dfXZ2DwIYzBmmrvEKZI5Dg1N5glXu3YiOTcRuNMr2vwwrOyt9pEat1hP TYrz8yGwnBqWcP4QNuRLec16VoxpddyKYt8RNCmN1+IRpTeB21FbdMJKWKh0jo9ggzyo KVGd3994+5DSaYcEfBbwey0AT8g3NiSA5zNmIB7umteblcozSRlY5Kd9PvFi4BbgNkRg +1J5kh6IK1JX8Q4g7ETTGSf4+POUAdsStOjTakRDo3mhX7A+xDP4y/QGQ1u29lH4Dslf Y5jJjqinHVcyqy88wJg5Q6s5yIQJKUEmjM0TQBv9MGTMHrW0tXIGBJDCFGzPsjih7dyn GCZg== X-Received: by 10.181.12.6 with SMTP id em6mr2225390wid.24.1415917991887; Thu, 13 Nov 2014 14:33:11 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id cr6sm29826039wjb.44.2014.11.13.14.33.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 14:33:11 -0800 (PST) Message-ID: <546531AF.6@gmail.com> Date: Fri, 14 Nov 2014 11:33:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> In-Reply-To: <54652E0C.7050901@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fwEaAs3XJBYlSSERflQ0JEpyNQQ Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:33:58 -0000 On 14/11/2014 11:17, Alexandru Petrescu wrote: > Le 13/11/2014 22:43, Jeroen Massar a =C3=A9crit : >> On 2014-11-13 22:19, Alexandru Petrescu wrote: >>> Le 13/11/2014 20:43, Jeroen Massar a =C3=A9crit : >>> [...] >>>> This is also what has been discussed on the list: >>>> - deprecate anycast 6to4 >>>> - keep direct 6to4 >>> >>> YEs, I agree, and I would like to re-mention the point about software= >>> bugs. >>> >>> There is one particular 6to4 implementation in the wild which has two= >>> different means to put up a 6to4 tunnel. One is to just say '6to4' i= n >>> the cli, the other is to be specific and type that IPv4 anycast addre= ss. >>> >>> With the first means - it does not work. Worse, it gets into a mode >>> where packets are output destined to random IPv4 addresses. >>> >>> Fix the bug. >> >> That is a vendor issue. Nothing the IETF can do about. >=20 > I agree. >=20 >> >>> What does this mean with respect to the deprecation effort? >> >> That because of the bug that platform already is useless anyway, thus >> effectively it is already deprecated... ;) >> >>> Do not deprecate the IPv4 anycast address because if so then the enti= re >>> 6to4 software on that platform will no longer work. >> >> If that platform (which one btw - sponsor) is so broken, then they >> currently have >> a broken setup anyway. Hence, nothing to be fixed there. >> >>> Do not deprecate until you offer a solution satisfying a number of >>> requirements (currently unsatisfied by eg tunnel brokers). >> >> Which requirements are these? >=20 > Ones one would have to lay down and agree on before engaging in new wor= k. >=20 > For example -1- must allow for reverse DNS ok, -2- must be secureable b= y > existing e2e IPsec, -3- to the extent of possible be easy to set up for= > Clients and not involve intervention of another party (like when > requesting an IPv6 address from an administrator, delayed paper forms, > etc). Anycast 6to4 meets those requirements afaik ;-) Brian From nobody Thu Nov 13 14:39:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC311AE0DB for ; Thu, 13 Nov 2014 14:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 1YnudXY7zP_H for ; Thu, 13 Nov 2014 14:39:06 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF051AE0D0 for ; Thu, 13 Nov 2014 14:39:06 -0800 (PST) Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id EC36A22B1C; Thu, 13 Nov 2014 22:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415918346; bh=ESCK/4h6aHa8WajQpzmGXsoXOh53Sq+c8wIX4ZUMFy4=; h=Date:From:To:Subject:References:In-Reply-To; b=k7kXggvbLgD2yret9/VehUwsDEtN9bDOFpB76y16x4PmBq3VxR+gn3BwQv7nmPSAu BocMnzDkAQtcUZ5wPf84Ogu4fi2ygeqsM0x3zXjZSWThy7cLOzqrupSc869Du3XTaM gYHzwJQpmB2XavbYkvEnB9TJ6QAxyqHLIEqw3xNo= Message-ID: <54653309.6010407@dougbarton.us> Date: Thu, 13 Nov 2014 14:39:05 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alexandru Petrescu , Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> <5465300C.8050206@gmail.com> In-Reply-To: <5465300C.8050206@gmail.com> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_YY1oKRbW8UF1a_56vOiIDQ0rM Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:39:07 -0000 On 11/13/14 2:26 PM, Alexandru Petrescu wrote: > Le 13/11/2014 23:17, Doug Barton a écrit : >> On 11/13/14 1:19 PM, Alexandru Petrescu wrote: >>> YEs, I agree, and I would like to re-mention the point about software >>> bugs. >>> >>> There is one particular 6to4 implementation in the wild which has two >>> different means to put up a 6to4 tunnel. One is to just say '6to4' in >>> the cli, the other is to be specific and type that IPv4 anycast address. >>> >>> With the first means - it does not work. Worse, it gets into a mode >>> where packets are output destined to random IPv4 addresses. >> >> Alexandru, >> >> This is merely a special case of the general proposition, "6to4 does not >> work well, and needs to go away." I think your analysis is correct, but >> your conclusion is the exact opposite of what I think the facts dictate. >> >> Meanwhile, I'm interested in learning more about "a solution satisfying >> a number of requirements (currently unsatisfied by eg tunnel brokers)." >> What are those requirements, and why don't the tunnel brokers meet them? > > Requirements or goals whatever one calls them, should be agreed before > embarking on new work. But you're begging the question on the new work in the first place. :) You're asserting that tunnels cannot do things that you think we should be able to do, making sure that a) you're correct, and b) those things are worth the cost should be a precursor to any discussion on new work. For example, in response to Jeroen you asserted that tunnels don't allow reverse DNS. At least for HE, that assertion is demonstrably false. > What do you think the goals would be? > > For example, the current tunnel brokers are very good but (1) are not > trustful, (2) force into later efforts to renumber when going native, > (3) require filling in forms. 6to4 has the advantage of not requiring 3. ... and yet I would assert that unless we're talking about something that is provider managed (such as 6rd) then automatically enabling it for the user is a bad idea. It will create more problems than it solves, and cause a lot of support calls, which ISPs are not going to like. I'm also pretty sure that to the extent I understand it, your point about renumbering is also invalid. Doug From nobody Thu Nov 13 14:42:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617BD1AE0FB for ; Thu, 13 Nov 2014 14:41:58 -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 Mf1bOGKslQDs for ; Thu, 13 Nov 2014 14:41:57 -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 5AEFB1AE10F for ; Thu, 13 Nov 2014 14:41:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMfku9026591; Thu, 13 Nov 2014 23:41:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EAA62046C1; Thu, 13 Nov 2014 23:42:06 +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 48DF32044C3; Thu, 13 Nov 2014 23:42:06 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMfKvI012592; Thu, 13 Nov 2014 23:41:45 +0100 Message-ID: <5465338F.6090805@gmail.com> Date: Thu, 13 Nov 2014 23:41:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aYqFE9WNNAD-Fu7rHpjXi8ONing Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:41:58 -0000 Le 13/11/2014 23:31, Iljitsch van Beijnum a écrit : > On 13 Nov 2014, at 12:22, Alexandru Petrescu > wrote: > >> Goal - any new replacement of 6to4 must be future proof: avoid >> renumbering when 6to4-replacement dies out. (this is what current >> tunnel brokers dont offer, they force one into a lockin going away >> from tunnel broker to native IPv6 one has renumber). > > Are you saying that you want to be able to move from a tunnel to > native without renumbering? Yes. My situation currently is that my network is on 6to4, it seems to get discarded, and the trustful ISP is not _yet_ offering native. > I don't think that's even a minor goal; renumbering is not a big deal > in a home environment. Depends on the size of the home environment. Considering the operators currently owning 2 devices but announcing to put and control much more devices in your home for IoT apps, one thinks avoiding renumbering could only be beneficial. Alex > From nobody Thu Nov 13 14:42:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8D1AE116 for ; Thu, 13 Nov 2014 14:42:41 -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 SiT1gPgO_qvV for ; Thu, 13 Nov 2014 14:42:37 -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 21C851AE10F for ; Thu, 13 Nov 2014 14:42:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMgZmV016535; Thu, 13 Nov 2014 23:42:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2DEC82047E4; Thu, 13 Nov 2014 23:42:55 +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 1FCED2046C1; Thu, 13 Nov 2014 23:42:55 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMgVVi012918; Thu, 13 Nov 2014 23:42:33 +0100 Message-ID: <546533D7.9080507@gmail.com> Date: Thu, 13 Nov 2014 23:42:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546531AF.6@gmail.com> In-Reply-To: <546531AF.6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IaeE2WXoGoc3acBUO0oiM1CXxPI Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:42:42 -0000 Le 13/11/2014 23:33, Brian E Carpenter a écrit : > On 14/11/2014 11:17, Alexandru Petrescu wrote: >> Le 13/11/2014 22:43, Jeroen Massar a écrit : >>> On 2014-11-13 22:19, Alexandru Petrescu wrote: >>>> Le 13/11/2014 20:43, Jeroen Massar a écrit : >>>> [...] >>>>> This is also what has been discussed on the list: >>>>> - deprecate anycast 6to4 >>>>> - keep direct 6to4 >>>> >>>> YEs, I agree, and I would like to re-mention the point about software >>>> bugs. >>>> >>>> There is one particular 6to4 implementation in the wild which has two >>>> different means to put up a 6to4 tunnel. One is to just say '6to4' in >>>> the cli, the other is to be specific and type that IPv4 anycast address. >>>> >>>> With the first means - it does not work. Worse, it gets into a mode >>>> where packets are output destined to random IPv4 addresses. >>>> >>>> Fix the bug. >>> >>> That is a vendor issue. Nothing the IETF can do about. >> >> I agree. >> >>> >>>> What does this mean with respect to the deprecation effort? >>> >>> That because of the bug that platform already is useless anyway, thus >>> effectively it is already deprecated... ;) >>> >>>> Do not deprecate the IPv4 anycast address because if so then the entire >>>> 6to4 software on that platform will no longer work. >>> >>> If that platform (which one btw - sponsor) is so broken, then they >>> currently have >>> a broken setup anyway. Hence, nothing to be fixed there. >>> >>>> Do not deprecate until you offer a solution satisfying a number of >>>> requirements (currently unsatisfied by eg tunnel brokers). >>> >>> Which requirements are these? >> >> Ones one would have to lay down and agree on before engaging in new work. >> >> For example -1- must allow for reverse DNS ok, -2- must be secureable by >> existing e2e IPsec, -3- to the extent of possible be easy to set up for >> Clients and not involve intervention of another party (like when >> requesting an IPv6 address from an administrator, delayed paper forms, >> etc). > > Anycast 6to4 meets those requirements afaik ;-) Hm yes and no. IPsec and anycast never married AFAIK. 6to4 is not alowing for reverse DNS either, if I am not terribly wrong. Alex > > Brian > > > From nobody Thu Nov 13 14:46:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12F1AE12B for ; Thu, 13 Nov 2014 14:46:16 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCRS_bxr_8VM for ; Thu, 13 Nov 2014 14:46:15 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986351AE12A for ; Thu, 13 Nov 2014 14:46:13 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id ADCAB10063F55; Thu, 13 Nov 2014 22:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415918770; bh=bUtIsd52mF/0oCvqZMR6LtEvCEfeJ8jSyYSAUwvP4QY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=WVJwY0oPic1taIr1h08iTLMG92t6p/Pp/rqaA2wEmM4W9w72EXbQb9XejCmioPbUJ ooE7w9uRGXP/InXN6fkswsw92yH/HQ8CtKnFvkqnFbfQi164Kghxg+9omHL8BH60uz rGM7NJmAf+fBZYfjoZjLfT0+v8wPf7JZA5M8xH0KNZ6aAhKEqJlPsROmR8YPSbcjDQ HxE7isiB6wxC+rZWRWdMvO7dgbLB87DVq04nARidoA72WEVtS7EExtnUgkAnlB2wwo gC83ae+q8veRblRZDlJkSF2NCW6aered2EReWTRi1F2zBT4NcGyag12g2/65ezSAHJ Ob69IQm0VN10A== Message-ID: <546534B0.90300@massar.ch> Date: Thu, 13 Nov 2014 23:46:08 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> In-Reply-To: <54652E0C.7050901@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QtSz__ZxOohipU0AycguwrqdIRE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:46:16 -0000 [Replies to multiple mails in this thread compressed into one] On 2014-11-13 23:17, Alexandru Petrescu wrote: [..] >>> Do not deprecate until you offer a solution satisfying a number of >>> requirements (currently unsatisfied by eg tunnel brokers). >> >> Which requirements are these? > > Ones one would have to lay down and agree on before engaging in new work. > > For example -1- must allow for reverse DNS ok, That is a business decision. Most (all?) TBs provide this. Note that a normal ISP does not do this, hence bit silly to require it for a free tunnel... > -2- must be secureable by existing e2e IPsec, The tunnel or the packets that flow within it? What is the problem you are trying to solve? The packets in the tunnel are 1280+ hence, go IPSec away as much as you want. For securing the tunnel it would require distributing keying material. As IPsec is horrible to configure and does not work through NATs happily (yes, you can patch crap) nobody ever bothered with this. For AYIYA packets are signed btw, hence, no spoofing of those. There is no crypto though there either. >-3- to the extent of possible be easy to set up for > Clients TSP (gogoclient) and TIC (AICCU) solve that problem. CPEs incorporate these tools or have their own implementations (eg Fritz!Box). How much 'easier' do you want it? > and not involve intervention of another party (like when > requesting an IPv6 address from an administrator, delayed paper forms, > etc). Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse. Other Tunnel Brokers and Gogo TSP in "authenticated" mode require that one signs up, just as you would with a IPv4 ISP. This is a "business" decision though. Nothing a technical thing can solve. >From another mail: > For example, the current tunnel brokers are very good but > (1) are not trustful, What do you mean with "trustful"? > (2) force into later efforts to renumber when going native, Changing ISPs typically require that. Only way to avoid that is to get your own PI space. At that point you will be able to arrange your own connectivity too though. > (3) require filling in forms. 6to4 has the advantage of not requiring 3. And 6to4 is unreliable as no ISP can 100% support it. With Tunnel Brokers you are signing up for a service. Signing up requires forms. Though those forms are there primarily to limit abuse too and to enable contacting people when they problems with their tunnel so that it can be resolved. And another mail: > 6to4 is not alowing for reverse DNS either, if I am not terribly wrong. https://6to4.nro.net But even then you still do not want 6to4 as it is unreliable ;) Doug Barton wrote: > ... and yet I would assert that unless we're talking about > something that is provider managed (such as 6rd) then automatically > enabling it for the user is a bad idea. It will create more problems > than it solves, and cause a lot of support calls, which ISPs are not going to like. Exactly. Greets, Jeroen From nobody Thu Nov 13 14:49:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FB21AE138 for ; Thu, 13 Nov 2014 14:49:00 -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 zpNrZjh-2sb2 for ; Thu, 13 Nov 2014 14:48: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 208841AE136 for ; Thu, 13 Nov 2014 14:48:57 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADMmrZc011913; Thu, 13 Nov 2014 23:48:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22F842048B0; Thu, 13 Nov 2014 23:49:14 +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 14B2F2044C3; Thu, 13 Nov 2014 23:49:14 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADMmjXs014573; Thu, 13 Nov 2014 23:48:52 +0100 Message-ID: <5465354D.5070002@gmail.com> Date: Thu, 13 Nov 2014 23:48:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Doug Barton , Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> <5465300C.8050206@gmail.com> <54653309.6010407@dougbarton.us> In-Reply-To: <54653309.6010407@dougbarton.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gSCCtY4eNjN2LixKjEIpo9QzxXI Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:49:01 -0000 Le 13/11/2014 23:39, Doug Barton a écrit : > On 11/13/14 2:26 PM, Alexandru Petrescu wrote: >> Le 13/11/2014 23:17, Doug Barton a écrit : >>> On 11/13/14 1:19 PM, Alexandru Petrescu wrote: >>>> YEs, I agree, and I would like to re-mention the point about software >>>> bugs. >>>> >>>> There is one particular 6to4 implementation in the wild which has two >>>> different means to put up a 6to4 tunnel. One is to just say '6to4' in >>>> the cli, the other is to be specific and type that IPv4 anycast >>>> address. >>>> >>>> With the first means - it does not work. Worse, it gets into a mode >>>> where packets are output destined to random IPv4 addresses. >>> >>> Alexandru, >>> >>> This is merely a special case of the general proposition, "6to4 does not >>> work well, and needs to go away." I think your analysis is correct, but >>> your conclusion is the exact opposite of what I think the facts dictate. >>> >>> Meanwhile, I'm interested in learning more about "a solution satisfying >>> a number of requirements (currently unsatisfied by eg tunnel brokers)." >>> What are those requirements, and why don't the tunnel brokers meet them? >> >> Requirements or goals whatever one calls them, should be agreed before >> embarking on new work. > > But you're begging the question on the new work in the first place. :) I am begging to give a replacement before deprecating. If you dont deprecate and if vendor fixes bugs then one is fine (except reverse DNS, and _any_cast trust matters). > You're asserting that tunnels cannot do things that you think we should > be able to do, making sure that a) you're correct, and b) those things > are worth the cost should be a precursor to any discussion on new work. > > For example, in response to Jeroen you asserted that tunnels don't allow > reverse DNS. The IPv6-in-IPv4 tunnel does not (I didnt mean IPv6-in-IPv6 tunnel not to allow reverse dns - I think it does). > At least for HE, that assertion is demonstrably false. Yes. >> What do you think the goals would be? >> >> For example, the current tunnel brokers are very good but (1) are not >> trustful, (2) force into later efforts to renumber when going native, >> (3) require filling in forms. 6to4 has the advantage of not requiring 3. > > ... and yet I would assert that unless we're talking about something > that is provider managed (such as 6rd) then automatically enabling it > for the user is a bad idea. It will create more problems than it solves, > and cause a lot of support calls, which ISPs are not going to like. > > I'm also pretty sure that to the extent I understand it, your point > about renumbering is also invalid. Ah no, please, dont plan on renumbering. I dont even have software to renumber all these devices and all these radvd.conf files... I can give up my 6to4 address space, but just once. I dont want to do it again in 2 years or so. (I already did it once in the past, its painful). (now I am a particular case and people could discuss theirs, if any). Alex > > Doug > > > > From nobody Thu Nov 13 14:52:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C848E1AE141 for ; Thu, 13 Nov 2014 14:52:21 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO0yDhgt7qg6 for ; Thu, 13 Nov 2014 14:52:20 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA601AE0C6 for ; Thu, 13 Nov 2014 14:52:20 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 979FE10063F57; Thu, 13 Nov 2014 22:52:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415919137; bh=WjTLqXyl+BAWJv4ZadevSBpeYcj8Na6UcMwelyxdO50=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=bg3qtnJpIbPnQ5k9+/CUP72bt14R4DX5SOjg/Z+bq7bSayOABHs6lBllxZLQg7LvZ LXXVi8N6CNr5JyJzTQvm3pd+4tbIawxv7H5ajBD0q5VTDmuwJ9B6nGtCeEE6Jl1Gwj VsLt21FE1CsVoYoqXxiie5PEJgU/gULpLv63Yw21Phk0apWdi4ft4+jQlkiJrDxo3y hEaLwntfz05VKv2I6C/Bbi5TBW2JbgRgMKe5wEg8ntFx4I3x1bZDtBq8g++K1ZEqT2 cAjSaKi7uVQgRA58gXB7aNtKh57QSB/6qgSKVAlKXISfyXCVHANvSmEg4uXMc8k+I2 y8p2dTQRzgVXw== Message-ID: <54653620.7050809@massar.ch> Date: Thu, 13 Nov 2014 23:52:16 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> In-Reply-To: <54652F3F.2090006@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/G94pGgzx6LSosS6vkrXRqm8MknI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:52:22 -0000 On 2014-11-13 23:22, Alexandru Petrescu wrote: [..] > Goal - any new replacement of 6to4 must be future proof: avoid > renumbering when 6to4-replacement dies out. (this is what current > tunnel brokers dont offer, they force one into a lockin going away from > tunnel broker to native IPv6 one has renumber). Please solve this problem for native IPv6, provided by an ISP, first. Then we can apply the same for Tunnel Brokers... Just in case you wonder: for the time being it is called PI. Most Tunnel Brokers give out static prefixes btw; I have had some already for well over 10 years... On 2014-11-13 23:41, Alexandru Petrescu wrote: > Le 13/11/2014 23:31, Iljitsch van Beijnum a écrit : >> On 13 Nov 2014, at 12:22, Alexandru Petrescu >> wrote: >> >>> Goal - any new replacement of 6to4 must be future proof: avoid >>> renumbering when 6to4-replacement dies out. (this is what current >>> tunnel brokers dont offer, they force one into a lockin going away >>> from tunnel broker to native IPv6 one has renumber). >> >> Are you saying that you want to be able to move from a tunnel to >> native without renumbering? > > Yes. My situation currently is that my network is on 6to4, > it seems to get discarded, What gets "discarded"? > and the trustful ISP is not _yet_ offering native. What do you mean with "the trustful ISP"? >> I don't think that's even a minor goal; renumbering is not a big deal >> in a home environment. > > Depends on the size of the home environment. Considering the > operators currently owning 2 devices but announcing to put and > control much more devices in your home for IoT apps, one thinks > avoiding renumbering could only be beneficial. I have a rather extensive home network. Renumbering though means I change the prefix in my config file, and then let my scripts spit out new DNS, new firewall settings etc and push that to the relevant boxes. Renumbering is easy for the portions that are in your own control (yeah, for total control of all that is involved). Renumbering is extremely hard when you need to tell other entities what the new settings are. Oh, and no, I don't want to renumber my network, I love my static prefix. Greets, Jeroen From nobody Thu Nov 13 14:53:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E103C1AE148 for ; Thu, 13 Nov 2014 14:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 d5ef9kU9a7RX for ; Thu, 13 Nov 2014 14:53:09 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A701AE141 for ; Thu, 13 Nov 2014 14:53:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sADMr8OU030316; Thu, 13 Nov 2014 14:53:08 -0800 Received: from XCH-BLV-101.nw.nos.boeing.com (xch-blv-101.nw.nos.boeing.com [130.247.25.116]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sADMqx5Q029777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Nov 2014 14:53:00 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.11]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 14:52:59 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , Jeroen Massar , Gert Doering , Iljitsch van Beijnum Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/5SRBJqwQ4D6aUGjUUXr5CsnMA== Date: Thu, 13 Nov 2014 22:52:58 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> In-Reply-To: <54652F3F.2090006@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cjQ3XJT2wtR_wZerHc1wJPiqg08 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:53:11 -0000 Hi, > Goal - any new replacement of 6to4 must be future proof: avoid > renumbering when 6to4-replacement dies out. (this is what current > tunnel brokers dont offer, they force one into a lockin going away from > tunnel broker to native IPv6 one has renumber). To amplify this point, tunnels are for more than just IPv6 transition. They= are useful also for: - mobility management - routing control - security (e.g., VPN) - multihoming - traffic engineering - renumbering avoidance - etc. You get all of this (plus v6/v4 transition, of course) with AERO. Indeed, AERO can be a one-stop-shopping solution for any tunnel application. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Nov 13 14:57:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA301AE159 for ; Thu, 13 Nov 2014 14:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 j-4lA9tH-PTP for ; Thu, 13 Nov 2014 14:57:30 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E351AE150 for ; Thu, 13 Nov 2014 14:57:30 -0800 (PST) Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id 55EBE22B1C; Thu, 13 Nov 2014 22:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415919450; bh=Gwj5+y3Amruj4msnhFs3IxDKhuFhxlcSHok52cbSJIs=; h=Date:From:To:Subject:References:In-Reply-To; b=gq7ycc4o0FzFbVAmBZPIP3XZgk2YoPisD5qwAq3j5SsTc2eu3R3rPUCbRCFVhu1KB fX5KW9cj06Qb+vtS+buu8xMAuvQsxMCLGjMMpLixmpUD/7VbqEyuARzuQhkmOg66x8 55xWtdhRkm4hRmPLg7M5uGvIqlT2ofVIuDofoGwM= Message-ID: <5465375A.9020908@dougbarton.us> Date: Thu, 13 Nov 2014 14:57:30 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alexandru Petrescu , Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> <5465300C.8050206@gmail.com> <54653309.6010407@dougbarton.us> <5465354D.5070002@gmail.com> In-Reply-To: <5465354D.5070002@gmail.com> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D3bsfAbILTt5BEnTa6C4RrvU5VU Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:57:32 -0000 On 11/13/14 2:48 PM, Alexandru Petrescu wrote: > I am begging to give a replacement before deprecating. If you dont > deprecate and if vendor fixes bugs then one is fine (except reverse DNS, > and _any_cast trust matters). If you are actually using 6to4 for production purposes I guarantee that you will like tunnels better. So your replacement is ready-made for you. >> You're asserting that tunnels cannot do things that you think we should >> be able to do, making sure that a) you're correct, and b) those things >> are worth the cost should be a precursor to any discussion on new work. >> >> For example, in response to Jeroen you asserted that tunnels don't allow >> reverse DNS. > > The IPv6-in-IPv4 tunnel does not (I didnt mean IPv6-in-IPv6 tunnel not > to allow reverse dns - I think it does). > > >> At least for HE, that assertion is demonstrably false. > > Yes. I'm not sure you are understanding me here. I have an HE 6in4 tunnel, I can easily get reverse DNS for it if I want to. (I don't, but I can.) > Ah no, please, dont plan on renumbering. I dont even have software to > renumber all these devices and all these radvd.conf files... > > I can give up my 6to4 address space, but just once. I dont want to do > it again in 2 years or so. (I already did it once in the past, its > painful). > > (now I am a particular case and people could discuss theirs, if any). I'm sorry to say, renumbering is a fact of life. I'm not trying to be insensitive to your pain here, but it sounds like you're asking us to delay a major improvement to the IPv6 spec for your organization's convenience. Doug From nobody Thu Nov 13 14:58:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E731AE15F for ; Thu, 13 Nov 2014 14:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6SquTsB1bzD for ; Thu, 13 Nov 2014 14:58:18 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165661AE15D for ; Thu, 13 Nov 2014 14:58:18 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 7A31D10063F59; Thu, 13 Nov 2014 22:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415919495; bh=30pVRADDSdZZDtcKwE7NDrFPnqUjX6ezg26D+CWvtQM=; h=Date:From:To:Subject:References:In-Reply-To; b=qnVkK7StpCqjm8yJ56EZhjmxgR71fFKrVeFZ53zv5K3o75+gTSziIm3tTEaJOS+LI uGC9E8NxPDEa3INanBNUZmznc8XfkNHh0glzGWZCZk9Mb9mT2WNmruIs66AN2smqTh KcoOEIm1R6BzsCrGJJlzIHeoJhrnETYN/9IwpSrzSEZt31KKB/T4ZOnr51pclh8IvK ktJ4DjFgAIYr7Vm6l3zMq1gVoBlvmMTIbp87RwycUnyEr8CdHnxI+mjRMM6chF3CAp CbT88T6/9ABESDyA50y9+xTelHhwg20OlhsqXw9nMAWMeCxfNSxpts9PmsQBtF+doN GoBHq1NCPESKg== Message-ID: <54653785.4040909@massar.ch> Date: Thu, 13 Nov 2014 23:58:13 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> <5465300C.8050206@gmail.com> <54653309.6010407@dougbarton.us> <5465354D.5070002@gmail.com> In-Reply-To: <5465354D.5070002@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CFQebD9G1xxMufJBkFaVVPc6UIs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 22:58:21 -0000 On 2014-11-13 23:48, Alexandru Petrescu wrote: [..] >>> Requirements or goals whatever one calls them, should be agreed before >>> embarking on new work. >> >> But you're begging the question on the new work in the first place. :) > > I am begging to give a replacement before deprecating. If you dont > deprecate and if vendor fixes bugs then one is fine (except reverse DNS, > and _any_cast trust matters). You'll have to come up with plausible requirements though. The ones you are giving are satisfied by various means that are able to provide you with proper connectivity for well over 10 years already. >> You're asserting that tunnels cannot do things that you think we should >> be able to do, making sure that a) you're correct, and b) those things >> are worth the cost should be a precursor to any discussion on new work. >> >> For example, in response to Jeroen you asserted that tunnels don't allow >> reverse DNS. > > The IPv6-in-IPv4 tunnel does not (I didnt mean IPv6-in-IPv6 tunnel not > to allow reverse dns - I think it does). The protocol used is irrelevant to the ability to assign reverse DNS. Unless you are talking about Teredo where it is just too troublesome to do so. Please see: https://www.sixxs.net/faq/connectivity/?faq=comparison for a list of pro/cons for each protocol. There is also a 'reverse DNS' column there. All of the protocols have "optional" reverse as it depends on the provider providing it. >> At least for HE, that assertion is demonstrably false. > > Yes. Check: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers for a nice feature comparison. >>> What do you think the goals would be? >>> >>> For example, the current tunnel brokers are very good but (1) are not >>> trustful, (2) force into later efforts to renumber when going native, >>> (3) require filling in forms. 6to4 has the advantage of not >>> requiring 3. >> >> ... and yet I would assert that unless we're talking about something >> that is provider managed (such as 6rd) then automatically enabling it >> for the user is a bad idea. It will create more problems than it solves, >> and cause a lot of support calls, which ISPs are not going to like. >> >> I'm also pretty sure that to the extent I understand it, your point >> about renumbering is also invalid. > > Ah no, please, dont plan on renumbering. I dont even have software to > renumber all these devices and all these radvd.conf files... > > I can give up my 6to4 address space, but just once. I dont want to do > it again in 2 years or so. (I already did it once in the past, its > painful). > > (now I am a particular case and people could discuss theirs, if any). Automating the generation & distribution of those configs helps a lot. Also, you could have requested a prefix from the three bigger Tunnel Brokers who have been operating for well over 10 years and you could have had a static prefix for all that time already... Greets, Jeroen From nobody Thu Nov 13 15:00:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364DA1AE183 for ; Thu, 13 Nov 2014 15:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs2pGyxIu4qk for ; Thu, 13 Nov 2014 15:00:48 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748AD1AE189 for ; Thu, 13 Nov 2014 15:00:48 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id F0D0C10063F59; Thu, 13 Nov 2014 23:00:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415919646; bh=1NSmaCVbehbe9HgYYAiu8J1ib80FDLAtLE0G01ammg0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=rsC1EmM8XrZ1lF63kHLpmReg1Mni1I4kDk0fqi5sWPZZaq3oCkkjKE9B1Xtvf7b34 MFC47dEpc6QDG2EZNTWOlssGH8qFsJge/cOlarv0w0c658Vg7msqH4/zebkK6DHcDG eUUMnguI/8J5N9iqE+HjHrHxgcXRNugW+dupytEkKoJ4svAznM7T2VtRMHHR97pfzK bK0im7VXubzvg+rQIjz8Twg8chPEaPEW6Q6TMoBLH9IJCCUODIYB1E83S8BQDdUA0L xTUvA8zSY2ZyjVVbq86T6+we7BP4hw3gg+6SIYioeQVa9dY+UsOyA0XVXccU2Enfed XGIn6mZ9tGUhg== Message-ID: <5465381B.5080906@massar.ch> Date: Fri, 14 Nov 2014 00:00:43 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sKIUeb41B2O1b01wKNuXiRDpp-4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:00:50 -0000 On 2014-11-13 23:52, Templin, Fred L wrote: > Hi, > >> Goal - any new replacement of 6to4 must be future proof: avoid >> renumbering when 6to4-replacement dies out. (this is what current >> tunnel brokers dont offer, they force one into a lockin going away from >> tunnel broker to native IPv6 one has renumber). > > To amplify this point, tunnels are for more than just IPv6 transition. They are > useful also for: > > - mobility management > - routing control > - security (e.g., VPN) > - multihoming > - traffic engineering > - renumbering avoidance > - etc. > > You get all of this (plus v6/v4 transition, of course) with AERO. Indeed, > AERO can be a one-stop-shopping solution for any tunnel application. AYIYA handles those fine too. Tested and in use by over 20k people, available from quite a number of CPEs too ;) OpenVPN works perfectly fine for probably millions of people. Don't call those things "tunnels" though, just name them by their commercial name: VPNs. Greets, Jeroen From nobody Thu Nov 13 15:03:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8BC1AE1AE for ; Thu, 13 Nov 2014 15:03:26 -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 y43FBh3GNJUq for ; Thu, 13 Nov 2014 15:03:24 -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 7F0311AE1A8 for ; Thu, 13 Nov 2014 15:03:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADN3J16019413; Fri, 14 Nov 2014 00:03:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E664020473E; Fri, 14 Nov 2014 00:03:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D8C1B203F87; Fri, 14 Nov 2014 00:03:39 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADN3B9u019617; Fri, 14 Nov 2014 00:03:18 +0100 Message-ID: <546538AF.1050101@gmail.com> Date: Fri, 14 Nov 2014 00:03:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546534B0.90300@massar.ch> In-Reply-To: <546534B0.90300@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1STXzmqEgCnS6Z0poUqPm66ChH0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:03:26 -0000 Le 13/11/2014 23:46, Jeroen Massar a écrit : > [Replies to multiple mails in this thread compressed into one] > > On 2014-11-13 23:17, Alexandru Petrescu wrote: [..] >>>> Do not deprecate until you offer a solution satisfying a >>>> number of requirements (currently unsatisfied by eg tunnel >>>> brokers). >>> >>> Which requirements are these? >> >> Ones one would have to lay down and agree on before engaging in >> new work. >> >> For example -1- must allow for reverse DNS ok, > > That is a business decision. Most (all?) TBs provide this. > > Note that a normal ISP does not do this, hence bit silly to require > it for a free tunnel... Home ISP may not do it, but business ISP does. >> -2- must be secureable by existing e2e IPsec, > > The tunnel or the packets that flow within it? What is the problem > you are trying to solve? I need to trust enough the other endpoint, not send something in the wild. > The packets in the tunnel are 1280+ hence, go IPSec away as much as > you want. > > For securing the tunnel it would require distributing keying > material. > > As IPsec is horrible to configure and does not work through NATs > happily (yes, you can patch crap) nobody ever bothered with this. > > For AYIYA packets are signed btw, hence, no spoofing of those. There > is no crypto though there either. The questions I have about these are numerous but mostly administrative as such are hard to formulate here in a public forum. It has to do with what kind of business is it, etc. > >> -3- to the extent of possible be easy to set up for Clients > > TSP (gogoclient) and TIC (AICCU) solve that problem. CPEs incorporate > these tools or have their own implementations (eg Fritz!Box). > > How much 'easier' do you want it? Easy in the sense of as easy as opening a Google account. >> and not involve intervention of another party (like when >> requesting an IPv6 address from an administrator, delayed paper >> forms, etc). > > Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse. For example, do they spy on you? > Other Tunnel Brokers and Gogo TSP in "authenticated" mode require > that one signs up, just as you would with a IPv4 ISP. For example, what kind of private data should I share with them? > This is a "business" decision though. Nothing a technical thing can > solve. There is no such aspect in 6to4... >> From another mail: > >> For example, the current tunnel brokers are very good but (1) are >> not trustful, > > What do you mean with "trustful"? HArd to say, who do _you_ trust? Trustful in the sense of accountable. I dont want them to spy my traffic, at least. I want them to anwser questions when asked. >> (2) force into later efforts to renumber when going native, > > Changing ISPs typically require that. Whereas we can require the destinationISP to set up routing such that I keep the same prefix I got from the first. Or update other databases. > Only way to avoid that is to get your own PI space. Another administrative effort? > At that point you will be able to arrange your own connectivity too > though. Only to those ISPs who accept it? >> (3) require filling in forms. 6to4 has the advantage of not >> requiring 3. > > And 6to4 is unreliable as no ISP can 100% support it. Its mostly a matter of 6to4 Relays uptime and IP routing finding right paths. Up to now I didnt experience 6to4 Relay not responding. > With Tunnel Brokers you are signing up for a service. Signing up > requires forms. Are the Tunnel Brokers ready to fill in forms that I request conceive? > Though those forms are there primarily to limit abuse too and to > enable contacting people when they problems with their tunnel so > that it can be resolved. What about the potential abuse from the Tunnel Brokers? > And another mail: >> 6to4 is not alowing for reverse DNS either, if I am not terribly >> wrong. > > https://6to4.nro.net Thanks, I didnt know that. Does it require filling in forms for each IP address? I am easier at vi-ing a config file in my local DNS and then DNS takes care of rest. > But even then you still do not want 6to4 as it is unreliable ;) :-) Alex > > Doug Barton wrote: >> ... and yet I would assert that unless we're talking about >> something that is provider managed (such as 6rd) then automatically >> enabling it for the user is a bad idea. It will create more >> problems than it solves, and cause a lot of support calls, which >> ISPs are not > going to like. > > Exactly. > > Greets, Jeroen > > > From nobody Thu Nov 13 15:07:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EE1AE1FE for ; Thu, 13 Nov 2014 15:07:56 -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 YmFlM7NLFIyh for ; Thu, 13 Nov 2014 15:07:54 -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 8F6DF1AE205 for ; Thu, 13 Nov 2014 15:07:54 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sADN7r6b020186; Fri, 14 Nov 2014 00:07:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4F8DD2048B1; Fri, 14 Nov 2014 00:08:13 +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 42FA92046F4; Fri, 14 Nov 2014 00:08:13 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.11]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADN7oFi021426; Fri, 14 Nov 2014 00:07:52 +0100 Message-ID: <546539C5.8050104@gmail.com> Date: Fri, 14 Nov 2014 00:07:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <54653620.7050809@massar.ch> In-Reply-To: <54653620.7050809@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1gyGZfpADtdEJ98HhumJFiomWEI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:07:56 -0000 Jeroen - you make up a few pretty good questions, I am happy. If I dont keep up sorry. Le 13/11/2014 23:52, Jeroen Massar a écrit : > On 2014-11-13 23:22, Alexandru Petrescu wrote: > [..] >> Goal - any new replacement of 6to4 must be future proof: avoid >> renumbering when 6to4-replacement dies out. (this is what current >> tunnel brokers dont offer, they force one into a lockin going away from >> tunnel broker to native IPv6 one has renumber). > > Please solve this problem for native IPv6, provided by an ISP, first. > > Then we can apply the same for Tunnel Brokers... > > Just in case you wonder: for the time being it is called PI. > > Most Tunnel Brokers give out static prefixes btw; I have had some > already for well over 10 years... > > On 2014-11-13 23:41, Alexandru Petrescu wrote: >> Le 13/11/2014 23:31, Iljitsch van Beijnum a écrit : >>> On 13 Nov 2014, at 12:22, Alexandru Petrescu >>> wrote: >>> >>>> Goal - any new replacement of 6to4 must be future proof: avoid >>>> renumbering when 6to4-replacement dies out. (this is what current >>>> tunnel brokers dont offer, they force one into a lockin going away >>>> from tunnel broker to native IPv6 one has renumber). >>> >>> Are you saying that you want to be able to move from a tunnel to >>> native without renumbering? >> >> Yes. My situation currently is that my network is on 6to4, >> it seems to get discarded, > > What gets "discarded"? deprecated 6to4 seems to become by meeting discussion. > >> and the trustful ISP is not _yet_ offering native. > > What do you mean with "the trustful ISP"? An ISP that has same upper organization that my organization. In private you pointed me to it, you know what I mean. > >>> I don't think that's even a minor goal; renumbering is not a big deal >>> in a home environment. >> >> Depends on the size of the home environment. Considering the >> operators currently owning 2 devices but announcing to put and >> control much more devices in your home for IoT apps, one thinks >> avoiding renumbering could only be beneficial. > > I have a rather extensive home network. Renumbering though means I > change the prefix in my config file, and then let my scripts spit out > new DNS, new firewall settings etc and push that to the relevant boxes. Well by renumbering I mean the Renumbering RFC which uses a form of Router Advertisement propagation. You have scripts - great, I am happy for you. > > > Renumbering is easy for the portions that are in your own control (yeah, > for total control of all that is involved). > > Renumbering is extremely hard when you need to tell other entities what > the new settings are. > > Oh, and no, I don't want to renumber my network, I love my static prefix. :-) Alex > > Greets, > Jeroen > > > From nobody Thu Nov 13 15:11:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01C1ACD09 for ; Thu, 13 Nov 2014 15:11:53 -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 RxnkwvqjF5JK for ; Thu, 13 Nov 2014 15:11:52 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08F61ACFC2 for ; Thu, 13 Nov 2014 15:11:38 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id n3so1139141wiv.2 for ; Thu, 13 Nov 2014 15:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z5apqW+WJivZfj1DvBJ5Ip6na33S5AAeLh/8nWnk4N8=; b=n1+kqdntZ4c5FCFQD1GB26XpmhSv80mjt9VOOcfPnGaXwB5WaIJIB+CP6jiK7ecBKv +4ugfxvlkTsbpfOAMYedduaWZz6kIm4xyXhxvuDBS4Nq9JgAJNxJWeISJSoqo7sReMIQ a01/dWQotJd6xP5mIZGuQ4llbUY8B1O0P64l0CXt3owNa6TSLZXZ6GZQYQCghYZF2lLq mdQUQ3mnsNAbCx943hX/oSREfCNEyPQAQfsBB7Cm0pWtVEVhR0tF2uUyPXYZaQ7b/odY YXaV6D255zf6U6jgHChs7VrwfWJmw7VF06d0sUdF6Y8Bo+BTQVwPTdtItEOnBsC+A/6R 1uxg== X-Received: by 10.194.237.162 with SMTP id vd2mr8420126wjc.52.1415920297722; Thu, 13 Nov 2014 15:11:37 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id gy4sm1141839wib.11.2014.11.13.15.11.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 15:11:37 -0800 (PST) Message-ID: <54653AB0.1020903@gmail.com> Date: Fri, 14 Nov 2014 12:11:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> In-Reply-To: <5463C716.1030805@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2L59Z7L7BIolxDdkjVjUBheH4o8 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 23:11:53 -0000 On one specific point: > So how about replacing; > > Internet service providers SHOULD filter out routes to 192.88.99.1. > > With; > > All networks, but in particular Internet service providers, SHOULD > filter routes for 192.88.99.1 or the prefix 192.88.99.0/24, yet they > SHOULD NOT filter traffic sourced from or destine to 192.88.99.1. That doesn't quite work for me. Firstly, an edge network that chooses (despite our advice) to use 6to4 shouldn't filter it, so I think it really is a recommendation to ISPs. Secondly, if you're filtering the route, you will drop packets TO 192.88.99.1 by definition. (I also think that mentioning the /24 prefix is redundant.) So my edit buffer now reads: Internet service providers SHOULD filter out routes to 192.88.99.1. However, networks SHOULD NOT filter out packets whose source address is 192.88.99.1, because this is normal 6to4 traffic from a 6to4 return relay somewhere in the Internet. Brian From nobody Thu Nov 13 15:29:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5681AE214 for ; Thu, 13 Nov 2014 15:29: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 CxSm_q_MY7dN for ; Thu, 13 Nov 2014 15:29:31 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEA81AD482 for ; Thu, 13 Nov 2014 15:29:30 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so1141967wiv.10 for ; Thu, 13 Nov 2014 15:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C9ouGQpXETAch8ewSlbGsWvUSrmZADSiS9jxh1sV63g=; b=Rc5wWBT+HL2bgDPcfH6ZgfX6luWFgcBFsz9GG0hW7dZdGYT6DlMBPHH6pWPgrFK/KU nvR5KpARLPmAGhyXo4JPLihHks/kw0sAMgVXTGCIeUNaIl7uaZC9T/bDXO45EDR/XAnV Q3w9/y5i9N+xU+PUJaj+rC3eiDc6NXr87WAQYRkVrUGmQU2ReUBTlM1MFKhXaL11t/hb KVzLD/VExDy5FBmTmvfTjCtaewrPcBHsJvo1yv88fUrsKN6n8aPOzNDhly+QcqjLe9u9 be4yQe3IKU5WcxsT7pABwUhIRrGjeMpJ0cFMer1mHEwUFieebuXXL590xhkRi1o/CwOR Xr0A== X-Received: by 10.194.81.70 with SMTP id y6mr7898055wjx.113.1415921369765; Thu, 13 Nov 2014 15:29:29 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id gy4sm1185077wib.11.2014.11.13.15.29.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 15:29:29 -0800 (PST) Message-ID: <54653EE1.1050905@gmail.com> Date: Fri, 14 Nov 2014 12:29:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546531AF.6@gmail.com> <546533D7.9080507@gmail.com> In-Reply-To: <546533D7.9080507@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LDSn3EvrSq1EEjcZsMApxjWGYsg Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:29:32 -0000 > 6to4 is not alowing for reverse DNS either, if I am not terribly wrong. RFC 5158 "6to4 Reverse DNS Delegation Specification" Regards Brian From nobody Thu Nov 13 15:31:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F6E1AE2B1 for ; Thu, 13 Nov 2014 15:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 BAWjdaBLdGGU for ; Thu, 13 Nov 2014 15:31:06 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD511AE19C for ; Thu, 13 Nov 2014 15:31:06 -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 sADNV6s7007983; Thu, 13 Nov 2014 15:31:06 -0800 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sADNV32I007939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Nov 2014 15:31:03 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.76]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 15:31:03 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/5SRBJqwQ4D6aUGjUUXr5CsnMJxfskCA//+AYCA= Date: Thu, 13 Nov 2014 23:31:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D862F5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> <5465381B.5080906@massar.ch> In-Reply-To: <5465381B.5080906@massar.ch> 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: http://mailarchive.ietf.org/arch/msg/v6ops/lQYm3QTYGIdCoqUAOT4mwv6GV4Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:31:07 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Thursday, November 13, 2014 3:01 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? >=20 > On 2014-11-13 23:52, Templin, Fred L wrote: > > Hi, > > > >> Goal - any new replacement of 6to4 must be future proof: avoid > >> renumbering when 6to4-replacement dies out. (this is what current > >> tunnel brokers dont offer, they force one into a lockin going away fro= m > >> tunnel broker to native IPv6 one has renumber). > > > > To amplify this point, tunnels are for more than just IPv6 transition. = They are > > useful also for: > > > > - mobility management > > - routing control > > - security (e.g., VPN) > > - multihoming > > - traffic engineering > > - renumbering avoidance > > - etc. > > > > You get all of this (plus v6/v4 transition, of course) with AERO. Indee= d, > > AERO can be a one-stop-shopping solution for any tunnel application. >=20 > AYIYA handles those fine too. Tested and in use by over 20k people, > available from quite a number of CPEs too ;) I forgot to mention also: - route optimization - distributed mobility management With AERO, there can be many 100's of Servers, and the Clients get the same service no matter which Server(s) they associate with. The Server-to-Client associations are communicated to Relays which connect the AERO link to the rest of the IPv6 Internet. Server association is through DHCPv6 PD messagin= g, and Route optimization is through IPv6 ND messaging the same as for any lin= k. > OpenVPN works perfectly fine for probably millions of people. OpenVPN is indeed the target integration platform for the AERO Client. Only, it is used whether or not the tunnel also applies IPsec - it would also be used for simple IPv4/UDP/IPv6 encapsulation. > Don't call those things "tunnels" though, just name them by their > commercial name: VPNs. Tunnels are VPNs and VPNs are tunnels, sure, but I don't see a reason for making such a distinction for the purpose of this discussion. Thanks - Fred fred.l.templin@boeing.com >=20 > Greets, > Jeroen From nobody Thu Nov 13 15:33:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02471AE2CF for ; Thu, 13 Nov 2014 15:33:15 -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 CUd150M0esS2 for ; Thu, 13 Nov 2014 15:33:14 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3257B1AE2BE for ; Thu, 13 Nov 2014 15:33:14 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so1148081wiv.10 for ; Thu, 13 Nov 2014 15:33:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P0Q+DZHA7C6GhoFfp+dM2LkXZ0RB9Hn41opH4Vleewg=; b=GhVqVKfUXnWuCX+Nr3ig/MtNHs/sE1CV1Epy4/6FAsnRvkszJFeNJ6/NhRCoeP6edg Uy+64xgwMZqLDg1d56qRm0tWeixinsdrabmaTEwmVIly+7+UWbvTgojfNiepv2m86sjy 7svV0HKeUriW9BVXKnBoWaQ+u/y/iZ9A72OPYRi1vnxf2ann/f8f9nALP26bE91w0AEL CCStGs90jlRhBkfS/V6N3fnjltomQZMQqyQUFdY/fPeg4MjIEQ4GLF2Ih2tn0CQ1GL4F AHaaSLJlwwjiDqFN5kBwuNw1nZg1MRpt10vJBvjc1vN7xVmaea5efjh8xijwBnf63FLA ajzw== X-Gm-Message-State: ALoCoQkZWAne4VH8Gf6oHjKeFmgMu85vROswq06ZASBlNjMI4ckxAdBmOc6R1kzvUtPoekdgesTJ X-Received: by 10.180.72.33 with SMTP id a1mr2522528wiv.18.1415921593017; Thu, 13 Nov 2014 15:33:13 -0800 (PST) Received: from dhcp-a0ea.meeting.ietf.org (t2001067c037001602482883c433d5907.wireless.v6.meeting.ietf.org. [2001:67c:370:160:2482:883c:433d:5907]) by mx.google.com with ESMTPSA id ne10sm1162480wic.23.2014.11.13.15.33.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 15:33:12 -0800 (PST) Message-ID: <54653FB5.6010402@jvknet.com> Date: Thu, 13 Nov 2014 13:33:09 -1000 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54653AB0.1020903@gmail.com> In-Reply-To: <54653AB0.1020903@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZvGjT8JmY8gKbqYX2bVIxKDEfQM Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 23:33:16 -0000 v6OPS WG, A natural association to deprecating RFC3068 and the removal of routing the 192.88.99.0/24 prefix will be the cessation of RFC6732 operation where it's enabled/implemented. This is expected and a good thing. Not sure if this should be mentioned specifically in the draft or not. regards, Victor K From nobody Thu Nov 13 15:34:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62211AE2D3 for ; Thu, 13 Nov 2014 15:34:31 -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 imI9Rd_dfzAh for ; Thu, 13 Nov 2014 15:34:30 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B371AE2C9 for ; Thu, 13 Nov 2014 15:34:30 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so2535730wgh.0 for ; Thu, 13 Nov 2014 15:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iyyceshvIm+El0cBl/7WPXjF6Q+wuTrU1TGzTyK7fKc=; b=W2zmtiWIApYJC/bvjYC/z04u90yEosIBmsFdorWTUfduiIqoBTz1SF/UBo0d6QiuqG zLMtHAxx0OXKN1SUQQwsfPr9HQ5mYTBGosZ/aL0EvwDObUZhzhjGZsJcbXhr2t/Gy/tF mDOzDVe5vFAX8QuvSpVOE/yL+Ff2TOMoZIMnP0qoNPSRXDNJv6AdwO028OCvYjorWCi1 lGBeLxvzM6rs0iKwtjpRWNSI8zFRY9rqAySs6h4kWk4zi1bQVEIIkkEhW8UEehm5Ovvx ERVn/G4UMwWViROxdXOUmzIVTmE5y0lHT8+9MmbqswVLiq0HMA9f2Hezx9VdiJifMWwQ TPpg== X-Received: by 10.180.88.162 with SMTP id bh2mr2317877wib.77.1415921669299; Thu, 13 Nov 2014 15:34:29 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id pf4sm26315582wjb.36.2014.11.13.15.34.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 15:34:28 -0800 (PST) Message-ID: <5465400C.1050406@gmail.com> Date: Fri, 14 Nov 2014 12:34:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546534B0.90300@massar.ch> <546538AF.1050101@gmail.com> In-Reply-To: <546538AF.1050101@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sReTeQXBbKinBhNSnTaVE5kDkoI Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:34:32 -0000 On 14/11/2014 12:03, Alexandru Petrescu wrote: ... >> And 6to4 is unreliable as no ISP can 100% support it. > > Its mostly a matter of 6to4 Relays uptime and IP routing finding right > paths. Up to now I didnt experience 6to4 Relay not responding. You have been amazingly lucky then. During the brief period that I ate this particular version of my own dog food, I had very intermittent success (both black holes and unfixable MTU/MSS issues). Brian From nobody Thu Nov 13 15:34:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3B1AE2D7 for ; Thu, 13 Nov 2014 15:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.99 X-Spam-Level: X-Spam-Status: No, score=-3.99 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, T_FILL_THIS_FORM_SHORT=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 7ZDpoPCuacBk for ; Thu, 13 Nov 2014 15:34:40 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B4D1AE2D5 for ; Thu, 13 Nov 2014 15:34:40 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 2002410063F5C; Thu, 13 Nov 2014 23:34:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415921677; bh=k5dKGmIYlcgg042mBo94XtE0GYRoSpJBCVimJ/kl4d8=; h=Date:From:To:Subject:References:In-Reply-To; b=ymlp94slnwMhUVGzSf9YbtCcumPaf66KfQPcOSqvj7wok+8D3qH8jDHVClIZm1b7o P1gbpOq5ntLsIYUXxiqH9cPA/Pm6X9tCO9FY4MrHrMSFCuHucG/WAZKxxp8sQ6g3aT Ec9rTBX6CnpzbDaZhc97jhgjk/7sZhKvw9m/z+G6iAZwUMJJPwRibrJJNkgOrZdXrm lTD71TPmKNSt85KGG685EP0qCYWTlHpTVIZ2UM5WPhLilm6S5/JR/tQKomv0bhZQAk H1eQR41uYJsAcjzCGQvplKlXJmZKVP55Khb3aAn/HJvAZMAwYQob0HY8z4T+oaTx1h Gay4Juw3Gkt7Q== Message-ID: <5465400B.4050103@massar.ch> Date: Fri, 14 Nov 2014 00:34:35 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546534B0.90300@massar.ch> <546538AF.1050101@gmail.com> In-Reply-To: <546538AF.1050101@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sJsFIYMXcdXenDidnXpY2dZa7DQ Subject: [v6ops] Missing features of Tunnel Brokers (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2014 23:34:43 -0000 Setting Subject so that people know that this is clearly not about the draft anymore and that subject can then be closed. On 2014-11-14 00:03, Alexandru Petrescu wrote: > Le 13/11/2014 23:46, Jeroen Massar a écrit : >> [Replies to multiple mails in this thread compressed into one] >> >> On 2014-11-13 23:17, Alexandru Petrescu wrote: [..] >>>>> Do not deprecate until you offer a solution satisfying a >>>>> number of requirements (currently unsatisfied by eg tunnel >>>>> brokers). >>>> >>>> Which requirements are these? >>> >>> Ones one would have to lay down and agree on before engaging in >>> new work. >>> >>> For example -1- must allow for reverse DNS ok, >> >> That is a business decision. Most (all?) TBs provide this. >> >> Note that a normal ISP does not do this, hence bit silly to require >> it for a free tunnel... > > Home ISP may not do it, but business ISP does. Then consider Tunnel Brokers Business ISPs :) >>> -2- must be secureable by existing e2e IPsec, >> >> The tunnel or the packets that flow within it? What is the problem >> you are trying to solve? > > I need to trust enough the other endpoint, not send something in the wild. The whole point of the Tunnel Broker model is that there is a fixed IP and thus likely a stable path to send packets to and get them back from... >> The packets in the tunnel are 1280+ hence, go IPSec away as much as >> you want. >> >> For securing the tunnel it would require distributing keying >> material. >> >> As IPsec is horrible to configure and does not work through NATs >> happily (yes, you can patch crap) nobody ever bothered with this. >> >> For AYIYA packets are signed btw, hence, no spoofing of those. There >> is no crypto though there either. > > The questions I have about these are numerous but mostly administrative > as such are hard to formulate here in a public forum. It has to do with > what kind of business is it, etc. info@sixxs.net or ipv6@he.net are there to answer such questions ;) >>> -3- to the extent of possible be easy to set up for Clients >> >> TSP (gogoclient) and TIC (AICCU) solve that problem. CPEs incorporate >> these tools or have their own implementations (eg Fritz!Box). >> >> How much 'easier' do you want it? > > Easy in the sense of as easy as opening a Google account. I am not sure about HE, but for SixXS you don't have to fill in some extremely unreadable recaptcha thing. Hence that makes it for those EASIER than opening a Google account. >>> and not involve intervention of another party (like when >>> requesting an IPv6 address from an administrator, delayed paper >>> forms, etc). >> >> Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse. > > For example, do they spy on you? You might want to define "spy". You will never know what the three letter agencies of the world do with data flowing around the world. My advise always: use SSL, or develop your own crypto and stuff packets in that. A tunnel does not restrict you from any of that. >> Other Tunnel Brokers and Gogo TSP in "authenticated" mode require >> that one signs up, just as you would with a IPv4 ISP. > > For example, what kind of private data should I share with them? At most the same as you would signup to a normal ISP: Your valid contact details (name, address, phone) At minimum a random username. >> This is a "business" decision though. Nothing a technical thing can >> solve. > > There is no such aspect in 6to4... Yes there is. As the providers running the relays can and will shut them down. That would also be a business decision. History has shown that this already happened when Hetzner allowed a customer of theirs to send spoofed 6to4 packets (src-ipv4 their IP, dst-ipv4 the 6to4-anycast-addr, src-IPv6 spoofed, dst-IPv6 some target). That caused quite a few 6to4 relays to shut them down as they did not want to carry that crap traffic. >>> From another mail: >> >>> For example, the current tunnel brokers are very good but (1) are >>> not trustful, >> >> What do you mean with "trustful"? > > HArd to say, who do _you_ trust? Nobody? :) > Trustful in the sense of accountable. I dont want them to spy my > traffic, at least. I want them to anwser questions when asked. You will never know if somebody is snooping along with your data. I can state though that SixXS does not peek along, unless we need to debug or there is some weird traffic pattern etc. I have no idea if the ISP providing the PoP peeks, or if some national agency is doing so though on the fiber level or just tapping away. As you love 6to4: as your packets go to an anycast you don't even know which path they will take the next moment... note that the 'anycast' is in four directions: IPv4 you->6to4-anycast, IPv6 6to4-anycast -> dest, IPv6 dest -> 6to4-anycast (could be different from original), IPv4 6to4->anycast to you. Hence, on the return path you won't even see it anyway... If you are paranoid about this: use Tor. Though that might not solve those problems either. There are lots of VPN providers you can pay for a service that might help you though. This will never be something that anybody will vouch for though. (At least, I cannot vouch for it because I don't control all the factors) >>> (2) force into later efforts to renumber when going native, >> >> Changing ISPs typically require that. > > Whereas we can require the destinationISP to set up routing such that I > keep the same prefix I got from the first. Or update other databases. That does not scale. Please check the GROW WG for more details. >> Only way to avoid that is to get your own PI space. > > Another administrative effort? Only once. It seems you want for free what lots of people just do... >> At that point you will be able to arrange your own connectivity too >> though. > > Only to those ISPs who accept it? Everybody you pay transit (or buy a crate of beer & a sack of onions ;) These are not technical requirements, but business (read: money/policy) problems. >>> (3) require filling in forms. 6to4 has the advantage of not >>> requiring 3. >> >> And 6to4 is unreliable as no ISP can 100% support it. > > Its mostly a matter of 6to4 Relays uptime and IP routing finding right > paths. Up to now I didnt experience 6to4 Relay not responding. Then you where lucky. >> With Tunnel Brokers you are signing up for a service. Signing up >> requires forms. > > Are the Tunnel Brokers ready to fill in forms that I request conceive? I really do not understand that sentence, please rephrase. >> Though those forms are there primarily to limit abuse too and to >> enable contacting people when they problems with their tunnel so >> that it can be resolved. > > What about the potential abuse from the Tunnel Brokers? What kind of abuse would the Tunnel Broker cause? Unless you mean the users. That is simple: depending on the problem report to authorities and the IPv4 ISP, or just close their account. >> And another mail: >>> 6to4 is not alowing for reverse DNS either, if I am not terribly >>> wrong. >> >> https://6to4.nro.net > > Thanks, I didnt know that. "There is a RFC for that": http://www.ietf.org/rfc/rfc5158.txt > Does it require filling in forms for each IP address? I am easier at > vi-ing a config file in my local DNS and then DNS takes care of rest. Afaik it goes per /48. Hence once per IPv4 address you'll have to fill something in. I have never bothered with 6to4 as configured tunnels simply work and do not have any unreliable properties. Oh another trip own memory lane: in something like 1997 I had a address our of 5f04:b000::/32 (rfc1897) thank you Surfnet (Wim Biemolt in particular) for that tunnel. Thus no, I did not always control the tunnel :) Greets, Jeroen From nobody Thu Nov 13 15:47:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB51AE2F6; Thu, 13 Nov 2014 15:47:30 -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 e-m0LWxo8mh1; Thu, 13 Nov 2014 15:47:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B531C1AE323; Thu, 13 Nov 2014 15:47:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113234728.4466.1690.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 15:47:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2RRpeuW4kxBgOqv97A5nEqA_M7U Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:47:30 -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 : Deprecating Anycast Prefix for 6to4 Relay Routers Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-08.txt Pages : 7 Date : 2014-11-13 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that the mechanism is unsuitable for widespread deployment and use in the Internet, especially in its anycast mode. This document requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. Thus it updates the guidelines in RFC 6343. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-08 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 13 15:52:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C855D1AE341 for ; Thu, 13 Nov 2014 15:52: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 3SNLKsaNkGaL for ; Thu, 13 Nov 2014 15:52:41 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276EC1AE33C for ; Thu, 13 Nov 2014 15:52:41 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so2549703wgh.14 for ; Thu, 13 Nov 2014 15:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pIquU7dkqahQ7OibWZuQySa8/JaZttEkGwRYFYDC1N8=; b=Q50oJSnRXSn83kZL+21SU+lyZZq/O7T2MDFhx9IheSOFfmzpTGcela17RQQHOKN3F9 U4uE7KoK/nhb4X31kzhsBxDtPAZs6o6zTMyldIOz+7I60Q4iVgnPs5iEl2LPmS/0rzVv TxJShrnpj0sHFXX0K8UB86tXzLgJIdkH7VrL4Q6tTK9RpCNrVeJT30BEVMLMvP8cXZqB az6E2ycVGUgGD+rgYgZiWxKtwzNnoFTfJRv/etPseX6RS0heq85tRWb8INzLj6uewK8t KIxEj91d+FOqvdA0HeIMwsUHG0SyeN1/+lXD5X4QuMaL0aIOCq3i4fhf5ve/c5NVj6Kz sNSw== X-Received: by 10.194.239.164 with SMTP id vt4mr8396015wjc.131.1415922759706; Thu, 13 Nov 2014 15:52:39 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id da3sm37442833wjb.12.2014.11.13.15.52.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 15:52:39 -0800 (PST) Message-ID: <5465444F.4050209@gmail.com> Date: Fri, 14 Nov 2014 12:52:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20141113234728.4466.1690.idtracker@ietfa.amsl.com> In-Reply-To: <20141113234728.4466.1690.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eQ3rmaZp6B6woUEuYwvcDNZbbm4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-08.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, 13 Nov 2014 23:52:43 -0000 OK, this is a quick update to include the changes I had in my edit buffer - they reflect the last couple of days' comments on the text. Two points: 1. I failed to consult Ole about this update, so he is entitled to raise objections. 2. I didn't intentionally change the main recommendations in any way. Of course, they are still open for debate when the WGLC starts in a day or two. Brian From nobody Thu Nov 13 15:54:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6C1AE345 for ; Thu, 13 Nov 2014 15:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG-2yCNn5Clr for ; Thu, 13 Nov 2014 15:54:29 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3457D1AE33C for ; Thu, 13 Nov 2014 15:54:29 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id la4so4425934vcb.33 for ; Thu, 13 Nov 2014 15:54:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MCeu95vH/fuZW+1mfa+W24dwly6fgLpAhv/JJP+krj4=; b=jiCwhCMIyQezDqfNH8PMLXAGGkzpQxWJZa23Mgr+rJLUba2PEK/ZCOTuSD5Zty7Dif zIQyRspHU6qwWN0P5DP+xepD5WeAV/0bzWr9RWIOmaqtbg+7j/w8/+eVS4Z5irXC+mWZ YPi39CUmaLZXY1u0fuaTT5GL6oPGUwsk5qkCKMzrbKazuzBYOiiHwAun5y8D3OTlkAFL XKlVUNqQumetAbh5AFBWpT4WN7I4ICezWVSBj4p5lE7dKTBknES+0SP2LZtBZegHLZNQ NlDR04gf+ynW4i1Vd8vRidlO7J286VfWSMSWWyuzhUl4NhCcyo+++U78KR61eIdvzrLN dPEw== X-Gm-Message-State: ALoCoQn28SiOl1QXyoRb+1ZOBY9pvG4zV1PF+xZUj3OmGl5DjM7H5p2keKvZS8LHqTG3IdgESfLG MIME-Version: 1.0 X-Received: by 10.220.177.138 with SMTP id bi10mr4248892vcb.1.1415922868273; Thu, 13 Nov 2014 15:54:28 -0800 (PST) Received: by 10.31.10.65 with HTTP; Thu, 13 Nov 2014 15:54:28 -0800 (PST) In-Reply-To: <54653FB5.6010402@jvknet.com> References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54653AB0.1020903@gmail.com> <54653FB5.6010402@jvknet.com> Date: Thu, 13 Nov 2014 13:54:28 -1000 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c2bd5897db300507c63bcd Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qFD7m0jtJUvibiAJARjBY1-ClDA Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 13 Nov 2014 23:54:30 -0000 --001a11c2bd5897db300507c63bcd Content-Type: text/plain; charset=UTF-8 RFC 6732 is obsoleted by this draft, isn't it? On Thu, Nov 13, 2014 at 1:33 PM, Victor Kuarsingh wrote: > v6OPS WG, > > A natural association to deprecating RFC3068 and the removal of routing > the 192.88.99.0/24 prefix will be the cessation of RFC6732 operation > where it's enabled/implemented. This is expected and a good thing. > > Not sure if this should be mentioned specifically in the draft or not. > > regards, > > Victor K > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- james woodyatt Nest Labs, Communications Engineering --001a11c2bd5897db300507c63bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC 6732 is obsoleted by this draft, isn't it?

On Thu, Nov 13, 201= 4 at 1:33 PM, Victor Kuarsingh <victor@jvknet.com> wrote:
v6OPS WG,

A natural association to deprecating RFC3068 and the removal of routing the= 192.88.99.0/24 pre= fix will be the cessation of RFC6732 operation where it's enabled/imple= mented.=C2=A0 This is expected and a good thing.

Not sure if this should be mentioned specifically in the draft or not.

regards,

Victor K


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



--
=
james woodyatt <jhw@nestlabs.com>Nest Labs, Communications Engineering
--001a11c2bd5897db300507c63bcd-- From nobody Thu Nov 13 15:56:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E281A1AE35D for ; Thu, 13 Nov 2014 15:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 tKviMyKQTsZy for ; Thu, 13 Nov 2014 15:56:05 -0800 (PST) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDA1AE35F for ; Thu, 13 Nov 2014 15:55:59 -0800 (PST) Received: from [98.139.214.32] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 23:55:58 -0000 Received: from [98.139.212.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 23:55:58 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 13 Nov 2014 23:55:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 232705.90535.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 7347 invoked by uid 60001); 13 Nov 2014 23:55:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1415922958; bh=kL8T+RyqBt18k8HQWmgVBZxXUHuqLSKtpdfcZ29W2cA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FMOznzUoPcHPari0+wtRijug3kQm1RcparI+n4cO5WyoPoNfIAKyQAXj96GQooits5sPBGRs4pP4DSZfKIkM/I04jJDEDeG1mK2cBaKkhYoF4JB2Io4fZcLpNPMMCGdDGOtgmUq16JKZ6otXBYo00dvZCdfBOZVoRG4gmbCg4cw= X-YMail-OSG: vkjQNSUVM1nvuVFyLf2dAGplamnqYGiGsdA4Qr9Gw_zqb9y 5ueHIjGnvTFAt2CkseEugDu2xpHYzdXDd_vMJQnMtBTDwIPD4.U9k9oxsNXR 7xY61amW1Sq95KvRIAa4YIywTV3KymEnLuJyDVItuSZXQJsfuw4Gp2n1jl7. AXDjz9tkG9.CDb4kNK2aAEu0tNue0ZyzFWayWp6RcDS3Eet9K230NLi2aa6L 09hglw2Egls.XhzQRUR.3r5PNmvrM3rMwoZVWRXC9b8RrJaJ3SUxoCjbMcoX wOhUFwDM6GDvr_PIdf1CdKFA7nDSbHiLFNTRg2JMzs0sN7kRbPLrdauBL7P5 uhfKgCkhfFYJdN5ZOfkyzY88HT8fdV6JYrVbGWhLz0iWYlt.szx9FvCD9S27 OdZzYFYGeniKHs1TbqQA1iImbpus48fXmSQadCTtjLDd5EizuUAfH3VEsMZT G.fVkfJxlzZLSeiXu4rP5q9deOd.HUUXL7nxoZdXWw.GTt2dyCXQywt3y2qj N6kkMkJImzcaJCLTR2ZBp0PIpkihXAcZ3FnUmW_BKbzsdOD311OgkeA-- Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Thu, 13 Nov 2014 15:55:58 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogSmVyb2VuIE1hc3NhciA8amVyb2VuQG1hc3Nhci5jaD47IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gQ2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc.OyA2bWFuIDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMTIgTm92ZW1iZXIgMjAxNCwgOTo0NAo.IFN1YmplY3Q6IFJlOiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> Message-ID: <1415922958.6870.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Thu, 13 Nov 2014 15:55:58 -0800 From: Mark ZZZ Smith To: Mark ZZZ Smith , Jeroen Massar , Brian E Carpenter In-Reply-To: <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AvoAegWOKlaSea5neYyMAQcEM3A Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:56:07 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith =0A> To: Jeroen Massar ; Brian E Carpen= ter =0A> Cc: IPv6 Operations ;= 6man =0A> Sent: Wednesday, 12 November 2014, 9:44=0A> Subje= ct: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-= problem-01)=0A> =0A> =0A> =0A> =0A> =0A> =0A>> ____________________________= ____=0A>> From: Jeroen Massar =0A>> To: Brian E Carpente= r =0A>> Cc: IPv6 Operations ;= 6man =0A>> Sent: Tuesday, 11 November 2014, 6:02=0A>> Subj= ect: Re: [v6ops] IPv6 MTU Flow-label.... (related to =0A> draft-v6ops-pmtud= -ecmp-problem-01)=0A>> =0A>> =0A>> On 2014-11-10 19:57, Brian E Carpenter w= rote:=0A>>> Er, no, you really can't use the flow label like that. RFC6437= .=0A>> =0A>> Hence, redefining the bits :) Few implementations use them any= way, thus=0A>> we still have time to actually make good use of them.=0A>> = =0A> =0A=0A> =0A> If high performance stateless and therefore load in= sensitive LB distribution is =0A> needed or wanted, then perhaps something = more simple that doesn't use TCP or =0A> UDP port information might be bett= er. For example, using SA+DA based forwarding =0A> in the LB, and then stat= ically mapping portions of the SA address space to a =0A> particular LB hos= t (e.g., 1/4 to LB host a, 1/4 to LB host b etc. for four LB =0A> hosts), w= ith all LB hosts configured with the LB 'shared' unicast =0A> address (i.e.= , no NAT). If you want anything smarter than that, then I think the =0A> LB= needs to become stateful, and start maintaining per-connection state.=0A> = =0A=0AActually, I've remembered more details of the problem, and the above = doesn't fix it.=0A=0AI think the fundamental problem is that a unicast addr= ess is expected to uniquely identify a single reachable destination from th= e position of the sender (i.e., a single host, or a single one of the hosts= sharing an anycast address, with the routing system selecting the single d= estination anycast host to deliver it to.).=0A=0AThe trouble here is that t= he unicast destination address in the PTB message doesn't uniquely identify= a single reachable destination, and therefore the simple stateless ECMP me= thod of load balancing may not select the right destination. The source add= ress of the PTB doesn't help either, because it is of the router generating= the PTB, so it isn't specific to the session either (which is my simpler s= tateless method above doesn't fix the problem.)=0A=0A> =0A> =0A>> Note that= I am specifically proposing setting the first four bits to 1=0A>> aka 0xf = so that the space can still be used for it's original intent =0A> too.=0A>>= =0A>>> What you can do is use the flow label as intended, for ECMP or any= =0A>>> other kind of load balancing. RFC6438, RFC7098. They don't fix the= =0A>>> ICMPv6 problem though.=0A>> =0A>> It won't fix the 1-RTT issue that= worries content providers either.=0A>> =0A>> That is the biggest problem f= or them: a ICMPv6 PTB is an extra round=0A>> trip and they want speed. Henc= e including the MTU already in the packet.=0A>> (though as noted in my repl= y, it won't work fully for async networks)=0A>> =0A>>> The key sentence in= Joel's draft is=0A>>> =0A>>>> Because the PTB message is not identifia= ble as part of the=0A>>>> original flow by the packet header the result= s of the ICMPv6 =0A> ECMP=0A>>>> hash are unlikely to be hashed to the = same nexthop as packets=0A>>>> matching TCP or UDP ECMP hash.=0A>>> =0A= >>> To fix that, I suspect that flow label reflection is needed.=0A>> =0A>= > Won't work as that packet will not be matching the loadbalancers setup=0A= >> either.=0A>> =0A>> What would partially work is if the ICMPv6 PTB would = copy the flow-label=0A>> from the original flow that caused the PTB.=0A>> = =0A>> But then still, large content providers will not be happy, as it does= =0A>> not satisfy the 1-RTT argument, which now causes them to just ignores= =0A>> PTBs and set the MSS to something tiny (thus in the end causing more= =0A>> packets, but at least all packets will go through).=0A>> =0A>> =0A>> = =0A>> =0A>> =0A>> Greets,=0A>> Jeroen=0A>> =0A>> __________________________= _____________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> http= s://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A>> =0A>> =0A>> =0A> =0A> __= _____________________________________________=0A> v6ops mailing list=0A> v6= ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nobody Thu Nov 13 16:00:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926DC1AE368 for ; Thu, 13 Nov 2014 16:00: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 YgznQrLaABwL for ; Thu, 13 Nov 2014 16:00:55 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51721AE33C for ; Thu, 13 Nov 2014 16:00:54 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so7243043wgg.21 for ; Thu, 13 Nov 2014 16:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GRbfuY/dHbtyrott+KHUNB8z2In5YdUpV/hyfw6xJ/I=; b=AEnKAWz+lX3HbqH0ytGQYiS9HNQvq4kTsw8B9XRZcl6iJbWQ5tBImAPMPco3QEIR8P l3rTP174lZAWmoyH64TQsQ2F7Py/cEW6o1fMuLl8FGAI7wAoELU2kcePac0R+ny7xqUd EIhlqUU9H8AlnR8RSiXMGx8B/bSoJ3sZvXPdsM5UuYIsKQzRsD4Dh0fgkNWaBfODutvG 1u8CSnj27v2QD8P+agUE7O9kVBEeTeo6QnXt3EQMQ99TUuvSePRAHnIJWpZmJb6ZRLiy bvu16Vy40wi1uNnqk4Ck2sW1hNkiPhsPAtZYEEOWouGTmcP5b5HTbk9WmoB4NGqUVPkj hG2A== X-Received: by 10.180.93.132 with SMTP id cu4mr2589494wib.46.1415923253417; Thu, 13 Nov 2014 16:00:53 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id wx3sm37455940wjc.19.2014.11.13.16.00.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 16:00:53 -0800 (PST) Message-ID: <5465463C.1000508@gmail.com> Date: Fri, 14 Nov 2014 13:01:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: James Woodyatt References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54653AB0.1020903@gmail.com> <54653FB5.6010402@jvknet.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k1Z_9pcWE9j_iNUzRiF8Q0grfus Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.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, 14 Nov 2014 00:00:56 -0000 Well, it isn't right now, but we certainly can do that if Victor so advises. However, I'm not going to issue a -09 version just for that. Brian On 14/11/2014 12:54, James Woodyatt wrote: > RFC 6732 is obsoleted by this draft, isn't it? > > On Thu, Nov 13, 2014 at 1:33 PM, Victor Kuarsingh wrote: > >> v6OPS WG, >> >> A natural association to deprecating RFC3068 and the removal of routing >> the 192.88.99.0/24 prefix will be the cessation of RFC6732 operation >> where it's enabled/implemented. This is expected and a good thing. >> >> Not sure if this should be mentioned specifically in the draft or not. >> >> regards, >> >> Victor K >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 13 16:07:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6D1A007F for ; Thu, 13 Nov 2014 16:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, RCVD_IN_DNSWL_NONE=-0.0001] 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_e3l2tH7O4C for ; Thu, 13 Nov 2014 16:07:41 -0800 (PST) Received: from nm44-vm7.bullet.mail.bf1.yahoo.com (nm44-vm7.bullet.mail.bf1.yahoo.com [216.109.115.31]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BC81A0077 for ; Thu, 13 Nov 2014 16:07:40 -0800 (PST) Received: from [98.139.212.153] by nm44.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 00:07:39 -0000 Received: from [98.139.212.246] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 00:07:39 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 00:07:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 399503.61913.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 4463 invoked by uid 60001); 14 Nov 2014 00:07:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1415923659; bh=7AKlPlUDpsgdcsn+QYk0DggAGD6nR1rZTZK8CP8tnMY=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mzHzDBIRJqwKBAC6n+FbEkCoobXXV8d9ULrgobPBDMj1BeO7+egyk/AvRqMuebSq4MHZUlemP5KxHOsaQDGUfq0O7pwijgYcebtlfZ0X0eVE1IJpzcQZsjbS/gkTev/13q8pBwcBRDIldpEjitzSRcOSVOsHbf2phTCjq6u1nko= X-YMail-OSG: G2FezxwVM1m5Zz.OMqIq.WfTGoUfHa6.Da0W7ZVRR2.vnxt Zm12UhFgT9sp48bnJeVAQywse5vYtzo1Vljj9Y.Mp1biAQUE66pogevtGWae pXN5gzXhe8VcTCErWkH7nNZMhykikjLOKFabe5b4XxEOjfAfL_m4__xnzL_6 pVGVNWUGQ.chZQWa8VWjY02uva0ZheSh762ZMSPT1pYHJv_IzteFQ5vMr5FE T2.1PhJA.UK1Vmz.hE5jDlZyOEuWe85t.aidQXGwjKOTTm06bchi4R1ATsyq VNKD8xhJF_WGlPWFUW4r0J9ca3Mzkeiatxu7pgSsn9ZibNQuLGmqhglKGAZ8 R1pdkneoYLLhfnRKtY3cRu7xarqSfMysiRkUtdgWbFI_IwHL7pACyMJUz3vu wEt9zGb5OhRNBoEpJa9hdwVfZ2eQ_wxGf4gVLV1s8vKIUjmQ8jXpOJhzuatm Pq2GhDpuW4mvb7sjOU49ztf2BtgLnVpi0N.V1dRM0n7jS7ZVx58Oav7SlBL5 SFM.kdAgp0EuW_1x3oQxY1lNDajKJJ1Ce.2tofhSE5qnLOCLNNII4Yw-- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Thu, 13 Nov 2014 16:07:39 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBKZXJvZW4gTWFzc2FyIDxqZXJvZW5AbWFzc2FyLmNoPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4gPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogV2VkbmVzZGF5LCAxMiBOb3ZlbWJlciAyMDE0LCAxOTo0Ngo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgTVRVIEZsb3ctbGFiZWwuLi4uIChyZWxhdGVkIHRvIGRyYWYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <54631E71.60403@massar.ch> Message-ID: <1415923659.92015.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Thu, 13 Nov 2014 16:07:39 -0800 From: Mark ZZZ Smith To: Jeroen Massar In-Reply-To: <54631E71.60403@massar.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dIJWmTROR1kJ8wTUvopmm4LvORI Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:07:43 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Jeroen Massar =0A> To: Mark ZZZ Smith =0A> Cc: IPv6 Op= erations ; 6man =0A> Sent: Wednesday, 12 Nov= ember 2014, 19:46=0A> Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related= to draft-v6ops-pmtud-ecmp-problem-01)=0A> =0A> On 2014-11-11 23:44, Mark Z= ZZ Smith wrote:=0A> [..]=0A>>> On 2014-11-10 19:57, Brian E Carpenter wrot= e:=0A>>>> Er, no, you really can't use the flow label like that. RFC6437.= =0A>>> =0A=0A> [..]=0A> =0A> Indeed. The problem there is simply that= IP was not designed with such a=0A> system (load-balancers looking only at= src/dst(/flow-label)) in mind,=0A> especially when considering these devic= es have to look at ICMPv6 too,=0A> which they clearly do not (for performan= ce reasons, hardware/asic etc).=0A> =0A> What is sad about this is that the= vendors who built those devices did=0A> not discover this till they deploy= ed those devices and that when they=0A> did, they apparently did not raise = this for discussion in the community=0A> so that a proper fix could be made= .=0A> =0A=0ASo I'd argue that protocols shouldn't have to be changed in rea= ction to lack of proper product design. I wouldn't support using the flow l= abel for this purpose. Doing so would seem to me to be expecting the protoc= ols to be band-aided to fix what is a problem with some vendors products, r= ather than products being designed to properly work with the protocols as t= hey're defined.=0A=0AI think the fundamental conflict is that the Internet = protocols assume a unicast destination address in a packet identifies a sin= gle unicast destination for the forwarding system to deliver to. Stateless = LBs are violating that assumption, which is why the protocols built on that= assumption then fail.=0A=0A=0A> =0A> Greets,=0A> Jeroen=0A> From nobody Thu Nov 13 16:18:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B894F1A0023 for ; Thu, 13 Nov 2014 16:18:38 -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 fRjN6aaky7bQ for ; Thu, 13 Nov 2014 16:18:37 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192371A000B for ; Thu, 13 Nov 2014 16:18:37 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so18077808wgh.13 for ; Thu, 13 Nov 2014 16:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1EYnOxMX6c31wxylR1lPUXy/ImEyFg+TNzRbhHaaDaA=; b=FvVCjhPHkfhLLiE0HAtEWjRTrjxZGyKIYMqjeVZUqDr2H8FEO1jF5eJLMVwfluhUf/ 6bywD4v7CKeYlf88Tzd5WmBYrAhOZaFHld6jF07TIcRbEBN35EiUM0HVYVHvh3YGk7Zc GMTYw2dj+JnKoONCIFnUmY0+SoRcbqYPkla6/0pc3v9LQtwXbKcxChT7tvALPzi0BL+c OjY9256LUMS30WLprExoTD5mHy9FgoIko+QKyaAtWyj/N96R1bHp06KFxF1NW6L3SksC ONNqD8gYHEynPYob5oTpyeF79i/+yL0Rjq7Co8oLr+An6Jg8U9oqIkt+Ub/yfHG4X5uA Rkrw== X-Received: by 10.180.212.52 with SMTP id nh20mr2801020wic.2.1415924315865; Thu, 13 Nov 2014 16:18:35 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id mc10sm531306wic.24.2014.11.13.16.18.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 16:18:35 -0800 (PST) Message-ID: <54654A63.6000406@gmail.com> Date: Fri, 14 Nov 2014 13:18:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lee Howard References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7qiSbMIsWiAmY8yPYpM0Lhcg7qE Cc: 'IPv6 Operations' Subject: Re: [v6ops] draft IETF91-v6ops minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 00:18:39 -0000 > Dave Thaler: If we deprecate 6to4, Teredo is next in line in preference= > table. Opposite of what we want. Thus, do not deprecate rfc3056 (p2p = mode) > without also deprecating Teredo. But Xbox uses Teredo for p2p, so can=C2= =B9t > deprecate it yet. I think Dave was getting at the default policy table in RFC 6724 in particular, which in fact we do not propose to change whatever we deprecate. Brian From nobody Thu Nov 13 16:35:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690621A026E; Thu, 13 Nov 2014 16:35:27 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnk_VO2UCg1E; Thu, 13 Nov 2014 16:35:25 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247BB1A01AA; Thu, 13 Nov 2014 16:35:25 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 9933E10060A48; Fri, 14 Nov 2014 00:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415925322; bh=5eujg+/N4diNp2nqZ90SU0eqnTSh+LlB/oHaqYPJv1A=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=kbzwzPMjzbiWw/Bv3iQTVbVbanlvh3mzzBJ/zhwxQ9nE+fVFUPat6rBRMKepzp8hW THGjmofm/RaWhJ0wNkJH/AawLI90ks9m3w+WF3xBziUEszeKZIdz+4dcvK2k9BvWdd Hkj2Hodi5hDn6kB9OyFXbDETk7Tx8deWDbw+w6oTvNBX1yNlivlMTKLOt5zEHig5on Yb4pWUqRmk781wQrMp+YVYMIVQrr2yeWn3yFudbNg/Us3vnK3nPEa/cQ1jAtW0yKhN qFM3Zvk1HM7h9oF8cWBVgCaRafeuQgOWj1JovRKo6D4Dhs2yZrgSpaazZcL2jgCkY5 HaowbBwatIMAQ== Message-ID: <54654E47.7090003@massar.ch> Date: Fri, 14 Nov 2014 01:35:19 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Mark ZZZ Smith References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <54631E71.60403@massar.ch> <1415923659.92015.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1415923659.92015.YahooMailNeo@web162204.mail.bf1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4w2dHkAFuBVM9aMoMfcGATJUynU Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Fri, 14 Nov 2014 00:35:27 -0000 On 2014-11-14 01:07, Mark ZZZ Smith wrote: [..] > So I'd argue that protocols shouldn't have to be changed in reaction > to lack of proper product design. I wouldn't support using the flow > label for this purpose. Flow Label cannot work the way that it is defined. The reason for having a Flow Label is so that for instance a Load Balancer does not have to look further than the first 40 bytes of packet (thus just the IPv6 Header). But, as every node MUST look at ICMPv6, that is thus automatically false. Hence, the Flow Label is useless for the purposes of identifying a flow. Note that an IPv6 'error', thus an ICMPv6 packet, for instance an PTB, but also "port unreachable" etc is part of the flow as it indicates an error status that relates to that flow. Obsoleting the Flow Label and using the bits for a problem we did not have in 1996: Load Balancing, proper MTU discovery etc is thus a good idea. Note that back then nobody really cared about 0-RTT either. This proposal CAN make that work, which will make a lot of content providers very very happy. Oh, and it solves most cases of the Load Balancer issue too (as described in the pmtud-ecmp draft). Though yes, it still will need to inspect a ICMPv6 PTB, at least it is not misled to believe the Flow Label is useful in any way. [..] > I think the fundamental conflict is that the Internet protocols > assume a unicast destination address in a packet identifies a single > unicast destination for the forwarding system to deliver to. > Stateless LBs are violating that assumption, which is why the > protocols built on that assumption then fail. That is mostly correct, but that is not the primary reason. The big problem is that even if the Load Balancer supports parsing the ICMPv6 PTB and can associate it with the correct "flow" and thus the right backend host, it won't help as there are a lot of other systems out there that are on purpose filtering out ICMPv6. By including the MTU in the packet though, it won't be filtered (or at least set to 1280, which is the minimum which just makes them hurt their own performance, but it won't break things). Greets, Jeroen From nobody Thu Nov 13 16:38:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0151A03AB; Thu, 13 Nov 2014 16:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvDir1xEW-sU; Thu, 13 Nov 2014 16:37:57 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C791A040C; Thu, 13 Nov 2014 16:37:56 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 2FD3D10060A48; Fri, 14 Nov 2014 00:37:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415925474; bh=g9Pa/YQlnTvx7YxljG1cFoI6MWuDOfyXGhdliXniyaY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=YfZFqv7gZkQTIQ5yj97F39aTlsvctlXgABMSFrcd5t7NGIeCaGAmP4dUqC1zSawIK iJ2WfKGYou6fF9TJ2npgQu2nqCZsN4R9j7BJl79uBLsap71gPbRGWh5AM05PSONBs2 alh0sNBsDGpTKun1G/Y3VjMLFvR7F9LLHQLxK5wnuKnBbi3r3zhHSvdD/tYsa7bi+E aHXAANweTEsHQMuC5oNz41AS1z+MOwI/mMNojuLj9rs7CigmfBW4nbFYN0fMbBI5Gy GElffTDVJnp/Nk3rk41Sq+H9HYCYf7htQzcg/heRfGB4lNytOxmsERT9JwmSfK25rd EvzyymEkcBJaQ== Message-ID: <54654EE0.4090507@massar.ch> Date: Fri, 14 Nov 2014 01:37:52 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Mark ZZZ Smith References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <1415922958.6870.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: <1415922958.6870.YahooMailNeo@web162201.mail.bf1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/w_a5ZL2dAnsaFAOOh0C-YWDKc2s Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Fri, 14 Nov 2014 00:38:07 -0000 On 2014-11-14 00:55, Mark ZZZ Smith wrote: [..] > The trouble here is that the unicast destination address in the PTB > message doesn't uniquely identify a single reachable destination, and > therefore the simple stateless ECMP method of load balancing may not > select the right destination. The source address of the PTB doesn't > help either, because it is of the router generating the PTB, so it > isn't specific to the session either (which is my simpler stateless > method above doesn't fix the problem.) Having a Flow Label is thus useless for this situation. And as the Flow Label is there to make work for Load Balancers and other 'flow based decision makers' easier, ... well it fails at that. Hence, lets just get rid of it as it is broken by design anyway. Greets, Jeroen From nobody Thu Nov 13 16:43:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4081A19FA for ; Thu, 13 Nov 2014 16:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x55bdDEj62e3 for ; Thu, 13 Nov 2014 16:43:25 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261931A19F7 for ; Thu, 13 Nov 2014 16:43:25 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 8484B1003C083; Fri, 14 Nov 2014 00:43:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415925802; bh=nKyMrQmyvsG8ebnBgBoM2VXH3JBbkdw4A4EEG2LFN3Q=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=crQ8Bp7nDE0zsicrv241yyx5MRv//iuVXoYGJyJQUVRcRdLmQyYtW3vd+ODrjTQNV LpBD8QqbUzW1dnZxkYMA9LIkFddx1iLd2MSL1ug1aqwkqKH7jCd7U3F+7nyeCuizU6 +2XN5J+6RdAK1pEazjcvYHd1tWimz6g0HYkk1TO5AG19KFrDkl78SWhM8eWZT4Zoom iVMk3wYnpPtN/qIUSmvLDzoI4xI94dscajZZ9RMl8aK+wosqwmANxehKr1RXkqSM66 8k4rt2AIrnNZBsnW5x8Tq4COYQb41Kj++Ujz31/r6CWaetQPvofWXsRMZI8b2zP0P7 BrHl6R6RrxqHg== Message-ID: <54655028.2090907@massar.ch> Date: Fri, 14 Nov 2014 01:43:20 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <54653620.7050809@massar.ch> <546539C5.8050104@gmail.com> In-Reply-To: <546539C5.8050104@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OJdKNYYpKQICU2f3P4GVKy9XBYw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 00:43:27 -0000 On 2014-11-14 00:07, Alexandru Petrescu wrote: > Jeroen - you make up a few pretty good questions, I am happy. If I dont > keep up sorry. [..] >>> Yes. My situation currently is that my network is on 6to4, >>> it seems to get discarded, >> >> What gets "discarded"? > > deprecated 6to4 seems to become by meeting discussion. But there are MANY alternatives which will work much better. Thus what is the problem? >>> and the trustful ISP is not _yet_ offering native. >> >> What do you mean with "the trustful ISP"? > > An ISP that has same upper organization that my organization. In > private you pointed me to it, you know what I mean. Kick your internal organization. It is 2014. Not 1996. Also the upstream organization (RENATER) has been doing native IPv6 for many many many years thus they will be more than happy to deliver it. The IETF cannot fix politics inside organizations. You will have to fight for that. [..] > Well by renumbering I mean the Renumbering RFC which uses a form of > Router Advertisement propagation. I have never ever seen anybody use that. > You have scripts - great, I am happy for you. Any decent system administrator or network operator who is lazy as they should be will do that. Systems like rancid, puppet etc exist for many many reasons. (I just rsync stuff with a /etc/init.d/... after it ;) Greets, Jeroen From nobody Thu Nov 13 16:50:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1DA1A1A47 for ; Thu, 13 Nov 2014 16:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_66=0.6, 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 xl9AKUZNJ8il for ; Thu, 13 Nov 2014 16:50:45 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E620C1A1A42 for ; Thu, 13 Nov 2014 16:50:44 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 8588310063F5E; Fri, 14 Nov 2014 00:50:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415926242; bh=jqK6ImWNazwP6fHzSuF64q3D+DIAWXuFn6r2No8yvz0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=xIU8KtLuD6R6RvyVF3l66M8MZrQW96NiCZVT4k46bWrvlaoHpwI4+/gSkK9rrgVWE J5w76Hk+SXau1T4IBNMXeypHb/QeDMYTZCcjIqhv7n2apAF6jYR7Ym4OezU5C6bfV0 HEcbikuH4typNKjd6jFm/A5p8fmX2SC15JzkSd2Vbl0dkHvGK2uEazP4guIsUBAXmS EW/hyW45pUQp1k/N3SahfAS7eVoxpr2P/zVovLfjJSjrUq7tiBFSMLCsasO5iMgn2M amITtWQJRqrZl/tX02YmN3Sq+VuctyBkgGGz672Tk5S2r4xd8XliacYYEHoqizknBA P3bDWmJF46Sjw== Message-ID: <546551E0.9040101@massar.ch> Date: Fri, 14 Nov 2014 01:50:40 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> <5465381B.5080906@massar.ch> <2134F8430051B64F815C691A62D9831832D862F5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D862F5@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NF80gSkDh_ebVxMCZENDzuv1V2Y Cc: "v6ops@ietf.org WG" Subject: [v6ops] AERO again (Was: Bar BoF on a 6to4 replacement?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 00:50:47 -0000 On 2014-11-14 00:31, Templin, Fred L wrote: > Hi Jeroen, > >> -----Original Message----- >> From: Jeroen Massar [mailto:jeroen@massar.ch] >> Sent: Thursday, November 13, 2014 3:01 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org WG >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? >> >> On 2014-11-13 23:52, Templin, Fred L wrote: >>> Hi, >>> >>>> Goal - any new replacement of 6to4 must be future proof: avoid >>>> renumbering when 6to4-replacement dies out. (this is what current >>>> tunnel brokers dont offer, they force one into a lockin going away from >>>> tunnel broker to native IPv6 one has renumber). >>> >>> To amplify this point, tunnels are for more than just IPv6 transition. They are >>> useful also for: >>> >>> - mobility management >>> - routing control >>> - security (e.g., VPN) >>> - multihoming >>> - traffic engineering >>> - renumbering avoidance >>> - etc. >>> >>> You get all of this (plus v6/v4 transition, of course) with AERO. Indeed, >>> AERO can be a one-stop-shopping solution for any tunnel application. >> >> AYIYA handles those fine too. Tested and in use by over 20k people, >> available from quite a number of CPEs too ;) > > I forgot to mention also: > > - route optimization Does it get a BGP feed to make these decisions? > - distributed mobility management The 'distributed' part comes from flooding these details to network. How does that scale with say 100.000 clients? > With AERO, there can be many 100's of Servers, And who would operate and coordinate these? How are these connected to the Internet? What kind of address would they use and where do they get these from? And how would a client be configured, needs anycast? > and the Clients get the same > service no matter which Server(s) they associate with. Peer-To-Peer networks do the same trick. Firewalls tend to not like them. > The Server-to-Client > associations are communicated to Relays which connect the AERO link to the > rest of the IPv6 Internet. How is this connection done? Are you peering at every major IX in the world? Or are you announcing a Anycast prefix everywhere? > Server association is through DHCPv6 PD messaging, > and Route optimization is through IPv6 ND messaging the same as for any link. What is the decision process for "optimizing a route"? How is this better than the decisions made by actual live operators and BGP? >> OpenVPN works perfectly fine for probably millions of people. > > OpenVPN is indeed the target integration platform for the AERO Client. OpenVPN is not a platform, it is a protocol implemented by a client+server. > Only, it is used whether or not the tunnel also applies IPsec OpenVPN does not do IPSec on the outside, it uses its own crypto. The tunneled packets might be IPsec though. > - it would > also be used for simple IPv4/UDP/IPv6 encapsulation. How? >> Don't call those things "tunnels" though, just name them by their >> commercial name: VPNs. > > Tunnels are VPNs and VPNs are tunnels, sure, but I don't see a reason for > making such a distinction for the purpose of this discussion. As the subject was "6to4 replacement" we are talking about IPv6 tunnels. VPNs are a specific case of provider-provided networking. Typically with money involved and typically requiring credentials. Greets, Jeroen From nobody Thu Nov 13 17:18:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74E1A040B for ; Thu, 13 Nov 2014 17:18:01 -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 nyubl7auLI0L for ; Thu, 13 Nov 2014 17:17:59 -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 228561A1A2C for ; Thu, 13 Nov 2014 17:17:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAE1HulR005466; Fri, 14 Nov 2014 02:17:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 44A2F200BBA; Fri, 14 Nov 2014 02:18:17 +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 2D195200BA7; Fri, 14 Nov 2014 02:18:17 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.13]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAE1GxbN025745; Fri, 14 Nov 2014 02:17:55 +0100 Message-ID: <54655809.4080109@gmail.com> Date: Fri, 14 Nov 2014 02:16:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <546525E7.7050006@massar.ch> <54652E0C.7050901@gmail.com> <546531AF.6@gmail.com> <546533D7.9080507@gmail.com> <54653EE1.1050905@gmail.com> In-Reply-To: <54653EE1.1050905@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YzOJyRgL_Swz9oRW6z0hgfN4HA0 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 01:18:01 -0000 Le 14/11/2014 00:29, Brian E Carpenter a écrit : >> 6to4 is not alowing for reverse DNS either, if I am not terribly wrong. > > RFC 5158 "6to4 Reverse DNS Delegation Specification" > > Regards > Brian > Thanks, I didnt know that. Alex From nobody Thu Nov 13 18:09:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F0E1A1B1A for ; Thu, 13 Nov 2014 18:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Q_487w2PXa-T for ; Thu, 13 Nov 2014 18:09:54 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF2B1A00F7 for ; Thu, 13 Nov 2014 18:09:54 -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 sAE29r80025858; Thu, 13 Nov 2014 20:09:53 -0600 Received: from XCH-PHX-101.sw.nos.boeing.com (xch-phx-101.sw.nos.boeing.com [137.136.238.4]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sAE29p0m025390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Nov 2014 20:09:52 -0600 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.167]) by XCH-PHX-101.sw.nos.boeing.com ([169.254.8.28]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 18:09:51 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: AERO again (Was: Bar BoF on a 6to4 replacement?) Thread-Index: AQHP/7ASoc8VuY5IJkmr5D6fRwAdmQ== Date: Fri, 14 Nov 2014 02:09:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D877A6@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <2134F8430051B64F815C691A62D9831832D8619C@XCH-BLV-504.nw.nos.boeing.com> <5465381B.5080906@massar.ch> <2134F8430051B64F815C691A62D9831832D862F5@XCH-BLV-504.nw.nos.boeing.com> <546551E0.9040101@massar.ch> In-Reply-To: <546551E0.9040101@massar.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1oGr-khLcca9cfR1QWGl2JkHoV8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] AERO again (Was: Bar BoF on a 6to4 replacement?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 02:09:57 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Thursday, November 13, 2014 4:51 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: AERO again (Was: Bar BoF on a 6to4 replacement?) >=20 > On 2014-11-14 00:31, Templin, Fred L wrote: > > Hi Jeroen, > > > >> -----Original Message----- > >> From: Jeroen Massar [mailto:jeroen@massar.ch] > >> Sent: Thursday, November 13, 2014 3:01 PM > >> To: Templin, Fred L > >> Cc: v6ops@ietf.org WG > >> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? > >> > >> On 2014-11-13 23:52, Templin, Fred L wrote: > >>> Hi, > >>> > >>>> Goal - any new replacement of 6to4 must be future proof: avoid > >>>> renumbering when 6to4-replacement dies out. (this is what current > >>>> tunnel brokers dont offer, they force one into a lockin going away f= rom > >>>> tunnel broker to native IPv6 one has renumber). > >>> > >>> To amplify this point, tunnels are for more than just IPv6 transition= . They are > >>> useful also for: > >>> > >>> - mobility management > >>> - routing control > >>> - security (e.g., VPN) > >>> - multihoming > >>> - traffic engineering > >>> - renumbering avoidance > >>> - etc. > >>> > >>> You get all of this (plus v6/v4 transition, of course) with AERO. Ind= eed, > >>> AERO can be a one-stop-shopping solution for any tunnel application. > >> > >> AYIYA handles those fine too. Tested and in use by over 20k people, > >> available from quite a number of CPEs too ;) > > > > I forgot to mention also: > > > > - route optimization >=20 > Does it get a BGP feed to make these decisions? No, route optimization is coordinated between Clients, Servers and Relays a= nd does not interact with the global Internet BGP routing system. However, Servers = and Relays do engage in a BGP routing protocol instance that is kept separate a= nd is used only to track the association of Client prefixes with Servers. So, for= example. if a Client has an AERO Client Prefix (ACP) P and associates with Server S,= the AERO BGP routing system includes the routing entry P->S. In terms of connecting to the larger IPv6 Internet, the AERO link has an ag= gregated (short) AERO Service Prefix (ASP) A that it announces into the global BGP r= outing system. This prefix never changes and does not become de-aggregated due to mobility, etc. > > - distributed mobility management >=20 > The 'distributed' part comes from flooding these details to network. I didn't understand that, but there is no flooding. Clients simply discover Servers that are close by and select one or more Servers to provide them with the service. > How does that scale with say 100.000 clients? Each AERO link can scale to as many ACPs as can be represented in the inter= nal BGP routing protocol instance - let's say that it can handle up to 1M ACPs.= But, there may be many such AERO links. > > With AERO, there can be many 100's of Servers, >=20 > And who would operate and coordinate these? The AERO link administrative authority. > How are these connected to the Internet? As ordinary IPv4 hosts in the public Internet. > What kind of address would they use and where do they get these from? In the case of a 6to4 replacement scenario, they would use the public IPv4 addresses they get from their ISPs. But, the AERO link would not necessaril= y be bound to just one ISP; it can include Servers that are distributed acros= s many ISPs. > And how would a client be configured, needs anycast? Anycast is certainly possible, but the expected mechanism is through DNS resolution of a FQDN like "linkupnetworks.example.com". So, the Client needs to be provisioned with the FQDN. > > and the Clients get the same > > service no matter which Server(s) they associate with. >=20 > Peer-To-Peer networks do the same trick. Firewalls tend to not like them. Didn't get that. > > The Server-to-Client > > associations are communicated to Relays which connect the AERO link to = the > > rest of the IPv6 Internet. >=20 > How is this connection done? Are you peering at every major IX in the > world? Or are you announcing a Anycast prefix everywhere? The AERO link would be represented as an AS to the global BGP routing syste= m. Either the AERO Relays themselves or other BGP routers advertise the ASPs t= o their global BGP routing system peers. > > Server association is through DHCPv6 PD messaging, > > and Route optimization is through IPv6 ND messaging the same as for any= link. >=20 > What is the decision process for "optimizing a route"? How is this > better than the decisions made by actual live operators and BGP? If a Client A discovers that Client B is attached to the same AERO link, Cl= ient A initiates route optimization, and the RO message is conveyed through Server= s (and possibly also a Relay) as a chain-of-trust whereby Client B can know t= hat it can accept messages directly from A. It is asymmetric, so a correspondin= g RO would also have to happen in the reverse direction. Both ways, the AERO link Servers and Relays provide a chain-of-trus > >> OpenVPN works perfectly fine for probably millions of people. > > > > OpenVPN is indeed the target integration platform for the AERO Client. >=20 > OpenVPN is not a platform, it is a protocol implemented by a client+serve= r. OpenVPN is also a software application that runs on a Client. What I meant by "platform" is that the AERO functions would be added to the OpenVPN code base and then run on a Client device. > > Only, it is used whether or not the tunnel also applies IPsec >=20 > OpenVPN does not do IPSec on the outside, it uses its own crypto. > The tunneled packets might be IPsec though. I don't really care what the exact securing mechanisms are. What I care about is the AERO control message signaling regardless of the specific encapsulation. > > - it would > > also be used for simple IPv4/UDP/IPv6 encapsulation. >=20 > How? By not including security encapsulations when they are not needed. > >> Don't call those things "tunnels" though, just name them by their > >> commercial name: VPNs. > > > > Tunnels are VPNs and VPNs are tunnels, sure, but I don't see a reason f= or > > making such a distinction for the purpose of this discussion. >=20 > As the subject was "6to4 replacement" we are talking about IPv6 tunnels. Call it tunnels then, I don't care. AERO tunneling is based on IP/UDP/IP wh= en it needs to go through filtering middleboxes or on IP/IP when it does not. If security is needed, it would then go as IP/IPsec/IP, but that is only fo= r environments that need IP security. > VPNs are a specific case of provider-provided networking. >=20 > Typically with money involved and typically requiring credentials. AERO is not constrained to IPsec-like VPNs only - for the public Internet c= ase, we would just use IP/IP or IP/UDP/IP encaps. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 From nobody Thu Nov 13 18:15:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCA71A017E for ; Thu, 13 Nov 2014 18:15:18 -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 0rvPvb_VPAxm for ; Thu, 13 Nov 2014 18:15: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 155C21A1A59 for ; Thu, 13 Nov 2014 18:15:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAE2FDEf013619; Fri, 14 Nov 2014 03:15:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 456F6200EC7; Fri, 14 Nov 2014 03:15:34 +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 39889200CF3; Fri, 14 Nov 2014 03:15:34 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.13]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAE2F6VF010082; Fri, 14 Nov 2014 03:15:12 +0100 Message-ID: <546565A9.9080700@gmail.com> Date: Fri, 14 Nov 2014 03:15:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <54653620.7050809@massar.ch> <546539C5.8050104@gmail.com> <54655028.2090907@massar.ch> In-Reply-To: <54655028.2090907@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1Azp7yH8P-ontQhFDyZwcABblhA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 02:15:19 -0000 Le 14/11/2014 01:43, Jeroen Massar a écrit : > On 2014-11-14 00:07, Alexandru Petrescu wrote: >> Jeroen - you make up a few pretty good questions, I am happy. If I dont >> keep up sorry. > [..] >>>> Yes. My situation currently is that my network is on 6to4, >>>> it seems to get discarded, >>> >>> What gets "discarded"? >> >> deprecated 6to4 seems to become by meeting discussion. > > But there are MANY alternatives which will work much better. > > Thus what is the problem? The ones you suggest involve renumbering later - painful. >>>> and the trustful ISP is not _yet_ offering native. >>> >>> What do you mean with "the trustful ISP"? >> >> An ISP that has same upper organization that my organization. In >> private you pointed me to it, you know what I mean. > > Kick your internal organization. It is 2014. Not 1996. Arguing at an organization takes more time than the flash depreciation at IETF... > Also the upstream organization (RENATER) has been doing native IPv6 for > many many many years thus they will be more than happy to deliver it. Sure. > The IETF cannot fix politics inside organizations. You will have to > fight for that. This is not politics. This is simple disconnect between what people think at IETF it is good for end users. > > [..] >> Well by renumbering I mean the Renumbering RFC which uses a form of >> Router Advertisement propagation. > > I have never ever seen anybody use that. I guess the authors of the RFC at least have used it. >> You have scripts - great, I am happy for you. > > Any decent system administrator or network operator who is lazy as they > should be will do that. > > Systems like rancid, puppet etc exist for many many reasons. Huh? Does it compile for a 1cmx1xm LTE embedded device, for example? > (I just rsync stuff with a /etc/init.d/... after it ;) Good to know thanks. Alex > > Greets, > Jeroen > > From nobody Thu Nov 13 19:00:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F0B1A011E for ; Thu, 13 Nov 2014 19:00: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECREnG2wjPzZ for ; Thu, 13 Nov 2014 19:00:10 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF9B1A1B8B for ; Thu, 13 Nov 2014 19:00:09 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id E23D710063F46; Fri, 14 Nov 2014 03:00:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1415934006; bh=f90JWNRRoRxarSRyeqAgz4bmaFKaXyOYsanfFH+Lm+k=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=chBTuGM+pfuorTJB3WoMBMvPeQBSAa+PLaa9I8NNMnm5eClhd9yynvg2l6V8xdWv3 +3UXakHsczm5+kpVgfiyQ01EmkvjO1mhb42XhkdIz1tHay+j0FI6Zz/YWPqhovWhSr MSqts74DaxP5aGJNJoSqdc/8mmeGCTAFzYbs/uLwUpkhEFQz7vtiFyonqLKVjvFgfj wEKD5Y08+H2nSZz4gjZId2nfv4DXcAkz7TDuVUjYbQZgcL41TFzxFmLi88OAfDYJA+ E3zY4WE6bG3amT0eAxDadea3Rx4euriDuSPfRgQmRPpo68xZ/rcz0Yvwl6Y7QWnliM 3mAjR3KlG+vfg== Message-ID: <54657034.4050004@massar.ch> Date: Fri, 14 Nov 2014 04:00:04 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Alexandru Petrescu References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <54653620.7050809@massar.ch> <546539C5.8050104@gmail.com> <54655028.2090907@massar.ch> <546565A9.9080700@gmail.com> In-Reply-To: <546565A9.9080700@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ixBNuYdJLjCRt6Ww-2q84HBY4qc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 03:00:14 -0000 On 2014-11-14 03:15, Alexandru Petrescu wrote: > Le 14/11/2014 01:43, Jeroen Massar a écrit : >> On 2014-11-14 00:07, Alexandru Petrescu wrote: >>> Jeroen - you make up a few pretty good questions, I am happy. If I dont >>> keep up sorry. >> [..] >>>>> Yes. My situation currently is that my network is on 6to4, >>>>> it seems to get discarded, >>>> >>>> What gets "discarded"? >>> >>> deprecated 6to4 seems to become by meeting discussion. >> >> But there are MANY alternatives which will work much better. >> >> Thus what is the problem? > > The ones you suggest involve renumbering later - painful. As you chose to use 6to4 you will have to renumber anyway one day. 6to4 is a transition technique, hence bound to go away. Note that technically you do not have to renumber, you can keep on using that 6to4 prefix, just not with a default pointing to the Internet anymore, especially not that anycast address. Also note that when changing ISP one will have to renumber, unless you are your own ISP and play the PI game you will not be getting away from that. Hence why becoming an LIR and getting your own ASN, own IPv6 PI and a last chunk of IPv4 is very popular, even home users do that already. Another note there is that most CGN/DSLite providers have are delegating prefixes that rotate every 24 hours, for "accounting" reasons or "your privacy and anonimity" but in reality so that folks won't run servers in the cheap space and need to buy hosting instead. >>>>> and the trustful ISP is not _yet_ offering native. >>>> >>>> What do you mean with "the trustful ISP"? >>> >>> An ISP that has same upper organization that my organization. In >>> private you pointed me to it, you know what I mean. >> >> Kick your internal organization. It is 2014. Not 1996. > > Arguing at an organization takes more time than the flash depreciation > at IETF... This draft will become an RFC... vendors won't do much, existing devices will keep on doing what they do as they do not get updated. Maybe operators will start stopping their relays, but that is it. That will take a couple more years though for all that to fade away. >> Also the upstream organization (RENATER) has been doing native IPv6 for >> many many many years thus they will be more than happy to deliver it. > > Sure. > >> The IETF cannot fix politics inside organizations. You will have to >> fight for that. > > This is not politics. In the end everything comes down to politics... if you like it or not. > This is simple disconnect between what people > think at IETF it is good for end users. I think "the IETF" is of the opinion that native IPv6 is the way to go. This is also the message being sent out with deprecating 6to4 which is just one of many transition mechanisms. As you state "end user" btw, you should be contacting your network team to get their act together. They kind of had already 15+ years of warning that this was coming and the hype machine has been doing proper information distribution and pushing folks to do this IPv6 thing. >> [..] >>> Well by renumbering I mean the Renumbering RFC which uses a form of >>> Router Advertisement propagation. >> >> I have never ever seen anybody use that. > > I guess the authors of the RFC at least have used it. I'll refer to a previous message in this thread to answer your question: http://www.ietf.org/mail-archive/web/v6ops/current/msg20524.html Demonstrating that the folks who write the drafts do not always use their own tools... >>> You have scripts - great, I am happy for you. >> >> Any decent system administrator or network operator who is lazy as they >> should be will do that. >> >> Systems like rancid, puppet etc exist for many many reasons. > > Huh? Does it compile for a 1cmx1xm LTE embedded device, for example? Contact the vendor of your device for details on how to properly manage them. Likely though it is just DHCP that you'll use for it or some custom Enterprise tool that can set all kinds of settings. Greets, Jeroen From nobody Thu Nov 13 21:00:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFED1A6F45 for ; Thu, 13 Nov 2014 20:59:55 -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 yWQjDzF9jlp5 for ; Thu, 13 Nov 2014 20:59:39 -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 6AE5A1A6F41 for ; Thu, 13 Nov 2014 20:59:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAE4xbkG028368; Fri, 14 Nov 2014 05:59:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E62A92049D7; Fri, 14 Nov 2014 05:59:57 +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 DA2D5200C2E; Fri, 14 Nov 2014 05:59:57 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.18]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAE4xDrp030042; Fri, 14 Nov 2014 05:59:36 +0100 Message-ID: <54658C20.8030300@gmail.com> Date: Fri, 14 Nov 2014 05:59:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> <54653620.7050809@massar.ch> <546539C5.8050104@gmail.com> <54655028.2090907@massar.ch> <546565A9.9080700@gmail.com> <54657034.4050004@massar.ch> In-Reply-To: <54657034.4050004@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ENBQisjn0Q6HA4nrtDLN7jnzXVw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2014 04:59:56 -0000 Le 14/11/2014 04:00, Jeroen Massar a écrit : > On 2014-11-14 03:15, Alexandru Petrescu wrote: >> Le 14/11/2014 01:43, Jeroen Massar a écrit : >>> On 2014-11-14 00:07, Alexandru Petrescu wrote: >>>> Jeroen - you make up a few pretty good questions, I am happy. If I dont >>>> keep up sorry. >>> [..] >>>>>> Yes. My situation currently is that my network is on 6to4, >>>>>> it seems to get discarded, >>>>> >>>>> What gets "discarded"? >>>> >>>> deprecated 6to4 seems to become by meeting discussion. >>> >>> But there are MANY alternatives which will work much better. >>> >>> Thus what is the problem? >> >> The ones you suggest involve renumbering later - painful. > > As you chose to use 6to4 you will have to renumber anyway one day. 6to4 > is a transition technique, hence bound to go away. Yes, I prefer to reunmber only once. If one depreciates 6to4 now, and as I can not get native now, I am found in a situation to renumber twice - once for the tunnel brokers and once when I go native. Right? > Note that technically you do not have to renumber, you can keep on using > that 6to4 prefix, just not with a default pointing to the Internet > anymore, especially not that anycast address. What does it mean? Somebody else than that anycast address could forward my 6to4 traffic, for free? Somebody nearby? > Also note that when changing ISP one will have to renumber, unless you > are your own ISP and play the PI game you will not be getting away from > that. Changing ISP is not an option. > Hence why becoming an LIR and getting your own ASN, own IPv6 PI and a > last chunk of IPv4 is very popular, even home users do that already. > > Another note there is that most CGN/DSLite providers have are delegating > prefixes that rotate every 24 hours, for "accounting" reasons or "your > privacy and anonimity" but in reality so that folks won't run servers in > the cheap space and need to buy hosting instead. >>>>>> and the trustful ISP is not _yet_ offering native. >>>>> >>>>> What do you mean with "the trustful ISP"? >>>> >>>> An ISP that has same upper organization that my organization. In >>>> private you pointed me to it, you know what I mean. >>> >>> Kick your internal organization. It is 2014. Not 1996. >> >> Arguing at an organization takes more time than the flash depreciation >> at IETF... > > This draft will become an RFC... vendors won't do much, existing devices > will keep on doing what they do as they do not get updated. > > Maybe operators will start stopping their relays, but that is it. That > will take a couple more years though for all that to fade away. The past experience of deprecating site-locals was much faster... >>> Also the upstream organization (RENATER) has been doing native IPv6 for >>> many many many years thus they will be more than happy to deliver it. >> >> Sure. >> >>> The IETF cannot fix politics inside organizations. You will have to >>> fight for that. >> >> This is not politics. > > In the end everything comes down to politics... if you like it or not. > >> This is simple disconnect between what people >> think at IETF it is good for end users. > > I think "the IETF" is of the opinion that native IPv6 is the way to go. Well that is a good opinion. But bringing to life is not easy, for example because of the established fear of the huge number of existing applications IPv4. People are busy maintaining that... Alex > > This is also the message being sent out with deprecating 6to4 which is > just one of many transition mechanisms. > > As you state "end user" btw, you should be contacting your network team > to get their act together. They kind of had already 15+ years of warning > that this was coming and the hype machine has been doing proper > information distribution and pushing folks to do this IPv6 thing. > >>> [..] >>>> Well by renumbering I mean the Renumbering RFC which uses a form of >>>> Router Advertisement propagation. >>> >>> I have never ever seen anybody use that. >> >> I guess the authors of the RFC at least have used it. > > I'll refer to a previous message in this thread to answer your question: > http://www.ietf.org/mail-archive/web/v6ops/current/msg20524.html > > Demonstrating that the folks who write the drafts do not always use > their own tools... Well, on another hand, its easier to write RFCs that remove software than writing RFCs that need new software... >>>> You have scripts - great, I am happy for you. >>> >>> Any decent system administrator or network operator who is lazy as they >>> should be will do that. >>> >>> Systems like rancid, puppet etc exist for many many reasons. >> >> Huh? Does it compile for a 1cmx1xm LTE embedded device, for example? > > Contact the vendor of your device for details on how to properly manage > them. Likely though it is just DHCP that you'll use for it or some > custom Enterprise tool that can set all kinds of settings. YEah I did - IPv6 is not important, the applications are important. How many new IoT applications can we imagine for them such that more get sold. Most work without IPv6, IPv4 is sufficient. Alex > > Greets, > Jeroen > > > From nobody Thu Nov 13 23:10:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03F1A6EF1; Thu, 13 Nov 2014 23:10:53 -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 jHTl_yA5micb; Thu, 13 Nov 2014 23:10:50 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A001A1AA5; Thu, 13 Nov 2014 23:10:49 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so1770652wiw.1 for ; Thu, 13 Nov 2014 23:10:48 -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=NVjCF2MDgjB2udCtzeG/l/seF25PvH2gPoQiKnrlqCQ=; b=Q2mEGNvIltoemcYqmhGacbVuXBp9wpaHUY011iG06tdsXzM3G+d+ZUdLQTxrRB0F3G DiHm4Q9jnZ8jo6uPQlC0QaFv+cXQ3gKFD1r1FVdzvl5WfJZHZ1LkV0JJgwfyt+ziQY4G fE2vXGZgbn9XAZOFWI1Wsfgt/0vRJvi/TzPywdyrXjtxoUVx0E3tX2Uzl90CupfPayD8 INKQiNIC+B8NIEo/2+6aDkeZEiyz/18cmPEiDyi8lFSwBEYeYQ21RiCNQb+BJCXLTbtV X35GtFfTEfSP3n9WXw1WUEroMc+Ou+dYikbr+RLexDEdZAkndxykAKW+/5oWuy6AYhh4 RWhQ== X-Received: by 10.194.89.129 with SMTP id bo1mr11072151wjb.29.1415949048446; Thu, 13 Nov 2014 23:10:48 -0800 (PST) Received: from Ivans-MacBook-Air.local (BSN-142-170-80.static.dsl.siol.net. [89.142.170.80]) by mx.google.com with ESMTPSA id l4sm38421519wjx.14.2014.11.13.23.10.47 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 23:10:47 -0800 (PST) Date: Fri, 14 Nov 2014 08:10:46 +0100 From: Ivan Pepelnjak To: Jeroen Massar , Mark ZZZ Smith Message-ID: In-Reply-To: <54654E47.7090003@massar.ch> References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <54631E71.60403@massar.ch> <1415923659.92015.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54654E47.7090003@massar.ch> X-Mailer: Airmail (249) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5465aaf6_6c09b517_1215" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AahRXZWh_zc1SnTmxH9tGNyeaKw Cc: IPv6 Operations , 6man Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Fri, 14 Nov 2014 07:10:54 -0000 --5465aaf6_6c09b517_1215 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Gentlemen, I will risk wasting everyone else=E2=80=99s time trying to explain yet ag= ain what the real problem is and why all the ranting about load balancers= inspecting or not inspecting ICMPv6 messages won=E2=80=99t bring the wor= ld peace. Some environments are simply too big for stateful load balancing. The onl= y workaround those environments have (based on how badly we crippled TCP/= IP stack with lack of session layer, leaky abstractions and DNS pinning) = is to insert a layer of stateless anycast load balancing in front of the = stateful load balancing (or proxies or whatever they use). The stateless anycast load balancing at speeds these environments need ca= n only be done with a layer 3 switch (device formerly known as router), w= hich is not expected to look deep into the packets (at least that=E2=80=99= s the theory that should be promoted on IET=46 mailing lists A=46AIK). A client request landing at this L3 switch is hashed based on SRC+DST IP = (port numbers may be used or not) and sent to one of the anycast destinat= ions. A PMTUD ICMP message arrives from an intermediate hop, not from the= client, and is thus hashed based on Router IP+DST IP. Nobody in his righ= t mind will waste the silicon to inspect random fields deep into the ICMP= v6 payload, or punt the transit ICMPv6 packets to the CPU just because. Also, the flow label approach will not solve this problem. You=E2=80=99re= just reinventing cookie-based stickiness and all its properties that any= one operating a load balancer immensely loves with flow labels. Ivan Pepelnjak www.ipSpace.net=C2=A0/=C2=A0blog.ipSpace.net Need a quick expert advice=3F Try ExpertExpress (www.ipspace.net/ExpertEx= press) On 14 Nov 2014 at 01:35:41 , Jeroen Massar (jeroen=40massar.ch) wrote: On 2014-11-14 01:07, Mark ZZZ Smith wrote: =20 =5B..=5D =20 > So I'd argue that protocols shouldn't have to be changed in reaction =20 > to lack of proper product design. I wouldn't support using the flow =20 > label for this purpose. =20 =46low Label cannot work the way that it is defined. =20 The reason for having a =46low Label is so that for instance a Load =20 Balancer does not have to look further than the first 40 bytes of packet = =20 (thus just the IPv6 Header). =20 But, as every node MUST look at ICMPv6, that is thus automatically false.= =20 Hence, the =46low Label is useless for the purposes of identifying a flow= . =20 Note that an IPv6 'error', thus an ICMPv6 packet, for instance an PTB, =20 but also =22port unreachable=22 etc is part of the flow as it indicates a= n =20 error status that relates to that flow. =20 Obsoleting the =46low Label and using the bits for a problem we did not =20 have in 1996: Load Balancing, proper MTU discovery etc is thus a good ide= a. =20 Note that back then nobody really cared about 0-RTT either. This =20 proposal CAN make that work, which will make a lot of content providers =20 very very happy. =20 Oh, and it solves most cases of the Load Balancer issue too (as =20 described in the pmtud-ecmp draft). Though yes, it still will need to =20 inspect a ICMPv6 PTB, at least it is not misled to believe the =46low =20 Label is useful in any way. =20 =5B..=5D =20 > I think the fundamental conflict is that the Internet protocols =20 > assume a unicast destination address in a packet identifies a single =20 > unicast destination for the forwarding system to deliver to. =20 > Stateless LBs are violating that assumption, which is why the =20 > protocols built on that assumption then fail. =20 That is mostly correct, but that is not the primary reason. =20 The big problem is that even if the Load Balancer supports parsing the =20 ICMPv6 PTB and can associate it with the correct =22flow=22 and thus the = =20 right backend host, it won't help as there are a lot of other systems =20 out there that are on purpose filtering out ICMPv6. =20 By including the MTU in the packet though, it won't be filtered (or at =20 least set to 1280, which is the minimum which just makes them hurt their = =20 own performance, but it won't break things). =20 Greets, =20 Jeroen =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 --5465aaf6_6c09b517_1215 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline